[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: Gavin Baumanis <gavinb_at_thespidernet.com>
Date: Mon, 22 Aug 2011 10:37:59 +1000

Hi Neels,

For the time I have been writing this email I have struggled to find a use-case where "I" would use your new feature proposa
None the less; I really like the idea.

It really isn't changing anything of real substance from the users point of view.
* It just simplifies my commit processes because now I no longer have to manually exclude a file from being committed.
* A temporary svn:ignore until I "actively" choose to commit it.

As for the concern about whether to update the file on hold or not... I don;t have a string opinion either way.
Is there any possibility of having that behaviour an option?
I.e. chose to have a held file updated or not - as opposed to having it dictated to the end-user?

Gavin

On 21/08/2011, at 9:48 AM, Neels J Hofmeyr wrote:

> On 08/20/2011 03:13 AM, Mark Phippard wrote:
> [...]
>> That said, some of these questions concern me. Have you outlined your
>> vision for this feature in its entirety? The idea that svn up would not
>> update these files scares me. I have never heard anyone ask for anything
>> but having an easy way to exclude some files from commit. IMO, other
>> operations like update/merge/switch ought to all do their normal behavior
>> and not be impacted by a special property.
>>
>> I also wonder about commit performance. Does WC-NG make this a non-issue?
>> I would imagine having to do a property check on every file could become
>> expensive, but at the same time with a focused and tuned SQL query it could
>> probably be negligible.
>
> Hi Mark,
>
> thanks for these excellent questions.
> I have taken the occasion to write a comprehensive description of my current
> vision for svn:hold.
>
> I share your reservation about holding back updates, but it is being
> mentioned in two issues (#2858 and #3028), so we better have an answer for it.
>
> There naturally is some inconvenience about merging held-back files, because
> the merge result should usually always be committed. So mergers have to
> remember to --do-not-hold when committing merges.
>
> Commit performance loss is only an issue when there are very many files that
> are modified, as the property only needs to be checked on files that are
> modified in some way (at the very "tip" of harvest_committables()).
>
> Well, I should stop repeating what's already said in notes/hold. I hope that
> the outline is satisfactory, and please hint me at topics I might have
> missed in there!
>
> http://svn.apache.org/repos/asf/subversion/trunk/notes/hold
>
> ~Neels
>
Received on 2011-08-22 02:38:43 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.