On 4/23/2011 10:38, Orchid XP v8 wrote:
>> git has all kinds of sweet tools to manipulate the repository in ways
>> Darcs can't very easily.
>
> Ways such as what?

Here's another example of something I don't understand how to do in Darcs.

Say you and I are both working on the same program. I find a bug in function 
ABC that needs a counter incremented in a loop. At the start of the loop, I 
add the counter increment.  You, at the "same time", find the same bug and 
fix it by adding the counter increment to the end of the loop.

Now, when we merge repositories, we'll be incrementing the counter twice. 
OK, not a problem that a VCS can solve, and you'd get the same ugly in git.

But ... OK, so I see you fixed the bug by adding the counter at the bottom, 
and since I already fixed it, I throw away that change from my repository.

You see you already fixed it, so you throw away my change in *your* repository.

How do we reconcile that later? How often do I have to exclude your change 
from my repository (while still obtaining your other changes), or how do I 
tell you to throw away your change and use mine instead?

In git, I'd manipulate the branch structure, or possibly rebase my changes, 
or I'd revert out that one change from my code during the merge and continue 
on. But since Darcs apparently doesn't record "they both started from the 
same place and made changes in parallel",

I don't see how Darcs can rationally handle the *history* of this change, 
other than having one or the other of us record a change that deletes the 
line that we added, then distributing that change around. I.e., I don't see 
how you can say "add this line, but delete that line it only if you apply 
the patch that fixes the problem elsewhere" in any sort of managable way.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message