>> http://koweycode.blogspot.com/2011/04/why-darcs-users-care-about-consistency.html
>
> Thanks. That's interesting.

Interesting, disturbing, whatever you want to call it. ;-)

All describing problems I've never come across. Then again, when your 
development team consists of one person...

> """
> The most well-known remaining cause of blowups in theory 2 is the
> problem of "conflict fights" where one side of the conflict resolves the
> conflict and gets on with their life without propagating the resolution
> back to the other side.
> """

Given the entire purpose of *distributed* revision control... yeah, that 
would be a problem. (Exponential-time merge worries me more though.)

> This is basically the source of the mess in git, also. In the whole blah
> going on here: http://bramcohen.livejournal.com/74462.html I'm not sure
> I can understand how presenting that work as a set of patches makes
> sense. You'd wind up with a repository that changes A into B twice and B
> into A once without any particular ordering between them, so I'm lost as
> to how Darcs would handle that.

You understand that Darcs *does* have an ordering between *related* 
patches, right? It's only *unrelated* patches that have no order 
relationship. I can flip the same line of code back and forth 20 times, 
and record that as 20 patches, and they will have a strictly linear 
ordering.

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

Post a reply to this message