I’ve been through the mill with version control. I started with sccs, believe it or not. Worked with RCS. Moved to CVS. Was forced to use Visual SourceSafe, and hated it. Have been pretty happy with Subversion.
I’ve been looking at the new distributed VCS – Git, Hg, etc. They look complicated. I have doubts over whether they provide enough of an advantage over SVN to make it worth the time it would take to get the entire team moved over to one of them.
But I was thinking. From what I’ve read there are two real changes in Git as compared to SVN. First, the distributed repositories. Second, managing merging through change sets, instead of with versions.
I don’t think I’m the only one for whom the first advantage is meaningless. For our business, we need a single repository. SVN does this, Git can do this. That Git can manage distributed repositories, as much a benefit as it may be to others, benefits us not at all.
Managing merging through change sets, though, is something that would benefit us. We’re managing multiple projects, with multiple branches, with some child projects being shared by multiple parent projects. Managing changes that need to be made across these branches is a lot easier with SVN than it was with CVS, but it’s by no means pain-free. Git’s change-set approach looks like it would be a real benefit.
What I’m wondering is how much of Git’s added complexity is due to the use of multiple repositories, and how much is inherent in working with change sets? Could a VCS that used change sets, but did not provide for multiple repositories, be simpler than Git?
And are there any VCS that work with change sets that are simpler to use than Git?
Subversion does have a concept of changesets, you can specify a changeset with the -c option. You can merge individual changesets, or a range of changesets. Behind the scenes, this is actually how Subversion stores each commit, in /db/revs/ (for file based storage at least).
What I see as an advantage in Git compared to Subversion, is that when merging multiple changsets from branch A to branch B, branch B retains each individual changeset, while in Subversion it gets squeezed together as one changeset and it “looks” like all changes are done by the user who committed the merge. While you can follow the history back to the old branch to see each changeset in Subversion, it’s not that convenient.
Git also has some powerful commands to see the differences of changesets between branches. The merge tracking introduced in Subversion 1.5 tries to do something like this, but is IMHO overcomplicated and not intuitive.