On Jul 7, 2005, at 8:38 AM, Joshua Varner wrote:
> Okay, this make sense. I just have one question and this isn't meant
> as a criticism I'm just trying to understand the behavior. If Adds and
> Deletes are considered changes to the containing directory, then what
> is the rationale for not updating the version of the directory when an
> Add or Delete occurs?
Suppose you have revision 10 of a working copy, and then create a new
file, 'svn add' it, then 'svn commit', creating revision 17 in the
repository. It's definitely correct to mark the newly-added file as
being at revision 17. But the parent dir? Not possible. Any number
of adds/deletes/propchanges could have happened to it between r10 and
r17. Claiming that we have r17 of the parent would be a lie. What
we have is r10 of the directory, with a few extra "things" added/
deleted lying around.
So what's really going on is that when a working copy claims to have
rX of a directory, it means,
* I have the exact set of properties that (rX, dir) is supposed
to have
* I have the exact set of children that (rX, dir) is supposed to
have, except for these exceptions:
(list of deleted objects)
(list of added objects)
When it finally comes time to 'svn update', the working copy
describes itself very carefully to the repository. It claims to have
rX of the directory, and lists any extra deleted/added objects
hanging around. The repository then settles up, possibly adds and
deletes more things, then tells the client it's okay to mark the
directory as being at rHEAD.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 7 16:39:00 2005