[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-12-17 18:25:04 CET

On Fri, 2004-12-17 at 05:15, Branko ─îibej wrote:
> Not exactly, IIRC we ignore branches when tracing node history forwards;

We don't trace node history forwards, because we have no efficient way
of doing so. We have a heuristic where we check that <peg-rev,path> and
<new-rev,path> refer to the same object, and return <new-rev,path> if it

> 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.

You "got shot down" partly because this is an incomplete proposal.
svn_repos_trace_node_locations could return multiple paths, but what
would be the behavior of "svn cat -r10000 url@9000" if it does so? Do
we get a copy of url on the trunk and every branch which has been
created between 9000 and 10000?

I argued that we should have true rename support, and forward tracing
should follow renames but not copies. I think backward tracing should
follow renames and copies but not merges. Perhaps a join could be seen
as a merge.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 17 18:26:38 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.