On 9/19/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> > 2) He writes out full URL's. The svn:mergeinfo property uses
> > relative URL's (for good reason). I understand why he is using full
> > URL's. I think the output would be more readable if it was relative
> > to the root. I would not change the API, just the CLI output. I do
> > not feel strongly about this.
>
> Eh. Whatever. Maybe this will be an excuse to expose an
> svn_client_repos_root_url() function, then. :-)
Like I said, I do not feel strongly. I just find the truncated format
easier to digest.
> > Something that would be both consistent and inconsistent at the same
> > time would be to use the "new format" for reporting merged revisions,
> > and the "old format" for the eligible ranges. This would allow the
> > eligible revision range to be passed directly to svn merge if desired.
> > This might sound stupid, maybe it is, but I think it does make some
> > sense from a user perspective and overall consistency.
> >
> > Here is what the above output would look like:
> >
> > $ svn mergeinfo .
> > Path:
> > Merge source: /trunk
> > Merged revisions: 1-4, 9, 13-16, 22
> > Eligible ranges: r4:8, r9:12, r16:21, r22:25
>
> [...]
>
> > And for completeness, here is what it would look like if we simply
> > used the "new format" for both:
> >
> > $ svn mergeinfo .
> > Path:
> > Merge source: /trunk
> > Merged revisions: 1-4, 9, 13-16, 22
> > Eligible revisions: 5-8, 10-12, 17-21, 23-25
>
> I've no problem with this latter format over what's in there now, but the
> inconsistent output of the first proposal is no good. You've made the
> assumption that folks will copy-n-paste the eligible ranges but not the
> merged ones, and frankly that assumption is bogus. I'm just as likely to
> run 'svn log' on a range of merged revisions as I am to run 'svn merge' on a
> range of not-yet-merged revisions, so using two different formats doesn't
> strike me as anything but confusing.
If the goal is cut and paste, it seems like my first proposal is the
best one, with the exception that we should use ":" instead of "-" as
the values in that proposal are what you would need to paste into log
(in the case of merged revisions) and merge (in the case of eligible
revisions.
It'd be cool if you could do this and get the exact results back efficiently:
svn log -r 1:4, 9, 13:16, 22
Then you could truly paste the results.
I assume that regardless of the changes to the output, the actual
underlying API is sort of set now and could be exposed via JavaHL?
Finally, should we consider an option that suppresses the revisions
that occurred prior to the creation of the target? In the example
above, the branch was created in r5, which primed it with trunk 1-4.
Should those show as merged revisions in this command?
--
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
Received on Wed Sep 19 23:15:34 2007