On 21.05.2009 01:37, TK Soh wrote: > On Wed, May 20, 2009 at 11:17 PM, Adrian Buehlmann <[email protected]> wrote: >> On 20.05.2009 19:35, Adrian Buehlmann wrote: >>> On 20.05.2009 17:09, Steve Borho wrote: >>>> On Wed, May 20, 2009 at 12:36 AM, TK Soh <[email protected]> wrote: >>>>> Just try it for a short time, but here's some observation so far: >>>>> >>>>> On overlay icons: >>>>> - on first view, tracked folders have no overlay icons, and it's not >>>>> obvious to user that a call to thgstatus is required. Some visual que >>>>> is needed to signal that. >>>>> - after thgstatus, untracked folders are marked as unchanged. >>>>> - overlay icons on folders, including the root folders, don't reflect >>>>> the correct status when files contained are modified/reverted/etc. >>>>> Must run thgstatus to update. IMO, this is counter-intuitive. Can >>>>> calls to thgstatus be automated? >>>> We think a lot of the cases can be caught by Mercurial hooks, but that >>>> will not catch changes made by the user. Ie: When they edit a file >>>> the directory icons below it are not updated. It should be possible >>>> to fix this when we refresh, but I don't know what Adrian's plans are >>>> in this regard. >>> I have none. I'm pretty much finished with this. >> To my surprise even the hooks thing is now pretty much ruled out by Matt >> (as per his rejects of my patches on mercurial-devel), and the existing hg >> hooks are largely unusable for getting up-to-date hg status update triggers >> by Mercurial. >> >> So, unless we start routinely patching Mercurial, we will probably have to >> live with what we have re icon updating. And most likely not worth investing >> much more time on the updating overlay thing then. >> >> I think the current system in crew is still a big improvement over the old >> pythonic shell extension and I will continue to use the new system as long >> as I have to work on Windows :-). > > Unfortunately, I can't agree with that. It's already bad enough to ask > user to run Update icons to update the folder icons the first time, > and telling them "you have to run it every time you change something" > is simply unreasonable.
No it really isn't. There is a reason why there is a hg status command. Running that command has a cost. Remember, we are talking about the icons on the _folders_, covering the sum of whole subtrees. If it takes that long to compute them, I'd rather turn the icons off on the folders (if I could). So if I want an update on the folder icons, I'm fine with having to issue a context menu command. But maybe it's just me who is working on large trees and is willing to pay that price in exchange for being able to quickly navigate inside it. I also like being able to say when I want to spend that moment for updating the icons on the folders. Also, in my trees I'm working a lot in quite narrow subtrees inside a specific clone (I'm doing a clone when I need to work on specific issue or feature). For example, in one project we have the source files related to storing functions all together in the same subfolder. If I have a bug to fix about storing things, I work in that folder, editing files. So the set of modified directories doesn't actually change that often in my workflow. But again, requirements can vary. I'm just not that obsessed with up-to-date to the second icons on the folders in my everyday use. And remember, the icons on the files are still immediate (provided that you can live with the already described consequences of the shellext reading .hg/dirstate - I can, and the CuteHg project has decided to do that too). One of them is that you have to hit F5 to update the file icons of the files in a folder you have opened in explorer, if you do something on the command line with mercurial on files in that folder (I could call that doing something "behind the scenes", as you could have done it with the context menu, which implicitly updates _all_ icons). But, for example, if I start editing a file that was not modified before (green) and I have the folder containing that file open in explorer in the background, the icon changes immediately to red when I save it in my editor in the foreground, because explorer notices that the file has changed an queries the shellext immediately. No need to hit F5 or even execute "update icons" from the cmenu. Also, with current crew all the commands from the context menu do a hg thgstatus implicitly when needed. This for example means that if you select some new files and add them with the context menu, everything -- including the icons on all folders in that repo -- is updated when the hg add command is finished. Same with commit. Same with update from the log dialog. Same with clone from the clone dialog. Same with adding or removing files in the status dialog. Etc. So I don't see it that dramatic as you say. Certainly nothing unreasonable here, I'd say. And it is very nice to have folder icons on the repo _roots_. You can forget that on the old system. I have a folder where I have all my clones. I now have an overview, in what repos I have changes. Yes, I do have to run that refreshicons.cmd in the base dir (where I have all my clones). It takes about 20 seconds here to update that overview of which of my clones is modified and which isn't. And I have some thirty clones with lots of files in it. I would have to navigate into each of them to see if anything is changed under the old system. This is quite comparable to having to issue a hg status on the command line, as the linux folks are doing it all the time. And some Windows users do, who don't use the overlay icons (because, maybe they were just too slow). You can think of just seeing the result of your last 'hg status' (Update Icons in the cmenu) on the folders in your tree while you navigate it with explorer. Icons on the files in a specific folder you see show the state according to what's in the .hg/dirstate, but file modification times freshly compared in that very moment you navigate into it (the files having status 'n' in .hg/dirstate) Is that really that unreasonable? ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
