On Thu, Mar 27, 2008 at 6:11 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Another long monologue from me.
>
> Here is my recommendation, which basically aims to make this a safe and stable
> starting point for a feature which can later become more friendly but does not
> aim to be particularly friendly in the initial implementation. In fact the
> command-line invocation is intentionally a little verbose.
>
>
> SYNTAX AND EXAMPLE
>
> svn mergeinfo --show-revs=REVTYPE --from-source=SOURCE TARGET
>
> REVTYPE is "merged" or "eligible"
> SOURCE is URL[@PEGREV] or WC-PATH
> TARGET is URL[@PEGREV] or WC-PATH
I agree with you in principle, but Dan and I have been thinking and
talking about this since last summer. I think if you really stop and
think about it, it is obvious that log output is what someone wants
here. In my opinion, a list of revisions is useless. What script
would that possibly drive? If you are just going to feed them back
into a merge command, then that is a fairly useless script. svn merge
will already do this for you automatically by just omitting the
revision argument. Maybe you know you only want revisions over 1000
for some reason. OK, again, svn merge -r1000:HEAD will do this
automatically.
People are going to want to run this command so they can make informed
decisions about what to merge. Such as "have we nominated everything
for backport into 1.5 that needs to be". To answer those questions,
you want a filtered log. It does not make sense to have the command
already have all that information and just discard it when we know
that is what people want.
I agree with the no defaults approach. We can always add some later.
I am not sure defaults make sense for this command anyway.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-28 00:24:59 CET