> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
>
> Karl Fogel <kfogel@newton.ch.collab.net> writes:
>
> > cmpilato@collab.net writes:
> > > I think this change addresses the following old problem:
> > >
> > > Given a greek tree at revision 1, I move A (and all its younguns)
to Z
> > > (making revision 2). Mod_dav_svn talks about paths and revisions
in
> > > all its communications. If you ask the filesystem for the created
> > > revision of the path /Z/D/G/rho, it will say "1" because
/Z/D/G/rho
> > > was a subtree item of a copied dir, and was not itself touched as
part
> > > of the copy. Of course, if you now refer to the path/rev tuple
> > > (/Z/D/G/rho, 1), the filesystem will tell you that no such path
> > > exists. That's wrong.
> >
> > Oh! Yah, that's a bug :-). I had thought this was how
> > svn_fs_node_created_rev() behaved right now, but looking at its
> > implementation, it clearly doesn't handle this case. Furthermore,
> > it's not clear that its behavior should change. That is, in the
> > scenario you describe above, we'd sometimes want created_rev() to
> > return 1, and sometimes 2, depending on whether one is asking about
> > the node itself or path by which it is accessed.
>
> I think Bill's change simply makes 'created_rev' mean something more
> like "path_created_rev" than "node_created_rev". I'm not sure if
> anyone really does care about the "node_created_rev" ... that's part
> of what I'm investigating while reviewing this patch.
Nobody outside of tree.c should care about node_created_rev. That's why
tree.c exists in the first place, right? That is, tree.c hides the
underlying the underlying DAG with a tree veneer.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 1 23:10:14 2002