Re: Remaining Merge Tracking auditing features for 1.5

On 7/2/07, Karl Fogel <kfogel@red-bean.com> wrote:
> 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 think it does, and he was just simplifying it.

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

It probably applies more to --merged-to, but it would be saying where
has this been revision been merged? Imagine, you make wanted to what
branches that the BDB repository corruption fix had been merged to.

You can get the --merged-from for a single revision using svn diff,
but this is a more convenient option and adds some symmetry.

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

I made a similar proposal. Dan did not like it. I imagine it is
because it is asking a command to do something completely different.
It would almost be like asking commit or update to show log
information. I will let Dan provide more reasons.

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

I think we went through this when discussing sussman's output for
notifications and settled on the format Dan is proposing.

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

I like that idea.

> ...whenever the result would otherwise overflow 75 or whatever
> columns.
>
> > 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... :-)

I think I might have put those words in his mouth, so you can forgive
him. Obviously it is not the only viable alternative. I think Dan
and I just have too much "shared context" on this issue where we have
discussed many of the alternatives and anticipated the rejections.

For example, neither of us love the idea of overloading this command
and also providing different output formats, but somehow it felt
better than overloading a long existing command (log), overloading and
changing the output of a long existing command (info) or completelty
re-purposing an existing command (merge). We also know that there is
a lot of rightful resistance to adding sub-commands, so we tried to
limit this to just one.

Here are some links to past discussions on some of the alternatives:

http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=127104
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=127603

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org