On Jan 4, 2005, at 7:26 PM, Jim Correia wrote:
> On Jan 4, 2005, at 8:17 PM, Shawn Harrison wrote:
>
>> To my thinking, the version number of the directory itself should be
>> the same as the latest version of any file within it. When foo.c is
>> committed, there is also an implicit change to the parent dir
>> (namely, what it contains). So the parent dir should also have the
>> later revision number, all the way back up the parent hierarchy.
>
> The directory is a separately versioned object (with its own
> properties, etc). You can't arbitrarily decide to call what you have
> N+1 just because one of its children was committed.
>
Exactly. In Subversion's universe, "revision N of a directory" means
1) a specific list of child entries, and 2) a specific list of
properties. As Jim said, you can't arbitrarily bump the working
revision of a directory in a working copy just because you feel like
it: you actually have to *have* the version of the directory.
So the classic example is:
Say you have a working copy at r5, and commit foo.c, which creates r9.
Certainly it's safe for the working copy to assume that its foo.c is at
r9. But it's not safe to assume that the parent directory is at r9:
what if somebody added or removed entries from the directory somewhere
in r6, r7, or r8? What if somebody changed the directory's properties?
Until you run 'svn up', it's not safe to assume that the working copy
really has r9 of of the directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 5 05:50:49 2005