Question

Hi all, I am trying to "free" my mind and see why storing changes (as git and Mercurial do) instead of storing revisions (as svn does) is better from developer point of view. Can you provide me some real programmers life examples showing the difference please?

Regards, Adam

Update:

Thanks for that information, Unfortunatelly I am not still convinced.

@Tyler Hicks-Wright:

The biggest benefit is that when the system stores changes, and then you branch (implicitly or explicitly) and later merge, it knows which changesets to merge in. The next time you branch and merge, the system already knows that those changesets have been merged in (as well as how they were merged) and won't try to do it again. This avoids a lot of the merge conflicts that tend to occur in centralized systems like Subversion.

Any working example of this happening?

@cdeszaq: You are talking about superiority of the merge using changes storage because of better granurality. Again can you provide me an example where the same code is merged using say SVN and Mercurial and SVN has problems which are not present when it is done with Mercurial please?

Best regards, Adam

Answer 1

The biggest benefit is that when the system stores changes, and then you branch (implicitly or explicitly) and later merge, it knows which changesets to merge in. The next time you branch and merge, the system already knows that those changesets have been merged in (as well as how they were merged) and won't try to do it again. This avoids a lot of the merge conflicts that tend to occur in centralized systems like Subversion.

<update>
It is a little difficult to manufacture this situation in SVN because you have to be working as if you were multiple people, making simultaneous, conflicting changes. Because SVN stores the file at each state, it doesn't know how it got there, so it just pulls up two big diffs, compares them, and if there are any conflicts, the merge will be conflicted.

With DVCSs, you have smaller changesets, checked in more frequently, so the system has a lot more information about what changed when. Also, once you do a merge, as I mentioned before, all of the merged changesets are marked as being a part of the repository, so if another branch, that also has those changesets, is later merged in, it doesn't try to include them again because it knows they're already there.

When we were using SVN, we'd run into this problem pretty frequently. It was a very bad feeling of déjà vu, you knew you'd already merged this (and it wasn't easy last time) and now you had to do it all over again.
</update>

It's also a lot closer to what's actually happening when you write code. You aren't coding with the intent of making new versions of each file, you're just making changes. Once you get away from the "this is the version I'm committing" to "these are the changes I'm committing", you're workflow becomes more in line with what the system is actually doing.

Answer 2

In a nutshell, tracking changes (or change-sets...groups of changes) lets you tracked what changed and how it changed. Tracking revisions only allows you to track the differences between revision:NOW and revision:PREVIOUS.

When you go to merge, merging changes, since they are date-ordered and related to each other, simplifies things because you can apply each change one-at-a-time. Merging revisions, on the other hand, tries to merge sets of differences, which are not nearly as granular as changes are, and are the root-cause of the massive numbers of conflicts that revision-based merging has as opposed to the fewer number of conflicts encountered with change-set-based merging.