Karl Fogel <kfogel@newton.ch.collab.net> writes:
> "Bill Tutt" <rassilon@lyra.org> writes:
> > For a long time now libsvn_fs/tree.c could not correctly resolve out the
> > laziness inherent in our O(1) copy model. That is no longer true. This
> > patch allows mod_dav_svn to report the correct "NodeRevision first
> > visible on this path at revision number X". This is accomplished by the
> > following changes:
> > * Record non-root bubble up changes in the changes table.
> > * svn_fs_node_created_rev now reports the "first visible on this path"
> > created revision number.
> > * svn_fs_dir_entries() now includes the new created_rev in the
> > svn_fs_dirent_t structure.
> > * svn_fs_revisions_changed() now stops immediately if cross_copy_history
> > is false.
>
> Bill, could you describe a concrete example scenario(s) affected by
> these changes? I'm having trouble understanding the motivation.
> Obviously, cmpilato understands it, but then, he was born in the
> filesystem :-).
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.
---------------------------------------------------------------------
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:48:14 2002