At work I'm being forced to switch from Starteam (complex, expensive and apparently almost dead; works well but I don't recommend to adopt it) to Subversion, and two serious steps back are apparent:

1) It's much slower than Starteam. Committing one thousand files takes many minutes. Maybe it's a consequence of slow disks and overloaded computers; however, TortoiseSVN needs about 500MB memory for such an operation.

2) It litters every directory with hidden ".svn" directories containing files named like source files, a very serious problem with every tool or build process that wants to process directories recursively or to delete and regenerate source files.

I'm considering Mercurial as a replacement for Subversion, with mostly the same benefits (support for Windows clients and Linux servers, inexpensive, Trac integration) plus clean working copies and presumably much greater speed, but with less tool support.

Both Subversion and Mercurial offer only version control; if one wants a more integrated system to track issues, link issue lifecycle to commits, produce releases, etc. you can evaluate the complex and expensive solutions like Starteam (RIP), Perforce, Surround SCM, etc.

I don't believe in IDE integration; editing code and performing updates, commits and merges are separate activities that are performed at different times, so why not with different tools?

Regarding the untrusted developer, I agree wholeheartedly with kyoryu and I think that any policy of formal and explicit distrust will ensure your company an enemy, not a productive team member.
Stealing your source code only because it's secret is a likely reaction; being nice until he earns your trust and some privileges, then brutally sabotaging the company, is also an option.

The pariah could work without any access to the SCM tools and to most of the sources: his work can be mostly self contained, without depending on most of the framework, or he might be left unable to link, or even compile, his code; he could send code to a colleague, getting an executable in return, and everyone would be productively annoyed. :-)

Quote:Original post by LorenzoGatti
At work I'm being forced to switch from Starteam (complex, expensive and apparently almost dead; works well but I don't recommend to adopt it) to Subversion, and two serious steps back are apparent:

1) It's much slower than Starteam. Committing one thousand files takes many minutes. Maybe it's a consequence of slow disks and overloaded computers; however, TortoiseSVN needs about 500MB memory for such an operation.

I've not experienced this before, but I've admittedly not looked that closely either. My understanding is that Subversion sends Diff files both ways (that is, to commit, or to update one's local source folder.) At my last job, adding a 1000-file directory to the subversion repository for the first time took under 3 minutes (and that was over a private VPN connection from the local office near Seattle, WA all the way to the home office in Baltimore, MD) I guess its the size of the files, though, rather than the number. That said, the same operation using Visual Source Safe would take between 30 minutes and an hour.

Quote:
2) It litters every directory with hidden ".svn" directories containing files named like source files, a very serious problem with every tool or build process that wants to process directories recursively or to delete and regenerate source files.

While it's kind of annoying from a "purity" standpoint, you really shouldn't be building directly from your SVN directory anyway. There's an SVN command, "EXPORT" I believe, which create a "clean" copy, free of any internal subversion files, in a directory of your choice. Just build from that instead. This clean-copy procedeure can be added as a pre-build process in your IDE or build system easily.

We did this for our entire automated build tree running on NANT. Every night at midnight, all our projects were checked for changes and re-built if there were any. There was a web-based interface for starting the build process manually on individual projects as well.

Quote:Original post by LorenzoGatti
I'm considering Mercurial as a replacement for Subversion, with mostly the same benefits (support for Windows clients and Linux servers, inexpensive, Trac integration) plus clean working copies and presumably much greater speed, but with less tool support.

For the Chicken Scheme-to-C compiler we use Darcs. Chicken is a medium sized project, 75K LOC, with a complicated bootstrapping build system. Darcs is a distributed version control system, there's no such thing as a central repository. Every Darcs repository is a fully working repository, and users push and pull patches back and forth to each other's repositories. In open source development this has tremendous advantages. It has allowed us to work in parallel on various issues without having to wait for each other, then Darcs has sort of semi-magically combined what we were doing. Darcs has a strong mathematical patch theory which is what allows such "in parallel" tricks to be played.

Darcs is written in a pure functional programming language called Haskell. Haskell may be responsible for why Darcs can do what it does. I've never looked at Darcs' implementation so I am not sure. Certainly, Darcs is a poster child for what Functional Programming can accomplish.

A disadvantage of Darcs is it's relatively slow. It's fine for a 75K LOC project, but I wouldn't want to use it on a million+ LOC project. At least, I'd want to see evidence from some other quarter that Darcs can handle it. 2 years ago it wasn't able to; I don't know about now.

Another disadvantage is it's written in Haskell. If there's a Darcs binary for your platform, that's not a big deal. If a Haskell binary is easily obtained for your platform, then compiling Darcs from sources likely won't be a problem. But some platforms don't have Haskell binaries available, and it's a real PITA to bring up Haskell. Not likely to be an issue for a game developer, but I do recall some guy with a weird Unix system that was struggling.

Because of the Haskell bootstrapping problem, we considered moving to Mercurial. Mercurial has basically the same distributed development philosophy and capabilies, as far as I understand. Mercurial, however, is written in Python and so is easier to bring up on strange systems. I have no idea about the quality of the Mercurial implementation as compared to Darcs, whether it implements features equally well, what each has that the other doesn't, etc. I made a "Darcs ain't broke, please don't fix it" argument and it stuck. Darcs is still working fine for us.

I use Darcs straight from the command line. Initially I resisted this, but it's really the best interface available and I don't actually use that many commands.

I use CMake for our build system. It can generate native project files for all versions of MSVC, so I don't actually have to worry about version control on MSVC project files. I just edit CMakeLists.txt which is a plain text file. I lose some VS IDE capabilities doing that, but the cross-platform + distributed version control benefits more than make up for that. Also I don't have to worry about which version of MSVC is being used; it's up to the individual programmer. Some people use CMake just to keep all the different versions of MSVC straight.