On Fri, Aug 19, 2011 at 7:12 PM, Neels J Hofmeyr <ne...@elego.de> wrote:
> 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? > First off, +1 on the idea of doing a feature like this. The fact that TortoiseSVN has coded something should be irrelevant. A solution that is honored by the API would be much preferred as then you could have consistent behavior across all clients. I am sure TortoiseSVN would prefer to remove code and allow the API to handle parts of this as well. 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. -- Thanks Mark Phippard http://markphip.blogspot.com/
