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

[Jean-Philippe Bernardy]

On Fri, Jan 16, 2009 at 8:41 PM, Grant Husbands
<darcsusers at grant.x43.net> wrote:
> 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.

Making the VC system easy to understand
is our main goal.

I believe that VC systems that work directly
on the text presented to the user have algorithms that are full of heuristics
and thus in practice impossible for the user to build a mental model.

A clever internal representation should allows for a trivial merge (easy to
understand). The conversions from/to the external representation should also be
easily understandable. (Darcs is a step in this direction compared to
all other,
state-based systems).

>> 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.

The rational-position-with-magnitude, as you put it, is indeed only one way to
implement the algebraic structure that allows for universal commutation
of patches. My current intuition is this implies the structure is a free abelian
group. While I hope that somebody will come up with something better than
rational-position-with-magnitude, it has the merit to be implemented in a
prototype for experimentation :)


>>> [(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.

That's another area of improvement. It's not unreasonable to invent an algorithm
that searches for patch sets that might solve the conflict.

>> 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.

Absolutely.

>>> [(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.

Maybe next year's student will be happy to take it :)

Cheers,
JP.