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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 25 18:05:27 2002