On Fri, 14 Sep 2007, Blair Zajac wrote:
> C. Michael Pilato wrote:
> >In IRC, Dan explained to me that when designing the merge notifications,
> >especially for single-revision merge ranges, we needed a way to distinguish
> >between "merge -c M" and "merge -c -M". We use "merging" to describe most
> >merges, but for the reverse merge case, we decided to go with "undoing",
> >as in:
> >
> > Undoing r45
> >
> >I take issue with this verb because to "undo" implies that something must
> >have first been done, and frankly our client code doesn't actually have
> >sufficient awareness to make that claim. I can run 'svn merge -c REV' on
> >any arbitrary source and revision and apply that to any arbitrary location,
> >and while it may conflict like crazy, the operation will still be
> >attempted.
> > Does this mean I "undid" that change? Not hardly.
> >
> >Mark suggested "removing", but it has the same shortcomings. As does
> >"Un-merging", or any number of verbs which claim to be inverting the
> >results
> >of some presumedly previously performed action.
> >
> >I suggest that we conservatively call a reverse-merge what it is:
> >
> > Reverse-merging r45
>
> +1 on reverse-merging.
>
> Undo'ing could imply to somebody that the revision is removed from the
> repository, which of course, it isn't. So reverse-merge is the best choice.
I changed it as suggested in r26639.
We still need to either suppress this notification, or change its
text, for merges whose left and right sides aren't at the same URL
(e.g. for 'svn merge url1@revX url2@revY .').
- application/pgp-signature attachment: stored
Received on Mon Sep 17 21:56:54 2007