'svn mergeinfo' and renamed branches.
From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-11-29 16:13:09 CET
So, I'm trying to work out the correct APIs and UI for 'svn mergeinfo' in
Imagine that in our own repository, all the work done on the 1.4.x branch
Already, we have two different interpretations of that request to deal with.
r26351-r28137: tags/1.4.5
But if you consider the whole lineage of that tag, well now you've got
r26351-r28137: tags/1.4.5
If we interpret the question in the first way (strict paths), 'svn
I kinda think 'svn mergeinfo' should interpret the question in the second
eligible = history(TGT) + mergeinfo(TGT) - history(SRC)
But now comes the UI question. If a user asks the question like so:
"What revisions along the history of /tags/1.4.5 can I merge into trunk?"
Does he want this list (ignore the particular layout ... that's not my point):
r26351-r28137: tags/1.4.5
or this:
r19524-r28137: tags/1.4.5
The former is kinda nasty-looking, but reflects real locations. If he
The latter is concise, but doesn't indicate that /tags/1.4.5 has been
So ... what to do? I don't have a strong opinion about this because I'm not
-- C. Michael Pilato <cmpilato@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
|
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.