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

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