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

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: Sun, 21 Aug 2011 01:48:16 +0200

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!



Received on 2011-08-21 01:49:02 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.