On Tue, Apr 12, 2011 at 3:14 PM, Hyrum Wright <hwri...@apache.org> wrote: > On Tue, Apr 12, 2011 at 8:00 AM, C. Michael Pilato <cmpil...@collab.net> > wrote: >>> You are looking at changelists as a way to learn how to move operations into >>> wc_db properly, but just like that temp table for notifications I don't see >>> this as the way to go forward. >>> >>> I really don't see why users want to add thousands of nodes to changelists >>> while we still don't support changelists on directories. And if it is just a >>> handful of nodes the old code worked fine. >> >> This was one of the wrestling matches that I had with myself when I started >> looking at this very bit of code that Hyrum has changed. As I *understood* >> it, we had an internal goal of losing the svn_wc__node_walk_children(). >> "It's slow." But in some cases -- namely this one -- it just seemed like >> doing so would require adding obnoxious or otherwise unpleasant code. >> >> Changelist operations are, I would suspect, pretty rare, so if folks don't >> like the approach Hyrum has taken, I would suggest that he just revert the >> whole of his effort in this space, delete notes/wc_node_walkers.txt, add a >> note to the svn_wc__node_walk_children() docstring encouraging developers to >> consider using a more batch-based approach if possible when considering >> additional uses of the function, and then move on. If we're going to spin >> our wheels somewhere, let's not do it on our arguably lesser-used features, >> please. > > The point of this entire exercise was not to make setting changelists > faster (though that is a nifty side effect), but rather to get more > insight into how we are going to deal with them when doing this type > of thing for use cases that do matter, such as recursive propset. > We've got changelists all over the code, and since the database can do > changelist filtering for us, I presumed that learning how to use that > capability would be a fruitful use of time. I guess the insight is: > "we can't do it using current methods." > > I'll revert this work sometime today.
I agree it's not the most important operation that needs optimization, but I'd like to add some weight to the other side of the balance: I think it's more than just an exercise. I think it can provide performance benifits (or avoid performance regressions) for real use-cases. Maybe not for command-line usage, but definitely for integration with IDE's or other UI-integrations. The IDE we use at work, IntelliJ IDEA, has it's own changelist concept in the UI, but synchronizes that with "real changelists" of svn. It does this in the background: you can see (modified) files becoming part in the UI pretty quickly, but if you run 'svn st' on the command line, only part of them are in the svn-changelist. After a while, the svn-changelist has caught up. Changelists in IDE's are used a lot, for separating work. If you do a major refactoring, touching say 2000 files, and you want those to be part of some changelist ... Also, when we do a sync-merge of a feature branch, we usually let those merge-changes appear in a changelist (makes it easy to commit with a nicely prepared commit message). If those syncs are more than a week apart, the amount of changed files can easily go to 2000-3000. I can't comment on the technical merits/problems of adapting changelists for more optimal wc-ng use (I get the impression that the effort currently outweighs the gains), but just wanted to add my 0.02 €: adding thousands of files to a changelist is not unusual when working from an IDE. Cheers, -- Johan
