I don't understand why we're arguing so hard that this feature must
never be in Subversion.
It's fine to say "It's not important enough to any current developer to
devote time to it." That's clearly true. It's also fine to say "If you
want to hire someone competent to see this feature all the way through
design and coding, then patches welcome." We say this all the time.
But I'm a little surprised that we're so vehement about insisting that
this is not useful, when we keep hearing from users that it is useful.
It reminds me of all the years when CVS and SVN experts would tell
people "You don't really need locking." Then SVN added a good locking
implementation, and lo and behold, a lot of people use it.
We could make the argument that mod-time-preservation would add too much
instability to the code. But that's a bit spurious: first, we haven't
seen the patch, so why would we be so sure? Second, we've incorporated
lots of other features that don't appeal to all users and do touch a
fair amount of code (look at all the different auth mechanisms we
support).
When I think about this feature technically, it doesn't seem likely to
add much instability. After all, if we're willing to save the modtime
in a property (an idea which Ben has proposed and which no one seems to
object to), then how hard would it be to use the value of that property
to set -- on platforms that support it -- the modtime of the working
file on checkout, update, or revert? Are we really talking about rocket
science here?
I'm not saying that anyone needs to drop what they're doing and write
the patch. I'm certainly not planning to. There is no obligation to do
something just because someone's asking for it.
But we also don't need to harden passive inaction into active
resistance. If some developer were to make a clean patch to do this, I
don't think we should turn it down on the assumption that it adds
instability. We should just evaluate it like any other feature patch,
and incorporate it if it seems good.
If there's going to be a FAQ entry here, IMHO it should something more
along the lines of what I'm saying here, not "We've discussed this and
decided it will never be in Subversion". There are feature proposals
that deserve that kind of unconditional rejection, but this is not one
of them.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-11 17:34:39 CEST