Quoting Greg Hudson <ghudson@MIT.EDU>:
> On Wed, 2004-03-31 at 21:37, Branko Čibej wrote:
> > I have a problem with this patch: it only looks in the _past_. That
> > restriction is unnecessary (and evil :-), you should be able to peg
> > /foo/bar/baz@100 and ask where it is at revision 200.
>
> We discussed this in the earlier (pre-1.0) thread. Consensus was that
> we can't trace into the future across renames of the file or its
> parent directories (because all copies look the same, whether or not they
> were renames, and even if there's only one copy of the same node in the
> target rev, it's too hard to find given the current FS schema), but we
> can check if <future-rev,path> is the same node-copy, and use that if so.
Yes I know the current schema doesn't support the forward search, but the _API_
should allow it. Adding forwarrd pointers to the history graph isn't that much
of a big deal as far as schema change is concerned, and could theoretically be
done in the 1.x line, or a different backend could add them. If the function
returns "sorry not implemented" for peg < target, that's fine for now.
A search into the future can obviously return more than one path.
(Theoretically, so can a search into the past, because in general, logical node
history is a DAG, not a tree.) In both cases it is possible to select "the"
correct node version (and path) if branches aren't considered equal.
Anyway. I propose that the API allows searches in any direction, and to
optionally return a list of paths. For example,
svn_fs_get_node_paths(path="...", peg=HEAD, target=HEAD, all=TRUE)
would return all the branches that the node currently exsists on. Cute.
> but "svn_fs_get_node_path" sounds likea simple FS operation.
There's no reason why it shouldn't _be_ a simple operation. The fact that our
schema currently makes it a total pain is embarrasing, but irrelevant.
(Sorry if the above seems like a rant, but we're past 1.0 now and no longer in
the "make it work" mode. We've made enough unfortunate API decisions based on
incomplete models as it is. Whilc this was excusable before 1.0, IMHO it no
longer is.)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 1 15:54:59 2004