Any non-distributed Version Control that uses change-sets, rather than versions?

Question

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?

Answer 1

I would say the learning curve of git and is well worth it for any type of use.

I'm not exactly sure what you're describing in terms of "change sets," but darcs talks about things in terms of "patch sets" which may be similar. It's also a DVCS, but rather different. I don't really understand darcs as well as git, though I am occasionally forced to use it. It may be what you're looking for.

I think intentionally trying to avoid DVCS is a mistake. You can still entirely use one central repository. The distributed part is wonderful for working when disconnected from the internet, and also great for reliability. You aren't dependent on the server. I get lots of work done when I'm on a train for 6 hours on my projects since I'm not tied to the server. In the event of a server issue, when every person with a checked out copy has the entire copy, you don't lose anything.

Answer 2

I'm not sure what you mean by "changesets" or "versions". It seems to me like it is in fact exactly the other way round. The way git stores its data is by storing the full content of each file. SVN on the other hand only stores the diffs of new versions.

The distributed repository feature is one that is extremely underestimated. Before I switched to git I did not see the potential yet either. But having local commits and local branches is a killer feature.

SVN has externals to deal with sub-repositories. In git this is called submodules (it's a bit different). This should not be a deciding factor, since both SVN and git support it. Except if you don't like how git does it, of course.

I suggest you watch this talk called getting git, it will explain how git works. Especially the "VCS taxonomy" slide does a good job of explaining the fundamental difference between different VCS' out there.

Answer 3

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.