Given that we've allowed a user to maintain a branch for this feature
for *years* -- without allowing him to merge the feature -- our
actions speak louder than words!
I'm fine for reopening the debate; we should first examine why
exactly we've kept this branch in stasis for so long. If we don't
like the design, what would a better design be?
On Fri, Jul 11, 2008 at 10:33 AM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> 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:37:34 CEST