[darcs-users] Fwd: Towards a conflict-free revision control system.

Grant Husbands darcsusers at grant.x43.net
Fri Jan 16 19:41:35 UTC 2009


Jean-Philippe Bernardy wrote:
> 1. While "user-level" conflicts can indeed exist, and should be reported,
>  "internal" conflicts are just a nuisance.

However, "user-level" conflicts are what the user cares about. I'm
wary of the distinction between "internal" and "user-level" effects,
as it makes it hard for the user to maintain a complete mental model
of what is going on.

> 2. Cherry-picking or rollbacking /never/ fails. This is of course in
> the sense of point 1. above, and can even be considered a corollary of 1.

In my idea of a perfect version control system, a dependency could be
'resolved' in the same way a conflict is. In both cases, you
essentially have a patch whose dependencies you want to change by
presenting the missing pieces. Also, unlike in Darcs, conflict
resolutions would not combine badly with other conflicting patches.
So, the rational-position-with-magnitude way of things is not the only
one that provides a relatively simple answer. As I'm never going to
write such a version control system, though, these points may be moot.

> 4. Finally, I think that the "theory" backing up our system is a lot
> simpler than that of darcs. This alone might make it worth considering.

The theory behind the internal representation is, certainly, and that
is admirable.

>> it is more likely that the way Darcs handles conflicts is insufficient.
>
> My take is that the improvement should take a form similar to what we propose :)

Touché.

> You can always choose /some/ representation for this kind of cases.
[...]
> This particular representation might by bad, but my point is that it
> is not difficult to come-up with something.

I think it may be difficult to come up with something usable and
useful, though. I hope to be proved wrong, though.

>> [(a)->(b) + (c)->(d)  = ?]
> Fixing this sort of conflict (as conflict) could be done by either
> 1. replacing the text by what you want

Certainly reasonable.

> 2. applying "missing" patches

You may find it tricky to find them, as the version control system
doesn't know which they might be. It's certainly the best route,
though, if you can.

> 3. fiddling directly with the internal representation.

That sounds like something for the brave. A colleague has tried that
in Darcs, to work around Darcs bugs and rhe results of them, with
varying success. I presume you will present some kind of interface for
this, though, if you want users to do it.

>> [(a,e)->(a,c,e) + (a,e)->(a,n,t,e) = (a,n,c,t,e)], without warning.
>
> In some cases our system will happily produce an output, whereas you might
> want to see a warning. This is future work :)

I look forward to it.

> However, I'd like to point out that in these cases your
> editor/compiler/testsuite
> will most definitely report a problem. Having a VC-level warning is
> "just" faster/earlier in the chain.

It's just as likely that the compiler won't report a problem, I'd say,
as most such small changes would be within a function/method. However,
it's quite reasonable to not expect a version control system to spot
all conflicts/dependencies that cause non-compilation. It is hard to
know where to draw the line.

Regards,
Grant Husbands.


More information about the darcs-users mailing list