Max Bowsher wrote:
> 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.
>
> If we implemented that, people would complain (rightfully so) that svn
> was way too slow.
> 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.
>
> This is why I (and I suspect others too) are opposed to implementing
> it - because we cannot see any way which doesn't either introduce
> bugs, or horrible slowdowns.
>
>
> Max.
>
As a user, not a dev I agree.
I have just put a thought into the TortoiseSVN dev's list so sound out
the feasibility of client side hooks on Commit and Update which would
enable individual users to implement their own schemes and balance the
speed and necessity equations.
I utilize a one line revisioned file whose keyword text is replaced with
version info by SubWCRev and then copied to an unversioned file. The
unversioned one line file is included when the compiler runs. It would
be nice to have this simple process run without human intervention.
I envisage, the hooks would be more a function of TortoiseSVN than
Subversion but I'm not pushing either way.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 30 13:51:11 2005