> > On 8/1/06, Mark Phippard <markp@softlanding.com> wrote:
> ...
> > >One thing is clear, in a standard multiple developer scenario with a
> > >variety of commits happening from multiple sources, then the current
> > >behavior is correct and probably cannot really be improved much. I am not
> > >suggesting that Subversion is broken or took a short cut.
In my (limited) opinion, I think the WC version number of any
directory should recursively reflect the current known least-version
of all sub-elements. If it is the case that the contents of a parent
folder are all known to be at version N or above, and a commit results
in version N+1, and the brach hasn't switched since the last update,
then it is clear that the contents of said folder are now all at
version N+1, and the entries data for that folder should be updated
accordingly. In the more complex case, if it is known that there were
no changes to said folder between version N and version N+x in the
current branch, the branch hasn't been switched since the last update,
and the commit results in version N+x+1, the entries data for the
folder should be updated to version N+x+1. Doing otherwise would break
the statement in my first sentence. In my mind, not having the first
sentence always be true would break, or severely limit, the utility of
having a WC version number associated with each directory at all. Even
in multi-user environments, if everyone takes pains to always stay up
to date with the HEAD version, you are invalidating their efforts by
overlooking this.
Is an inaccurate number better than none at all? Does this number go
above the least-version of a sub-element in any case? If it never goes
above the least-version of any sub-element, just below, I suppose
subsequent updates are just meant to fill the gap. Is hard to detect
if a WC has switched braches since the last update?
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 2 05:08:44 2006