Sent an email to Chris Kinsman about an update on his weblog about CVS and SourceSafe. Some of it is here:
CVS is to SourceSafe like Macintosh is to Windows. Both will get the job done, but they really approach the problem from different directions.
One tip I can offer is this: Don't try to use a GUI, get to know the CVS command line tools. There are a few GUIs but until you really understand what CVS is doing, the GUIs just confuse things (a lot).
SourceSafe forces you to check out a file, modify it, and check it back in. You can see what files other users have checked out so you know in advance if you're going to conflict.
CVS, however, calls SourceSafe's "get" operation, "checkout". There isn't really a concept of locking a file (there is, but it's not recommended).. you just "get" (checkout) the source, make your changes, and then try to commit them. It's not until you commit that you find out there's conflicts (and then only if they couldn't be merged cleanly).
CVS handles branches really well. I have a myproj71_branch that I tagged on my project, and then I did a "cvs co -r myproj71_branch myproj" to get a 7.1 copy and when I make changes in this copy and commit them, they automatically go back into the 7.1 branch and not into the main (HEAD) branch. When I commit a file in the 7.1 branch, it tells me that the new version is, say, 1.4.3.2. Then I can go back to the main branch and say "cvs diff -r 1.4.3.2 myfile.c" and it will tell me what's changed between the version I have now, and the one I just checked into the 7.1 branch. "cvs up -j 1.4.3.2 myfile.c" merges those changes into the file I have.
The idea that I can go into any directory with source in it and say "cvs up" to get a freshened copy of the stuff in that directory, respecting what branch I checked it out from, is cool. I don't think SourceSafe handles that nearly as well.
I've used SourceSafe for years, and I miss the integration with the IDE. There's the Jandili Igloo project (I'm sure I spelled that wrong but a search should find it) and a few others that try to integrate CVS with VS.NET but because VS.NET is designed around the SourceSafe paradigm, the integration doesn't really work that well. I find it says I've got a ton of modified files when really I don't.
You CAN make CVS work like SourceSafe, but you'll be fighting it the whole way, and it's not really worth it. You won't be happy with the result. You pretty much have to give in and work CVS's way.
On to fixing the problem... what I need is a client/server SourceSafe, with a good command line interface that the Unix guys can use. Microsoft says that the VSS team is working on some cool stuff but of course won't say what it is, and I'm fairly sure Unix isn't a priority for them, so I'm probably on my own.
The SCC API is what VS.NET uses to talk to SourceSafe. A shim SCC that remoted the calls to a process on the VSS server that made SCC calls to a real SourceSafe would satisfy the client/server aspect, and a .NET command line SCC client that talked to the remote SCC server that you could run in Mono would satisfy command line requirements on every platform.
One question is does SCC expose functionality that would make it possible to corrupt the VSS database remotely... guess I'll have to find the SCC docs and figure it out.
A side note: In my opinion, one of the reasons that communities of Windows developers are not forming the way they do with Linux is the lack of something like anonymous cvs access. Giving out current copies of source to a Windows project means zipping it up and posting it; it's no work at all with cvs.
9:12:11 AM 
|
