My advocation of regular check-ins isn’t to verify that the developer is working. I trust my developers until proven otherwise, and I have easier ways of discovering a productivity issue than doing regular pulls from their private work areas. Rather, regular check-ins are wise for early uncovering of integration problems.

For this, performing regular “pulls” wouldn’t be as effective as regular check-ins, because I won’t know the right time to “pull”. The developer should do check-ins at a reasonable frequency, but not when their new code is in any random broken state! The code should be buttoned up and “not break the build.” Yet if I pull from their private working copies/branches at any random time, I can’t claim those attributes. Just because I pulled over pure crap wouldn’t mean that there’s a problem — it might just mean that the developer is in a massive code migration, which might be all done by, say, the end of the day.

In addition, as a manager, I might not know all the places to pull from.

So, I still maintain that it’s best if developers regularly check into the pool. I think DCVS have an interesting issue with this.

If a manager is worried that his or her developers are NOT checking in their changes on a timely basis, this is a problem with both CVCS and DVCS.

You mention that this is potentially more pervasive with DVCS since they have local copies of the repository on their machine.

Yet, there is a solution to this: DVCS allows “pull” operations. For the manager, all that is required consequently is to set up regularly scheduled pulls (e.g. a cron job) and review the diffs between the developer’s work and the current baseline project. As I see it, this is in fact a big advantage over CVCS: if the developer is negligent in checking in, the manager has the ability to investigate in a very detailed way.

And now we wish we hadn’t. It’s a complete bollocks that gets confused easily, and generates a LOT of svn:mergeinfo properties where they’re not needed, causing trac and other diff tools to spew irrelevant changes, adding way too much noise to the process.

Maybe it just needs some more work. But svn’s had 7 years to get this right, and have been pretty seriously upstaged by the “newcomers” hg and git when it comes to this “basic” SCM ability.

This limitation (lack of “merge tracking” ) has a long history in the svn community and was addressed in svn 1.5 (recently released).

- Sofia

In most projects that I’ve worked with using Subversion, I usually -spend- waste a considerable amount of time trying to fix some hangup that is preventing a commit. Subversion only seems to have no problems if you only make trivial changes. But what development project have you worked on that only required trivial changes?

I’m baffled by this post. Git was ditched because you heard on the internet that it’s GUI isn’t up to speed?!
That should probably not be your primary criterion…

The Git GUI tools (git-gui and gitk) have been criticised before, back when Git was in its infancy, but now they’re easy to use and work really well. And on all platforms. It’s not eye-candy, but they get the job done, and they do it well.

Branching is never “bad”. It is the safest way to introduce new features — and when branching and merging is hard to do (which is the hopeless case for Subversion), you end up never branching at all, and definitely never merging again.

Git is objectively better than Subversion. I’ve been working on very large proprietary systems using Subversion, and it gets the job done, as long as you don’t want to do anything out of the ordinary. Which you occasionally do when working multiple people on the same project and conflicts occur.

If you want to know more about Git and why it was designed the way it is, you should check out Linus’ presentation about Git at Google: http://video.google.com/videoplay?docid=-2199332044603874737

As to Git vs. Mercurial, I can’t really say. They seem very similar in design, but I haven’t heard of any major projects using Mercurial for primary development, while Git has the Linux Kernel, Ruby on Rails, X.org (and everything else from freedesktop.org), OLPC, Wine, various GNU build tools, Merb, Rubinius, Samba, VLC Media Player, and I could go on, but that would be annoying.

All in all, you’re wrong, everyone else is right.

- Simon