My software group uses Subversion for source control. It fit our needs better than any other system out there.
Personally, I've been using Subversion since the 0.3x days.
I think most developers who actually bother to research SourceSafe will never touch it, even if 2005 fixes the long-running database corruption problems. I don't regard software where I have to run a fix tool every night to keep the corruption in check
as being reliable.
When we looked at source control last year, we picked SourceGear Vault. We didn't consider open source source control - we wanted a company to blame if things went wrong. SourceGear had a good history already with SourceOffSite. Perforce looked way too complicated
for us. It's possible to get a new developer with no previous source control experience working with Vault in about an hour, a little less if you've got previous SourceSafe experience.
Right now our Vault repository has 532MB of source in it, although a lot of that is shared and branched files: the database is only 210MB. We keep source and binary dependencies in the repository.
We still have a program, written by a colleague, scheduled to run every night, which performs a 'get' of particular projects in the repository to corresponding paths in our 'work in progress' file share, if changes have been made to those projects. I'm not
aware that anyone's actually using those backups though. Maybe it's time to stop making them (we are of course backing up the full database weekly and the transaction log nightly).
As for separating roles, here all developers have commit privileges. I believe that Microsoft also grant all developers commit privileges, but not immediate commit. A commit typically has to pass a series of check-in tests before being checked in. For a large
product like Visual Studio or Windows, each subteam has its own 'virtual build lab' - a branch on which development for that subteam occurs, separate from the main trunk for the product. That stops a build break in one subteam from affecting the whole organisation.
A developer checks code into his team's VBL; only when the team and the managers of the trunk are satisfied that quality is good enough is the change integrated into the trunk - a process termed 'reverse
integration' or RI.
I use SVN for all my new projects, but haven’t converted my CVS projects over.
The crowds that be that use free version control systems seem to all lean toward SVN from CVS, even the ones that lead toward commercial apps still put cvs on the far side of what they want.
The nice free IDE integration is what did it for me. (ANKHSVN)
I've gotten bitten by Visual Source Safe a few times over the years (that's why I use Subversion now).
Since we're a very small development team, and 99% of our projects are one-man things, we just don't have use for the sophisticated branching/merging features that some of the higher-end commercial version control packages give us.
I don't think we've ever made a branch on one of our source trees, besides experimenting with SVN's features.
I also like Subversion because of the TortoiseSVN interface. It's an add-on for Explorer. Most of your version control functions are simple right-click operations.
For my workflow, this seems like the most "natural" place for version control. I'm using Explorer to manage my files ANYWAY, versioning is just an extension of that.
I don't like version control systems that are heavily IDE-oriented. There's a few reasons for that:
I use several different IDEs. Finding one VCS that integrates with all of them is almost impossible. A lot of the code I work on is not part of an IDE (text editor and make scripts).
Also, I work with a lot of non-IDE resouces that need to be versioned. I have product manuals (Word .DOCs). I have board schematic and PCB layout files. We also have things like EPLD and FPGA designs.
One cool feature of Subversion is the WebDAV interface. It allows a person to mount the SVN repository as a drive letter in Windows. They can work on it like a regular disk drive, and all of the file versioning happens transparently.
This feature works well for out CAD department, which don't really get the concepts of version control systems.
Re: SVN vs. CVS
I chose SVN over CVS for two reasons:
#1 Atomic commits. To me, this is a critical feature of an serious version control system. It's the only way to be sure your repository is in a good state. This is another reason you should steer away of Visual Source Safe (it doesn't do atomic commits).
#2 Binary files. As I mentioned earlier, we keep a lot of binary resources under version control. CVS doesn't handle binary files as diffs. This can get inefficient pretty quickly, especially with a bunch of 10MB board schematics.
Personally I like an IDE driven source control system. Using Tortoise in conjunction with sourceforge I find an awful experience (and that's setting aside the SSH setup and use).
Vault I've used at a client site, and watch it die under moderate load. Horribly. Even with the sourcegear people looking at it for the entire 9 months of the project we could write off an afternoon due to vault not being available.
But Vault is atomic, can be configured for change sets and is free for a single developer. So it's Vault at home, as I don't care about scalability when it's just me. I just need to get a new server to keep it seperate from my normal SQL box, which I'll be
pushing to 2005 very soon. Which means I'll have to reconfigure my network to NAT as I'll have ran out of static, routable IPs. Damnit.
Strangely though I've never, ever had SourceSafe go haywire.
Subversion rocks. We're using it for all of our Windows, Mac and Linux development.
Past experience with VSS was always unpleasant.
'Source Safe' is intolerable.
I will never trust that name.
Starbase was what I preferred, (harkening back to my Delphi days); if TFS matches that sophistication, I will use it, but who can afford either of these anyway?
We use sourcesafe because frankly it was hard enough beating people here in to using that in the first place let alone anything else. It needs to be zero friction.
We evaluated SVN but it was a long time ago and I think Ankh wasnt right at the time. As I said, it has to be zero friction so thats IDE integration or nothing. If we were starting from scratch right now, I'd use SVN. I would push for a switch to SVN now if
there were a simple upgrade path. Is there?
We'll probably switch to team system when that gets going, assuming a SourceSafe to TFS upgrade path. Allthough of course now there are six of us needing source control access, so thats screwed us on the five users free TFS thing, so maybe not - unless there
is a truely compelling reason to.
Sourcesafe has never gone that badly wrong on me that I've lost stuff. The major problem I have had is trying to branch projects in sourcesafe. Just dont.
We've looked at Subversion, but we use SourceSafe on a regular basis with 10-15 developers without having any corruption issues.
I'm not dissing subversion, and I'd be happy to use it, but Source Safe's problem is that it's documention and UI is not obvious. Otherwise, it works quite well.
I've been using VSS for years and touch wood......
have never had any problems with it
Heh. Heh, heh.
Huh. Huh, huh.
I work in an enrironment which is about equal numbers of Mac, PC and Linux. Subversion seemed like the best natural choice for versioning on all of these systems. TortoiseSVN makes the PC the best platform for dealing with Subversion. After using TortoiseSVN,
I find all other IDE integrated version control plugins are way inferior.
Subversion is flexible and has multiple ways it can be accessed (WebDAV, http, https, svn server). It is easily customized: I built custom post-commit scripts to automatically build, test, and deploy code to multiple servers.
The biggest problem for me is the lack of a client that is as good as TortoiseSVN for Mac and Linux desktops. There is one for Mac called 'SCPlugin', but it is about 10% complete (compared to Tortoise).
On the Mac, look at
SvnX. XCode also supports SVN.
On the Mac, look at
SvnX. XCode also supports SVN.
I have tried those, but they are quite shoddy when compared to Tortoise. They really inhibit smooth workflow, especially for designer types.
Never had any disappearing sources and now with VSTS it rocks
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.