[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 24 Aug 2011 13:56:30 -0400

On Wed, Aug 24, 2011 at 1:50 PM, Stefan Sperling <stsp_at_elego.de> wrote:

> I don't like this because it only addresses the merge-meister use case.
> Developers perform merges, too.
> The developer who does not want to commit local changes that existed prior
> to the merge now has to be careful to put files back on hold after the
> merge command has removed files from the special changelist.

We could probably go round and round on this forever if we want to, right?
 I could just as easily say that the inexperienced developer is less likely
to be doing merges, so we do not need to optimize for them. Or I could say
that it is better that the credentials of an inexperienced developer are
committed to the repository, then having them not commit a critical
configuration change.

I think the greater point is that this issue is more complicated than it
sounded originally, which is why I also point out we do not HAVE to do
anything at all. Neels will say what is it going to hurt to have a feature
that someone does not have to use. I say it hurts us anytime we add a
feature that can create confusion and problems. Who is to say some
developer does not add this property to address their needs and then this
gets rippled out to everyone and creates problems for them that the
developer did not consider. We are the ones that are going to be left to
answer it. We really want our answer to be that you do not have to use the
feature or you can write a hook to make sure no one does? BTW, that hook
would not be trivial.

Mark Phippard
Received on 2011-08-24 19:56:58 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.