|
From: | Markus Schiltknecht |
Subject: | Re: [Monotone-devel] resolving name conflicts; file suturing vs drop |
Date: | Wed, 07 May 2008 10:21:47 +0200 |
User-agent: | Mozilla-Thunderbird 2.0.0.12 (X11/20080420) |
Hi, Thomas Moschny wrote:
[...] but: 0 file a exists / \ 1 3 file a is changed (differently in both 1 and 3) 2 4 file a is deleted (both in 2 and 4) \ / 5 6 file a is resurrected Which version should mtn resurrect? (it could ask the user, but we don't do that for other non-content issues, so what would be the default?)This is the well-known problem of delayed content-conflicts arising on file resurrection. It *is* a content-conflict, and must be propagated to the user. In your example, there are only two changes conflicting, but you can easily imagine a case with N conflicts having suddenly to be solved.
Does the user really want to resurrect a file just by its node id?You might even have renames, so that the file to be resurrected isn't currently visible. How's the user supposed to resurrect the file then?
Doesn't the user rather want to resurrect a file from a specific revision (possibly with a new target filename). That would make resurrection a simple copy, and we wouldn't need to carry on node ids forever.
In the above case, the user would then have to decide if he wants to resurrect file a from revision 1 or 3. If he really wants to keep *both* edits, he would have to resurrect both and then suture them...
Regards Markus
[Prev in Thread] | Current Thread | [Next in Thread] |