[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-19 03:09:28 CET

Greg Hudson wrote:

>On Fri, 2004-12-17 at 05:15, Branko ÄŒibej wrote:
>>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?
Sorry, I don't see the relevance here. The one is an API, the other is a
decision about GUI behaviour.

>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.
"Renames and branches but not copies." But I'm getting way out of the
domain of possible 1.x fixes. We can't have efficient forward searches
without a schema change anyway.

> I think backward tracing should
>follow renames and copies but not merges. Perhaps a join could be seen
>as a merge.
Theoretically speaking, a join has about as much in common with a merge
as a copy does with a branch. I hope to persuade people about the
importance of these differences before 2.0 gets set in stone, but since
that's a long way off, this may not be the right time.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 19 03:09:56 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.