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.
Blair
--
Blair Zajac, Ph.D.
<blair@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/training/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 15 00:36:18 2007