You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2007/09/14 19:05:35 UTC
[BIKESHED] Merge notification verb choices
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
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [BIKESHED] Merge notification verb choices
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 17 Sep 2007, Paul Burba wrote:
> > -----Original Message-----
> > From: Daniel Rall [mailto:dlr@collab.net]
> > Sent: Monday, September 17, 2007 3:57 PM
> > To: Blair Zajac
> > Cc: Michael Pilato; Subversion Developers
> > Subject: Re: [BIKESHED] Merge notification verb choices
> >
> > On Fri, 14 Sep 2007, Blair Zajac wrote:
...
> > > >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 .').
>
> We discussed this a bit on IRC and FWIW I'd like to see a generic
> notification in the two-URL case to keep it somewhat consistent with the
> single-URL case. Maybe something like:
>
> " --- Merging difference between unrelated URLs"
Since we don't bother to determine whether the URLs are actually
(historically) unrelated, I went with a somewhat similar message in
r26648. If someone has a better suggestion, I'm all ears.
RE: Re: [BIKESHED] Merge notification verb choices
Posted by Paul Burba <pb...@collab.net>.
> -----Original Message-----
> From: Daniel Rall [mailto:dlr@collab.net]
> Sent: Monday, September 17, 2007 3:57 PM
> To: Blair Zajac
> Cc: Michael Pilato; Subversion Developers
> Subject: Re: [BIKESHED] Merge notification verb choices
>
> 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 .').
We discussed this a bit on IRC and FWIW I'd like to see a generic
notification in the two-URL case to keep it somewhat consistent with the
single-URL case. Maybe something like:
" --- Merging difference between unrelated URLs"
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [BIKESHED] Merge notification verb choices
Posted by Daniel Rall <dl...@collab.net>.
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 .').
Re: [BIKESHED] Merge notification verb choices
Posted by Blair Zajac <bl...@orcaware.com>.
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.
<bl...@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