On 08/19/2011 01:45 PM, Markus Schaber wrote: > Hi, Neels, > > Von: Neels J Hofmeyr [mailto:ne...@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
signature.asc
Description: OpenPGP digital signature
