[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-04 00:14:53 CEST

On Tue, 03 Jul 2007, Giovanni Bajo wrote:

> On 03/07/2007 2.36, Daniel Rall wrote:
>
> >While this functionality could be delivered by piggy-backing on
> >existing sub-commands ('svn log' and 'svn info' have been considered
> >at length), discussion leads me to believe that we might be better off
> >introducing a new sub-command to deliver these features:
> >
> > svn mergeinfo --available-from=URL TARGET[@REV]
> > svn mergeinfo [-r ARG] [--merged-from | --merged-to] TARGET[@REV]
> >
>
> I guess TARGET defaults to ".", right?

Yup.

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

> That's fine, but I would also love the opposite: "show me all the
> (non-blocked) revisions available for merging from *ALL* the URL I've been
> merging with". That's a very useful command that's not available in
> svnmerge.py.
>
> [The scenario I'm thinking of is that of a shared library/module which is
> copied within several projects. Bidirectional merges are used to import new
> developments from the copies within the projects into the global shared
> module, and then propagate those changes them back into the other projects.
>
> In this scenario, the maintainer of the shared library/module needs to
> answer his SCM: please show me all changes in all projects that I might
> want to incorporate into the global shared module. This answer would
> require something like "svnmerge avail-all" which does not exist]
>
> 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.

> > $ 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. ;-) Also, see Karl's thread.

  • application/pgp-signature attachment: stored
Received on Wed Jul 4 00:14:46 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.