On 19/04/2011 22:05, Darren New wrote:

> I honestly wasn't recommending git.
>
> However, that said, and with the understanding that I haven't looked at
> the other DVCSs, I think git has a very interesting layered approach to
> the problem.

OK, I just sat down and read it.

Yeah, it's fairly straight-forward. But I can see how if you don't 
understand the way it works, there's huge potential to *seriously* 
confuse yourself!

I had assumed that all DVCSs were the same, but I now see that at least 
Git and Darcs use fundamentally different models.

Fundamentally, any version control system tracks changes to files. What 
Git appears to be doing is something similar to RCS or CVS, where each 
file goes through a strictly sequential series of "versions", and one 
version comes "before" or "after" another. It seems that each commit 
stores the complete state of the entire repository. (Presumably as a 
diff relative to the previous commit, but still logically it's a 
snapshot of everything.) Git then uses "heads" to point to the most 
recent commit in each branch, or to other interesting points in the history.

Darcs works completely differently. Darcs doesn't track sequential file 
versions, it tracks change-sets. It defines a "change-set algebra" where 
unrelated changes to the same file are independent, and can be applied 
or reverted independently. Changes to the same part of a file are not 
independent, and can only be applied in sequence. But unrelated changes 
are... unrelated.

As an example, if I add some comments to file X and commit that, and 
then I add a new function to file X and commit that too, I get two 
change-sets. I can revert adding the comments but still keep the new 
function, even though the latter change happened *before* the former.

As far as I can tell, Git would require me to create a branch where I 
add the comments, and another branch where I add the new code, and then 
merge them back into the main branch, hoping that I don't get any 
conflicts. To me, this seems like a lot more work and a lot more 
conceptual overhead.

It also seems that when you ask Git to perform a commit, you have to 
tell it which files to record changes for. With Darcs, you tell it which 
files to monitor, and when you ask to commit it detects what's changed 
and interactively asks you which differences to include and which ones 
not to include. E.g., I could add comments to file X, add a new 
function, do a commit and interactively split the modifications into two 
separate commits. (It doesn't /always/ work, of course, but mostly it does.)

I wonder how well the illusion of one single sequence of file versions 
works when you have multiple people editing the file in parallel. I 
would imagine the Darcs model works better, because it doesn't try to 
pretend that file X looked like this, and then this, and then this. It 
just records what edits happened, without recording their relative 
ordering [except where they affect the same lines of code]. Git, on the 
other hand, appears to be trying to track what every file in the entire 
repository looked like in every individual commit object.

With Darcs, you make a branch by copying the repository. That's it. 
(Although there is an option to build a bunch of symlinks for you 
instead of just copying, to save a bit of disk space. Presumably only on 
POSIX platforms...) You can email individual change-sets around, and 
this works. Getting somebody else's changes just copies all change-sets 
from their repository into yours. You can then resolve any conflicts.

Still, I've used Darcs quite a bit, and I've never once used Git, so I'm 
not really qualified to say how well it works in practise.

Post a reply to this message