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