[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: David James <djames_at_collab.net>
Date: 2006-03-25 18:53:35 CET

On 3/25/06, Giovanni Bajo <rasky@develer.com> wrote:
> 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.
> """

I definitely like these new names. "--manual" describes the use case:
I did a manual merge; please update the merge metadata for me.
"--record-only" describes what svnmerge.py actually does -- it records
that we already did a manual merge. Both names are good, with the
first being shorter, and the second being slightly more clear. Like
you, I tend to favour clarity over brevity.

> 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.
> """

Very clear. Great! Thanks for writing this documentation as it will be
very helpful for users.

Should we also refer back to the "block" subcommand, which allows you
to ask svnmerge *not* to merge a particular set of revisions? In some
cases, if you didn't exactly "merge" the revision but the
functionality is available on the branch with similar code, it might
be tough to choose between the two.

We may want to mention somewhere that svnmerge.py does not record
"indirect" metadata (i.e. it does not record that, if you merge a
change from branchA to branchB, you might indirectly be merging
changes from trunk). For now, you can correct this metadata using
merge --record-only. In future, it might be possible for us to be a
bit better about merging the indirect metadata, but I don't think
we'll ever get it perfect, so this feature will always be handy.

> 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".

Great! Good idea to refer back to "--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.

Really? Why would --record-only allow svnmerge.py to behave more
correctly? I find this sentence a bit confusing. I think we should
simply say that "--record-only" records that a merge happened, whereas
"block" records that a merge should not happen.

Cheers,

David

--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 25 18:53:55 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.