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?
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!
Received on 2011-08-22 02:38:43 CEST