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

Re: 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: Thu, 18 Aug 2011 23:00:43 +0200

Hi Daniel,

if I understand you correctly, you are saying that there's no need for
svn:hold, as changelists already do what they are supposed to do.

But changelists and svn:hold have entirely different use cases.

1) svn:hold is exclusive, changelists are inclusive.
   I mean you can use an svn:hold on *one* file to block it, or you'd
   have to add *all other* files to a change list, what a bummer.
2) it should be possible to have svn:hold in the repos, i.e. to commit
   the property, using an --ignore-hold option, so that a project can
   by default set certain files on hold for all users checking out.

I'm aware of changelists and I'm sure that changelists are not the solution
to the use case at hand, being that there are few config files that are
basically templates. Every user has to configure them for their local box
(or every build changes some trivial item in it), and these changes should
not be committed, unless the user is really sure. Every user is prone to
committing these changes by accident and goes through pains to avoid
committing them, on a daily basis. Every new user falls into the same pit at
the first time, messing up all others' config files with conflicts. To work
around, people have to think about custom build scripts, e.g. commiting the
file on a different location and making the user/build script create a
personal copy at the proper location. That solution is not satisfactory to
many users.

Does that clarify anything at all?
And let me say this is bleeding edge WIP pre-alpha toy-around stuff on a
branch, so don't take this seriously ... YET! ;)

~Neels

On 08/18/2011 06:29 PM, Daniel Shahaf wrote:
> Stefan Sperling wrote on Thu, Aug 18, 2011 at 18:23:24 +0200:
>> On Thu, Aug 18, 2011 at 07:16:40PM +0300, Daniel Shahaf wrote:
>>> neels_at_apache.org wrote on Thu, Aug 18, 2011 at 14:24:12 -0000:
>>>> Author: neels
>>>> Date: Thu Aug 18 14:24:12 2011
>>>> New Revision: 1159240
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1159240&view=rev
>>>> Log:
>>>> On 'hold' branch: Block commits for files that have the 'svn:hold' prop.
>>>>
>>>> * subversion/include/svn_props.h
>>>> (SVN_PROP_HOLD): New #define.
>>>>
>>>> * subversion/libsvn_client/commit_util.c
>>>> (harvest_committables):
>>>> Check for 'svn:hold' prop and exclude files from committables if found.
>>>>
>>>> * subversion/include/private/svn_wc_private.h
>>>> (svn_wc__node_get_commit_status),
>>>> * subversion/libsvn_wc/node.c
>>>> (svn_wc__node_get_commit_status):
>>>> Also return parameter HAD_PROPS for slight optimization in
>>>> harvest_committables().
>>>
>>> Neels,
>>>
>>> I went ahead and put together a regression test for this. It XPASS()es
>>> when I use changelists instead of svn:hold.
>>
>> As far as I know, Neels would like to allow this 'hold' status to
>> be transmittable to other working copies via commit/update.
>> So a changelist is not the same thing.
>>
>
> I used a changelist for debugging purposes during test development:
>
> - svn propset svn:hold A/D/G/pi
> - svn commit A/D/G
> - XFAIL
> + svn cl foo A/D/G/rho
> + svn commit A/D/G --cl foo
> + XPASS
>
>> This is why this is on a branch -- the implementation is WIP and
>> there is more to come.
>>
>> But Neels can probably explain better.

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