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

Re: Remaining Merge Tracking auditing features for 1.5

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-07-05 22:04:08 CEST

On Wed, 04 Jul 2007, Giovanni Bajo wrote:

> On 04/07/2007 0.14, Daniel Rall wrote:
> >>In that case, I assume that a bare "svn mergeinfo" means "show me all
> >>revisions that have been merged into the current trunk".
> >
> >So, a bare 'svn mergeinfo' defaults to 'svn mergeinfo --merged-to .'
> >
> >While I like that a lot, the UI would be inconsistent with our other
> >sub-commands, which don't have a "default behavior" for which they
> >also have a long option. I'm +1 on the behavior, but we need to alter
> >the UI for consistency with other sub-commands.
> I understand your concern. I think this command better describe my vision:
> svn mergeinfo [-r ARG] [--from URL[@REV]] TARGET[@REV]

  svn mergeinfo [-r ARG] [--from URL[@REV]] [--xml] [TARGET[@REV]]

> So basically:
> * "svn mergeinfo": show all the merges into the current directory
> * "svn mergeinfo foo": show all the merges into foo
> * "svn mergeinfo --from=bar foo": show all the merges from bar into foo
> Does this sound better? Or am I still missing something wrt your original
> mergeinfo proposal?

This example provides an excellent interface for determining "merged
from" information. However, it doesn't accommodate ease of discovery
of "merged to" information.

Use case: I have a set of live branches still under maintenance, and I
want to know where I've backported a bug fix to. Rather than going to
each branch and asking about the bug fix's change set, I want to just
ask the repository where the change set has been merged to.

What were you thinking for 'svn mergeinfo --merged-to'?

> >>So, my own suggestion is to use two different commands. I don't think
> >>that's harder on users than having a single command with two
> >>totally-different meanings, triggered by special options on the command
> >>line. On the contrary, I think it's easier for them.
> >>
> >>svn mergeinfo [-r ARG] [--merged-from | --merged-to] TARGET[@REV]
> >>svn mergeavail [--from URL] TARGET[@REV]
> >
> >So, a bare 'svn mergeavail' would show available revisions for all
> >paths which have been merged into TARGET? That sounds very useful.
> Yes. Indeed it is.

I'm really leaning towards adding more sub-commands to handle this
features. Anyone else have thoughts on this?

> >>> $ svn mergeinfo --merged-to /trunk
> >>> At r14, merged r3-7, r13 from /branches/featureX to /trunk
> >>> At r60, merged r30-57 from /branches/featureY to /trunk
> >>Please, use an output which is *very* machine-oriented. Most users will
> >>be better off using a graphical merge tool anyway (what's "r14", "r3",
> >>"r13"? A graphical merge tool can just show you those graphically).
> >
> >Do you find --xml to be insufficient (or do you just not like XML)?
> >(I wouldn't blame you for that. ;-)
> No, XML is perfectly fine for me. I had not understood it was implied that
> --xml existed :)

Gotcha. I think we have it for most client sub-commands that report
information to the user. Adding it for merge info auditing/reporting
will be trivial.

> In fact, I really prefer parsing XML that an under-specified format like
> (eg) that of a normal "svn log". I wonder how many people failed into the
> trap of parsing "svn log -v", and realizing after some time that they
> failed to take into account the copyfrom info :) [ it happened *twice* to
> me ]. Or, even easier, parsing "svn st" and crashing because of
> svn:externals :) This kind of parsing mistakes just can't happen with XML.

I do find XML to suite this particular case quite well.

  • application/pgp-signature attachment: stored
Received on Thu Jul 5 22:04:07 2007

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.