On Thu, 2008-09-11 at 00:14 +0200, Stefan Sperling wrote:
> 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
What he said.
Plus, note that (AFAIK) the replacement file is expected to have
".svn-base" base files iff it was created as a copy of something. If I'm
right about that (I haven't checked), just be careful not to assume that
there will be no such base files.
- Julian
---------------------------------------------------------------------
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 15:04:38 CEST