On Tue, Apr 12, 2011 at 3:14 PM, Hyrum Wright <hwright_at_apache.org> wrote:
> On Tue, Apr 12, 2011 at 8:00 AM, C. Michael Pilato <cmpilato_at_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
Received on 2011-04-12 15:28:07 CEST