views:

535

answers:

4

We're about to start a new project, and our client's current application is .NET versioned in SourceSafe. However, we use Subversion internally. This will likely be a "one-time" delivery (complete application rewrite), so they could easily do a checkout from our repo, then export, and import into their SourceSafe repo. However, my fear is that if we have some edits or do future maintenance, that it becomes much more difficult to manage. Any thoughts on how best to handle this?

EDIT:

I'm not sure if it makes a difference, but there is a low-probability that the client will make changes. If they do, it will be after we are 100% done, which makes it easier to manage. If we were both making changes simultaneously, then I would probably suggest I give them write access to our repo for their project, and we manage it that way. I'm trying to be forward thinking though, because there is a strong chance they would want us to come back and do more work with them.

+1  A: 

I wonder if there is any way you could use use a distributed version control system to manage the interaction between the two repositories. I know git can work with svn, but I am not sure about sourcesafe.

Zoredache
That seems like a good approach; the sourcesafe side would probably need to be manual (or read/written from a custom script)
Jason S
+1  A: 

is the client going to be making changes to the program as well? If so, I would say what you are thinking is the best: do an export out of subversion and put that into source safe. Then anytime they want you to make changes, you export (or checkout or whatever) any changes they have made and make those changes (really just copy over the top) of a checked out version in subversion. It isn't pretty, but you don't have many options. You could also try and just get them to send you any and all changes they make.

Why is there a need to keep the code in two code repos?

Ryan Guill
+3  A: 

Another option is to provide them with access to your svn repo (for their project only) and give them support, links, etc. Once they see the light they may not want to use anything else...

I think I would do it that way until you have to make a decision about ssafe. Maybe before you have to make a decision it will just go away.

I did have an experience with this in the past. For some reason the company we were subcontracting was using CVS internally, but SourceSafe for external client facing stuff. I took over the project and put it into svn. The contractors were happy with that.

EDIT:

Additionally, it is possible to have a master/slave svn repo set up. Not sure if that helps in this situation.

Another possibility is asking them if they would host an svn repo if you set it up and admin'ed it at first.

All in all, it is probably best to talk to the client to work this out. See what ideas you can come up with. Maintaining two ACTIVE repos is not a good idea.

Tim
Once they see the the light? Git hasn't been mentioned, has it? ;)
pmr
funny. I think git has a long way to go as far as UI and ease of use before the source safe crowd will adopt it. You are asking for TWO companies to change repositories, not just one. That is a big leap.I'd probably pick mercurial over git in any case.
Tim
+2  A: 

I've been working on a VSS->SVN migration tool, one task of which was to provide support for updating the SVN repository with any changes made after a certain date (I had to do this as we have a 16 gig VSS DB, and it takes blinking ages to migrate around 3 million individual revisions)

So, I make a snapshot copy of the VSS DB, and use that to import with, then some time later, I migrate all the changes made since I took the snapshot. It seems like this would be useful to you, as you could just import changes your client makes to their VSS DB.

The code is released in the SVN repo, but not built as a package yet as you'll have to download the files from the SVN repo and build. Its .NET based so you should be comfortable with it. It also keeps all label, author and date changes.

Its hosted on CodePlex as VSS2SVN.

gbjbaanb