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

Re: concerns about svn:hold -- was: svn commit: r1159240 - in /subversion/branches/hold/subversion: include/private/svn_wc_private.h include/svn_props.h libsvn_client/commit_util.c libsvn_wc/node.c

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Tue, 23 Aug 2011 01:56:22 +0200

Forgot to add that I absolutely love & agree with this reply. Thanks Johan!

~Neels

On 08/22/2011 08:48 AM, Johan Corveleyn wrote:
> On Mon, Aug 22, 2011 at 2:01 AM, Greg Stein <gstein_at_gmail.com> wrote:
>> On Sat, Aug 20, 2011 at 19:48, Neels J Hofmeyr <neels_at_elego.de> wrote:
>>> ...
>>> I have taken the occasion to write a comprehensive description of my current
>>> vision for svn:hold.
>>
>> I find the entire concept to be worrisome. All of a sudden, there are
>> files that just don't act right. "Magic" occurs, and only on certain
>> files. This just isn't very discoverable, and I think it will just
>> trip people up. "Huh? Why didn't that commit? ... OH, SUCK."
>>
>> There is just too much mystery occurring with this proposed feature.
>
> FWIW, I do like this feature (as an svn user and overall CM person in
> my company). I could certainly make good use of this in our
> environment: for project and module files of the IDE, build scripts
> ("Makefile.in" and the like), ...
>
> I do not want to bother every developer with that (putting them in a
> changelist, ...), but just set it (and draft the template) centrally.
> I only want them committed if someone explicitly decides to change the
> template (--do-not-hold seems fine to me).
>
> To me the current proposal seems like a relatively clean and standard
> approach. It doesn't appear to be any more magical than other svn:
> props (ignore, keywords, eol-style, ...). Besides, I haven't seen
> other ideas yet on how to implement this useful feature.
>
> However: please keep it as simple and transparent as possible, at
> least initially. For instance, I'm not interested in holding 'update'
> (I currently see no firm use case for that). AFAICS, the main thing is
> holding 'commit'. Though I realize that other operations may need to
> be adapted as well (status, diff, info, ...), to keep it consistent
> and understandable for the user.
>

Received on 2011-08-23 01:56:53 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.