[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Svnmerge] [PATCH] Add ability to mark change sets as merged

From: Giovanni Bajo <rasky_at_develer.com>
Date: 2006-03-25 10:57:54 CET

Daniel Rall <dlr@collab.net> wrote:

> This is effectively a way to manipulate the merge memory stored in the
> "svnmerge-integrated" property. It's the flip-side of the 'block'
> concept.

Hi Dan, thanks for the patch. It looks ok.

I don't specifically like the name of the option nor the documentation. I
thought of "--manual": what people think of it? I'm not really satisfied with
it either. "--record-only" is longer but possibly better? I don't think it's
too long as I don't expect it to be used so commonly to justify the need of a
shorter name (and there's the single-dash letter version anyway). [BTW, I don't
care about the single-dash letter, -M: that's always a non-informative
non-mnemonic version of the option, so really any letter works).

So a proposal:

"""
--record-only: do not perform an actual merge of the changes, yet record that a
merge happened.
"""

As for the main description at the top:

"""
When manually merging changes across branches, --record-only can be used to
instruct svnmerge that a manual merge of a certain revision already happened,
so that it can record it and not offer that revision for merge anymore.
"""

I'd also add a note to the svnmerge block help page:

"""
Do not use this option to hide revisions that were manually merged into the
branch. Instead, use "svnmerge merge --record-only". The immediate effect is
the same (the revision is not available for merge anymore), but the behaviour
will be more correct with respect to merge across multiple branches.
"""

Giovanni Bajo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 25 10:59:08 2006

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.