Richard Lowe writes: > So, I think you hinted toward this during your review when looking at > one of the XXX's in WorkSpace (I think the "tied to the parent" > comment).
Well, it's really two things. First, I was surprised that getting the active list required a trip into the parent. As a Teamware user, I'm used to having the wx active list being a local attribute -- something that works in a disconnected workspace. In particular, it's something I can use on my laptop when I have WiFi shut off and I'm on a plane. Finding that the active list -- something I sometimes use to remind myself exactly what I'm working on or what things I haven't done yet -- needs the parent is disappointing. I can get used to it, and change how I work, but it'll take time. Second, yes, is the overall time the operation takes. And I've trussed the process, so I know that it's busy groveling through the entire local tree structure, and doing so for almost every single hg command. I'm more used to having a cache of this information saved off, and needing to do "wx update" when I know or suspect I've done some operation that may have changed the directory structure. I know it's trying to be "helpful" and "foolproof." Unfortunately, sometimes it's the sort of "help" and "proof" I don't want. > This is why I didn't get to implementing any kind of persistent > caching there (because the data in question is uncachable), and why I > didn't give up on my "no user maintained active list" kick, because > without the lack of write permission before 'wx/sccs edit', I think that > would lead to considerable confusion. Yep; understood. That's why I mentioned Mercurial (and not the Cadmium extensions) as being the source of the reason why it's going to take some getting-used-to. > This is the primary reason bug #357 exists. OK ... though that's focusing on cdm and not the overall hg environment. > [1] I talked to them about fixing this, and showed Matt a fairly nasty > patch I put together to demonstrate what I meant. If I recall the > end result of that conversation correctly, the idea was sound, the > patch was awful, and he would prefer to redesign the way Hg walks > files in general (or just the API surrounding it?) in the course > of whatever fix. Having an hg extension that does explicit user-refreshed caching of the required data would be a nice solution, at least for me. It doesn't have to be the default. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
