Miha Vitorovic wrote:
> Hi all!
>
> Since I only monitor this list, I am very reluctant to speak, but I feel
> that I need to, now. Here are some of my observations.
>
> I've seen this issue raised by a number of users, who many times feel very
> strongly about it. I actually don't have much of a need for this feature,
> but some people feel they can not live without it.
>
> But I would like to point out, that the whole refusal of the developers
> comes across as "we will not do it, because we think that it is stupid".
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".
> I am OK with that stand, and if it would take developers away from real
> issues, of course I wouldn't like them to waste their time on something as
> trivial as this. Or, if this would break current Subversion
> functionality/system in some important way, of course everyone (well
> almost) would understand that you can not do it. But I didn't see this
> argument made anywhere (or maybe I missed it). It's more of a holy war,
> that real issue.
>
> But here you have someone who is willing to spend his time on this issue,
> and still you argue, that it is stupid. And this, IMO, is really bad
> advertising. Because those users who REALLY, REALLY want this, get the
> impression that it can be done, but won't because the developers mean they
> are stupid to want it in the first place. And people don't like to be
> called stupid. And here is this guy offering himself to do it, but "they"
> won't let him.
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.
---------------------------------------------------------------------
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:21:29 2005