RE: [PATCH] Fix for 1003, and URL stability

[Bill Tutt <ra...@lyra.org>]

> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
> 
> Karl Fogel <kf...@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