On Wed, Sep 10, 2008 at 05:30:38PM -0400, Karl Fogel wrote:
> The question at hand is, how should Subversion behave when it receives
> an update to a file that is already schedule-replace? (I realize as I
> ask this that it's sort of a tree-conflict issue.)
Yes, this is a tree conflict. 100%. Not even "sort of" :)
The real problem is that the original file was deleted.
The fact that a different file is now sitting at the same path is
actually unrelated (in theory, but possibly not in the implementation).
> Anyway, now we're back to my original question: what should happen?
>
> My answer is that the file should still be schedule-replace, still
> have revert-bases (and no regular bases), the revert-bases should have
> the new content. The working file should *not* be in conflict, but
> should simply have the same replacement text it had before the update.
>
> Does anyone think that's the wrong goal?
If what you're saying means that any text/prop modifications the update
wants to apply are not applied at all, then I agree that it is the right
goal for now -- the file the modification is destined for is gone, so we
can't modify the file anymore.
While not ideal, this behaviour is at least consistent with the current
behaviour of 'skipping' changes we can't apply during merge, and certainly
better than trying to apply a text-/prop-delta to a file the delta is not
destined for. The latter seems to be the current behaviour as far as
I could tell from your post.
Printing a warning ('Skipped missing/replaced target') might be a good idea.
In the long term, however, we'd want to flag a tree conflict, to make
really sure that the user is made aware of the fact that someone else
has concurrently modified a file which has been replaced locally.
Any attempt to commit from this conflicted state should then be blocked with
an appropriate error message. Users must be forced to consciously decide
what the merge result should be -- keep original file + mod, keep new file
as-is, keep original file as-is, keep new file + mod (if possible),
keep some arbitrary file containing content merged from new and old,
remove the file altogether, keep both new and old files under different
names, can't think of more possibilities right now but you never know
what users will want the result to be :)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-11 00:15:05 CEST