On Fri, 2005-09-30 at 12:20 +0100, Max Bowsher wrote:
> You are half right. It is more like "we will not do it, because we think
> that it cannot be done both properly and efficiently".
Some people have also argued that it's not a desirable feature. But
you're right, the primary reason we don't want it is that it's
architecturally difficult.
To address Miha, when something is architecturally difficult, having a
volunteer developer doesn't necessarily solve the problem, because the
resulting complexity stays in the code base forever and increases our
maintenance burden.
> My view (which I suspect is similar to many developers') is that I cannot
> believe people want a feature where "svn update just_one_file" causes svn to
> recurse both downward and upward throughout entire working copy.
I don't think we'd have to. We'd have to rewrite a file when (1) we're
bumping their revision numbers at the end of an update, and (2) the
entry indicates that the file has an svn:keywords property containing
$GlobalRev$ or whatever. (Similarly, to fix the "svn switch" keywords
bug, we'd have to rewrite each file whose entry indicates that the file
has an svn:keywords property containing any keyword which lists the
file's URL or FS path.)
For normal cases, the main penalty would be having to store the
svn:keywords property of each file inside the entries files.
> And, if we cut corners, and didn't do that recursion in all cases, then we
> would knowingly be introducing a bug, in that this new keyword value could
> easily become stale and inaccurate over the course of normal subversion
> operations.
The new keyword value would remain accurate: it would reflect the
working copy revision of that file. It might not reflect the uniform
revision of the entire working copy, but we don't have to make that a
requirement. (Although a name like $GlobalRev$ would probably be a poor
choice. $WCRev$ would be accurate but still easy to misinterpret;
$UpdateRev$ is inelegant but makes a certain amount of sense. There are
probably better choices I haven't thought of.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 30 19:08:20 2005