[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
From: |
Markus Schiltknecht |
Subject: |
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop |
Date: |
Thu, 08 May 2008 13:09:37 +0200 |
User-agent: |
Thunderbird 2.0.0.12 (X11/20080227) |
Hi,
William Uther wrote:
An example: how is bob expected to resurrect a file "foo", which got
overridden by another node id which is now called "foo". I can only
think of something like "take file 'foo' from rev '1234..' but name it
'bar'", which will quite certainly make bob become crazybob.
That looks much like subversion's copy feature. I think that would make
merging hard for monotone. It is a complete break with the current
'mark-merge' philosophy.
I was trying to say that it's hard for the user to specify which node id
she wants to resurrect, in case its filename got reused by another node.
It's an argument against concentrating on node ids, and has not much
to do with the implementation.
All three problems (resurrection, suturing, and copying) will need to
establish some sort of connection between node identities in the
graph (resurrection: 1->1, suturing: N->1, copying 1->N).
This isn't totally correct. You need the node-id's you're talking
about, but you also need the marks for mark-merge. As has been noted by
Thomas in another email, the problem with resurrection isn't with
finding the node-id, it is with being able to get the marks when you
later do the merge. At the moment we don't keep the marks when we drop
a file.
With suturing + copying, as I'm envisioning, we don't need to keep them.
Good line of thinking, that makes my point even clearer: we won't need
resurrection, once we have suturing and copying. Because 1->1 can
easily be achieved by 1->N->1.
er, not necessarily.
It depends on whether dropping is seen as a separate thing to identity
(in the copy-suture sense of identity) when doing a mark-merge. There
is also the issue that if N = 0, then you need to have a graveyard to
hold the marks. This whole 1->N notation is nice, but it is a
simplification and doesn't catch all the details.
I'm not following you here. IMO, 1->N is a generalization, which we
don't need. 1->2 is absolutely enough, because we can simply repeat that
to get 1->N (for N > 2).
We already have 1->0 and 0->1: that's simply add and drop.
And I'm currently concluding that the 'single bit aliveness flag per
node id' is overly complex for us and for the end user, while suturing
and copying might achieve pretty much the same effect.
A 'single bit aliveness flag' is a simple re-use of mark merge. It will
mean that aliveness has the same semantics as rename, move, and almost
everything else that monotone merges. This should be a good thing for
using understandability.
..but a bad thing for content merges, which can get delayed - so one
potentially needs to do multiple merges before having resurrected a
file. And not to forget about the problem of having to keep the node ids
forever.
Suturing is tricky. We have no agreed mechanism for implementing it
(yet). And even if we did, none of the mechanisms I'm thinking of
would, by themselves allow you to resurrect a file. Suturing and
resurrection interact, but they're not simple substitutes for each other.
I still disagree in that copying+suturing can be a replacement for
resurrection (but certainly not the other way around). See my lengthy
other mail in answer to Thomas, where I'm giving examples of how that
might work.
Regards
Markus
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, (continued)
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Patrick Georgi, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/08
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop,
Markus Schiltknecht <=
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Matthew Nicholson, 2008/05/08
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/08
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/08
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/08
- [Monotone-devel] Graveyards vs reconstruction for liveness merging (was: resolving name conflicts; file suturing vs drop), William Uther, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/07