[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: tree conflicts with replace

From: Stefan Sperling <stsp_at_elego.de>
Date: Sat, 15 Aug 2009 15:40:08 +0100

On Fri, Aug 14, 2009 at 05:14:42PM +0200, Neels Janosch Hofmeyr wrote:
> Stefan Sperling wrote:
> > On Fri, Aug 14, 2009 at 04:16:30AM +0200, Neels Janosch Hofmeyr wrote:
> >> So, someone merges from a branch, gets a conflict with an incoming replace.
> >>
> >> The 'revert' step is then useful as a resolving strategy of "wipe, get a
> >> clean slate, re-apply local changes manually". In that case, the merge would
> >> be carried out and recorded correctly.
> >
> > Unless maybe if the file has explicit mergeinfo?
> Well, incoming mergeinfo should be preserved. If there is explicit mergeinfo
> uncommitted in the working copy, sure. But isn't that what "revert" is
> supposed to be?

Say you have a file which ends up having explicit mergeinfo after a merge
of rX to your merge target. The parent's mergeinfo does not list rX,
but the file's mergeinfo now *does* list rX (locally in the WC).

Say also that you don't want the change rX made to that file.
You just want the version that's already in the merge target.

If people expect to use 'svn revert' as part of a conflict resolution
process after a merge, and 'svn revert' deletes mergeinfo property
changes on the file as well as the merged content changes, the merge
won't be recorded.

So, in other words, you have thrown away changes the merge brought in,
and you don't ever want them again because they conflict entirely with
your own changes. But because the mergeinfo on the file is also gone,
next time you merge, you get the same changes merged to the file again.
So you 'svn revert' the file again to get rid of the changes the merge
brought in. Again, the mergeinfo property changes also get revert.
It's an endless cycle.

  $ svn merge -c3 ^/trunk/alpha alpha
  --- Merging r3 into 'alpha':
  U alpha
  $ svn st
  MM alpha
  $ svn pl alpha
  Properties on 'alpha':
  $ svn revert alpha
  Reverted 'alpha'
  $ svn pl alpha

Unless people realise that the way to break the cycle is another
--record-only merge to the file in order to restore the mergeinfo
before commit. But I'd say no one will remember to do this.

  $ svn merge --record-only -c3 ^/trunk/alpha alpha
  $ svn st
   M alpha

> What are we discussing, again?

I don't know. I just stumbled into this discussion because for some
reason what I read here made me realise that the above problem exists.

When people hit this, and don't understand how the mergeinfo stuff
and 'svn revert' work, they will probably not realise that the real
problem is that they don't understand enough of the internal workings
of the tool and lack the corresponding insights into the tool's limitations
to be capable of dealing with the limitation they just hit.
And then they will [rightfully] blame Subversion for the problem,
i.e. they will blame us for not having fixed this limitation.


Received on 2009-08-15 16:41:07 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.