On 08/19/2011 01:45 PM, Markus Schaber wrote:
> Hi, Neels,
>
> Von: Neels J Hofmeyr [mailto:neels_at_elego.de]
>>
>> 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.
>
> At least this usecase is supported by TortoiseSVN via the
> "ignore-on-commit" changelist.
Yes, I'm very aware of that. But I respectfully disagree with changelists
being the best solution for this issue.
<rant>Changelists could have been a nice solution if we had any
repository-supplied config for those, and if it didn't involve reversing the
currently established "direction" of changelists depending on the changelist
name, and if it didn't involve using a changelist implicitly. All I see
there are cans of worms and pandora's boxes. Using an "svn:"- prefixed
property is more powerful, cleaner *and* easier to realize.</rant>
But while we're at it, could you tell me if Tortoise's ignore-on-commit
changelist also keeps out updates on those files? From the name I'd guess
not, right? And does it affect WC-to-URL copies, or *anything* else?
And, oh yes, if a folder appears in the ignore-on-commit list, are prop
changes on that folder ignored on commit? And does that act recursively,
keeping entire subtrees out of commit?
I'd greatly appreciate some real world insights on these issues.
Thanks!
~Neels
Received on 2011-08-20 01:13:30 CEST