On 29/04/2011 05:16 PM, Darren New wrote:

> Indeed, that's my main complaint with the whole concept: the idea that
> simply because two patches are in different files doesn't mean they're
> unrelated. If I implement foo() in file abc.c and call foo() in file
> def.c, those are not two unrelated patches.

And my complaint about Git is that just because change X happened after 
change Y does not necessarily mean that change X depends on change Y in 
any way, yet Git assumes that it does.

Fundamentally, I expect working out which changes truly depend on each 
other is probably undecidable. [And that's before we even get into the 
fact that the only way for this to work properly is to implement a 
seperate detection engine for every programming language you ever want 
to version control.]

Apparently both models do work in practise, since there are people using 
them. Personally, I much prefer the way Darcs does it.

> We both record our changes.
>
> We attempt to merge our repositories.
>
> Can you try this on a blank repository on your machine and tell me what
> happens?

I imagine Darcs will say "error, these changes conflict, please fix it". 
And other words, "I can't figure out what to do; you decide".

> Resolving this in git is very straightforward. You can just pick one
> that's right and say "Henceforth, that's the answer". Or you can just
> grab all the changes and basically never merge them back together again
> (say, if you have two distros in the same repository).

That sounds in principle like the same thing that Darcs does.

> Also, what happens if I rename a file from XXX to YYY and you rename it
> from XXX to ZZZ? Do I wind up with both YYY and ZZZ in my repository?

Same again, I would imagine.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message