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