Scott Wallace <Scott.Wallace at disney.com> wrote:
> This brings to mind a little command I wrote a long time ago that 
> addresses the same annoyance.  I use this command frequently, and 
> I've been tempted to put it into the public release for quite a 
> while, but never got around to it.  Now that the topic has been 
> raised on the squeak list, I thought I'd mention it.
> 
> My approach is to have a command that will globally reorder change 
> sets such that all the numeric ones appear *after* all the 
> non-numeric ones.  I often invoke this command after updating.  That 
> way, my named change-sets move to the top of the change-set lists in 
> change sorters.  This command does not affect just one change sorter, 
> it affects the order in which the system enumerates its change sets 
> everywhere.  (Naturally, within the numbered and non-numbered 
> subgroups, it preserves the pre-existing order.)
> 
> I usually *want* to continue to see the numbered updates in my change 
> sorters.  I just want them to be bunched together at the end of the 
> list, so that my own, unnumbered, change sets are all together at the 
> top.
> 
> I made this a command that you must proactively request when you want 
> it, rather than as something automatic, because after an update 
> happens, it is useful to see the newly-added updates at the top of 
> the list.  You can look at each of them, check them for conflicts 
> with your ongoing work, etc., and when you're satisfied, you can 
> issue the command to have them move down below your own changesets, 
> joining their confreres.
> 


Yes, both approaches sounds great.  It's really annoying having to hunt
through numbered changesets to find the ones that are mine.

However, I would vote for a third approach than the two mentioned: sort
the changesets by *name*, in reverse order.  This gives you an intuitive
ordering, fast lookups if you know the name, and separation of numbered
and non-numbered changesets.  It remains easy to figure out which
numbered changesets were added most recently, because after all,
numbered changesets are numbered in order, anyway.  Finally, it avoids
adding a menu item to an already large menu.


Lex