[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: Deterministic *-merge
From: |
Nathaniel J. Smith |
Subject: |
Re: [Monotone-devel] Re: Deterministic *-merge |
Date: |
Fri, 12 Jan 2007 18:14:26 -0800 |
User-agent: |
Mutt/1.2.5.1i |
On Fri, Jan 12, 2007 at 04:53:45PM -0800, Oren Ben-Kiki wrote:
> One last question :-) Is the idea that the '#' nodes be completely
> virtual? That is, if I have two actual versions in monotone, one with a
> value of 'a' and one with a value of 'b', and I try to merge them...
> what would happen in practice?
>
> The simplest way would be to force the user to resolve every '#' to a
> specific value (just like he does today when there is a conflict), so in
> the monotone repository we would see:
>
> a* b*
> \ /
> c*
>
> Only during the merge algorithm the graph would be considered to be:
>
> a* b*
> \ /
> #
> |
> c*
>
> So all the '#' nodes would only exist virtually, never in a real
> version. If that's the case, then the example of merging two '#' nodes
> would be impossible to construct in practice.
>
> The more complex alternative would be to allow '#" values in real
> versions. This would allow merging two '#' nodes to cleanly remove the
> conflict, but it would also require some way of actually representing
> '#" values inside text files.
It would also require some way to actually define # for text files --
this algorithm has only been written down for scalars ATM :-).
Anyway, the answer to your question is that I'm not proposing anything
at all change in monotone -- that's why I said at the beginning of the
writeup that my note had no practical consequences :-). We've
generally taken the line that the history graph should attempt to
model as closely as possible the user's intrinsic understanding of
"versioning a bunch of files", because this is the both the most
user-friendly and the most future-proof approach. (Sucks to build a
particular merge algorithm's assumptions into your hash-chained
history graph, and thus be stuck with that merge algorithm for a few
decades...)
That said, I dunno, maybe someone will figure out how to use this kind
of stuff to improve VCS UI -- it's just some ideas, who knows what
will happen to them once they start wandering around in people's
heads...
-- Nathaniel
- [Monotone-devel] Deterministic *-merge, Nathaniel J. Smith, 2007/01/12
- Re: [Monotone-devel] Deterministic *-merge, Oren Ben-Kiki, 2007/01/12
- [Monotone-devel] Re: Deterministic *-merge, Timothy Brownawell, 2007/01/12
- [Monotone-devel] Re: Deterministic *-merge, Oren Ben-Kiki, 2007/01/12
- [Monotone-devel] Re: Deterministic *-merge, Timothy Brownawell, 2007/01/12
- [Monotone-devel] Re: Deterministic *-merge, Oren Ben-Kiki, 2007/01/12
- Re: [Monotone-devel] Re: Deterministic *-merge,
Nathaniel J. Smith <=
- Re: [Monotone-devel] Re: Deterministic *-merge, Oren Ben-Kiki, 2007/01/13
- [Monotone-devel] Re: Deterministic *-merge, Lapo Luchini, 2007/01/23
Re: [Monotone-devel] Deterministic *-merge, Justin Patrin, 2007/01/12
Re: [Monotone-devel] Deterministic *-merge, Florian Weimer, 2007/01/12
[Monotone-devel] a little *-merge history, Lapo Luchini, 2007/01/23