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

Re: [RFC] Merge History Audit and Query

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-05-24 01:13:32 CEST

On 5/23/07, Daniel Rall <dlr@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


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.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 24 01:13:43 2007

This is an archived mail posted to the Subversion Dev mailing list.