[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Possible new feature

From: Branko ─îibej <brane_at_xbc.nu>
Date: 2004-12-17 11:15:59 CET

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

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.