C. Michael Pilato wrote:
>I remember chatting about this feature in the past. It's certainly
>do-able. And seems useful, too.
>
Heh, last time I tried to convince people that node history is a DAG,
not a tree, I got shot down on the grounds that "you get the same effect
by merging the contents then deleting the branch". :-)
> The complication that I see is that
>your destination file will have a fork in its ancestry, which means
>that answer questions like, "What did this line of history look like
>in <some revison prior to the join>?" kinda complicated. Does the
>answer include data from both tines of the fork (or all N of them,
>right -- this operation can commute)?
>
>Not that this is a new problem. We have the problem today, in trying
>to answer "What does this line of history look like in <some revision
>after a copy/branching operation>?"
>
>
Not exactly, IIRC we ignore branches when tracing node history forwards;
that is, svn_repos_trace_node_locations returns only one path per
revision, searching only the branch defined by teh fs path and peg. I
argued that it should return a set of paths per revision, but got shot
down there, too.
But anyway, I think this is _not_ doable without a schema change. As you
might have guessed, this kind of schema change is bubbling away in my
pot of ideas for 2.0. But it'll be a while yet before /that/ gets
served. :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 17 11:16:30 2004