[RFC] Merge History Audit and Query

[Daniel Rall <dl...@collab.net>]

http://subversion.tigris.org/merge-tracking/func-spec.html#merge-history-audit

While Hyrum is looking at the "Commutative Author and Revision
Reporting" features, I'd decided to take a look at spec'ing out some
of the other auditing features.  Specifically:

- Show change sets available from a merge source.

- Show where a change set has been merged to.

I'm considering the following command-line UI for these features:

svn info --merged-to [SOURCE@REV]
Show a list of merge targets (URL@REVs) that SOURCE has been merged to.

svn info --merged-from [TARGET@REV]
Show a list of merge sources (URLs) and corresponding revision range
lists that have been merged into TARGET.

Alternately, we could add a new 'svn audit' (or some such)
sub-command, instead of re-using 'svn info'.  Thoughts?

Re: [RFC] Merge History Audit and Query

[Mark Phippard <ma...@gmail.com>]

On 5/23/07, Daniel Rall <dl...@collab.net> wrote:
> http://subversion.tigris.org/merge-tracking/func-spec.html#merge-history-audit
>
> While Hyrum is looking at the "Commutative Author and Revision
> Reporting" features, I'd decided to take a look at spec'ing out some
> of the other auditing features.  Specifically:
>
> - Show change sets available from a merge source.
>
> - Show where a change set has been merged to.
>
> I'm considering the following command-line UI for these features:
>
> svn info --merged-to [SOURCE@REV]
> Show a list of merge targets (URL@REVs) that SOURCE has been merged to.
>
> svn info --merged-from [TARGET@REV]
> Show a list of merge sources (URLs) and corresponding revision range
> lists that have been merged into TARGET.
>
> Alternately, we could add a new 'svn audit' (or some such)
> sub-command, instead of re-using 'svn info'.  Thoughts?

While I like info as the sub-command name, it is taken already and I
am not a huge fan of overloading the meaning of a subcommand.

One could argue that this is also overloading a command:

svn audit --merged-from
svn audit --merged-to
svn audit --blocked
svn audit --available

But at least it is consistent.

I'd like to see us use something like "mergeinfo" over "audit".
Something that ties it to merge.

It seems like there is a lot of potential for general commands/options
to better query or report on the repository.  audit might be a good
subcommand to use for that depending on what we come up with.  I fear
that if we do not use a subcommand name for this that is tied to merge
in its name, then the options are going to have be really long.  For
example what does this mean:

svn audit --blocked

When the audit command does additional things besides report on merge
info?  It would have to become:

svn audit --blocked-revisions

or

svn audit --blocked-revisions-from-merge

Maybe we should overload the merge command if we are going to pick one?

I do not feel strongly about this.  I am trying hard to pick one and
advocate for it.  I have seen good arguments on both sides.

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