[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: Sun, 16 Aug 2009 14:01:21 +0100

On Sat, Aug 15, 2009 at 11:18:43AM -0400, Mark Phippard wrote:
> On Sat, Aug 15, 2009 at 10:40 AM, Stefan Sperling<stsp_at_elego.de> wrote:
> >> 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.
> I do not buy into this at all. There is no question that revert
> should also remove any mergeinfo changes on the target. If it didn't,
> then that would mean you could not revert ANY merge.

I agree that there is no technical problem.

> I also fail to see how this is confusing. If your normal merge patten
> is to merge all unmerged revisions (which is the basic scenario you
> are describing), then it makes perfect sense that you would need to
> use --record-only if there is a revision that you need to revert but
> do not want to keep merging in the future. I do not see any signs
> that users are confused by this part of merge.

It's more of a UI issue. People need to already know what you know to
arrive at these conclusions, and the UI as it is now is not giving them
a lot of hints.

Maybe a warning like this could help:

  $ svn revert foo.c
  svn: Warning: Reverted mergeinfo on foo.c,
       run 'svn merge --record-only -r2:4 foo.c' to keep the merge recorded.

This would be the most naive way to fix the UI a small bit.
Then again, it's hard to draw a line where to add such warnings and where
they'll just get annoying.


Received on 2009-08-16 15:02:12 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.