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