On Wed, Jun 12, 2013 at 8:40 PM, Joseph Gentle <jose...@gmail.com> wrote:
> On Wed, Jun 12, 2013 at 11:30 AM, Bruno Gonzalez (aka stenyak)
> <sten...@gmail.com> wrote:
> > On Wed, Jun 12, 2013 at 8:19 PM, Joseph Gentle <jose...@gmail.com>
> wrote:
> > I was under the impression that darcs could handle all edge cases that
> > even git can't handle (e.g. the 'bug' where merging patch-by-patch in git
> > can result in different final status, than merging several patches at
> > once), and actually that darcs had no known edge cases.
>
> Really? Maybe I don't understand darcs as well as I thought. @Michael?
>
>
I know it fixes some merging problems that most other DVCSs (like, at
least, mercurial and git) suffer from. Not sure if it's the bestest dvcs in
the world, but with regards to merging, it's certainly one of the best (if
not the best).
As a curiosity, it also supports non-diff patches, which is something I
*think* is unique to darcs.
E.g. we're used to patches that look like unified diffs. In darcs, a commit
does not necessarily use diffs like that, but can use (at least) a type of
patch that consists of an order, which reads "replace word X by word Y in
file Z and T" (just that literal sentence, encoded somehow). So when you
rename a variable, and at the same time other person adds a new line using
the old variable name, there's no conflict, it's resolved automatically.
Anyway, this is all from what I've read, I haven't really dug into the math
itself.
> Also, you mention that using OT you don't need conflict markers. Does
> this
> > mean that OT guarantees no conflicts at all, ever? If so, and this is
> just
> > pure curiosity, does this mean that OT could be the ultimate underlying
> > system to use by distributed version control systems?
>
> You actually *want* conflicts in a version control system. If we both
> independantly edit the same line of code, we've probably messed
> something up. For example, if we both delete a line and rewrite it,
> using the OT systems I know of, the text gets deleted but you end up
> with both rewrites in the final document. This probably isn't what you
> want.
>
> A conflict-free system is perfect for live editing (you'll fix any
> problems at arise while you edit), but we might want to add conflicts
> back in before making a kickass VCS on top of this stuff.
>
My assumption was that conflicts were simply mathematically inevitable in a
DVCSs, that's why your mention about lack of conflict markers sparked my
interest... you mention conflicts like they can be optional? If so, are
conflicts "eliminated" by choosing an arbitrary merging strategy when
conflicts *do* happen (e.g. "choose the last timestamped patch and lose
information on the way, we don't care"), or can they be prevented from ever
happening in the first place?
--
Saludos,
Bruno González
_______________________________________________
Jabber: stenyak AT gmail.com
http://www.stenyak.com
