[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: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-07-03 03:04:31 CEST

Daniel Rall <dlr@collab.net> writes:
> 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]

"--available-from" is a synonym for "--unmerged-from", right?

By the way, why don't URL take an @REV qualifier in the first example?
If the --merged-from target in the second example can take @REV, I
would have though URL in the first example could too.

I'm not sure what the semantics of the "-r ARG" are.

> The output of "Change Set Merge Availability" will look like that of
> 'svn log'. The semantics will be slightly different, listing logs
> from URL instead of from TARGET.

Have we considered piggy-backing on 'svn merge' itself?

   1. svn merge --info-unmerged FROM_URL TARGET[@REV]
   2. svn merge --info-merged-from TARGET[@REV]
   3. svn merge --info-merged-to TARGET[@REV]

In fact, even if the subcommand were "mergeinfo", I would still like
to offer the above option structure for consideration.

> The output of "Find Change Set" will include merging revision, URL,
> and range list:
> $ 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

For a moment I almost proposed "r30-r57", but I guess that takes up
too much horizontal space (and is completely idiosyncratic).

> $ svn mergeinfo --merged-from /branches/featureX
> At r14, merged r3-7, r13 from /branches/featureX to /trunk
> $ svn mergeinfo --merged-to -r37
> At r60, merged r30-57 from /branches/featureY to /trunk
> $ svn mergeinfo --merged-from -r37
> At r60, merged r30-57 from /branches/featureY to /trunk
> $ svn mergeinfo --merged-to -r37 /trunk
> At r60, merged r30-57 from /branches/featureY to /trunk
> $ svn mergeinfo --merged-from -r37 /trunk
> (Nothing was merged *from* /trunk in r37, only *to* it.)

In real life, these lines are very often going to overflow 80 columns.
Perhaps we should declare now (for parsers) that whitespace at the
beginning of a line means a continuation line, and format like this...

    $ svn mergeinfo --merged-from /branches/featureX
    At r14, merged r3-7, r13
     from /branches/featureX
     to /trunk

...whenever the result would otherwise overflow 75 or whatever

> The only other viable alternative would be to introduce multiple new
> sub-commands: one to handle the path/revs output by
> --merged-from/--merged-to, and another to handle the 'log'-style
> output from --available-from. This offers the benefit of consistent
> output from a sub-command regardless of the options it's passed
> (arguably similar to the modal behavior of --xml), but has the obvious
> down-side of introducing yet more sub-commands that a user must wrap
> their head around.

You have been working on and thinking about this far more than I, but
the words "only other viable alternative" still make me nervous... :-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 3 03:04:25 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.