On Nov 29, 2007 10:13 AM, C. Michael Pilato <cmpilato@collab.net> wrote:
> Does he want this list (ignore the particular layout ... that's not my point):
>
> r26351-r28137: tags/1.4.5
> r26346-r26350: branches/1.4.5
> r25343-r26345: tags/1.4.4
> r19524-r25188: branches/1.4.x
>
> or this:
>
> r19524-r28137: tags/1.4.5
>
> The former is kinda nasty-looking, but reflects real locations. If he
> wanted to, the user could do four merges of exactly those ranges, in
> oldest-to-youngest order, and get what he expected.
>
> The latter is concise, but doesn't indicate that /tags/1.4.5 has been
> through any renames. That said, if the user wanted to, he could do a single
> merge of this range and it would work. And as long as his peg revision was
> young enough, he could even cherry-pick revisions from this range where the
> history lived somewhere besides /tags/1.4.5.
>
> So ... what to do? I don't have a strong opinion about this because I'm not
> a big fan of the subcommand in the first place. (I just don't anticipate it
> being used very much.) But there's an API behind this subcommand that needs
> to do the right thing, and that's really where my concern is.
It would be great if I could give you some rationale behind my answer,
but not sure I can. I'd prefer the second, concise format. I guess I
think of it from the perspective of a GUI. I ultimately just want to
get a set of revisions I can show the user and let them select what
they want to merge. It is not a lot different than running svn log on
the path. Basically, it is log with a filter applied. So I'd vote
for the second, simpler format:
r19524-r28137: tags/1.4.5
--
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 Thu Nov 29 16:32:15 2007