On 04.12.2009 05:22, Steve Borho wrote: > On Thu, Dec 3, 2009 at 6:24 PM, Kurt Granroth > <[email protected]> wrote: >> On 12/3/09 2:32 PM, David Dyer-Bennet wrote: >>> However; it seems to me that you're essentially abandoning Windows support >>> with this decision, and THAT I care about deeply just at the moment. >>> Losing support for Windows Explorer would uncheck the "Windows >>> integration" checkbox in most Windows shops, I believe, eliminating >>> Mercurial from consideration. Having to run "some other browser" is not >>> an acceptable alternative to most windows users, especially management. >> There are, of course, different ways of looking at that. We're rolling >> out Mercurial in our development department and TortoiseHg is absolutely >> *critical* to this. First-rate Windows support was in the "essential" >> list of criteria. TortoiseHg provides that for Mercurial in a way that >> git and darcs can't come close to touching. >> >> The big hurdle that we've had to overcome, though, is the fact that >> Tortoise is a shell extension. This is a shop coming from extensive use >> of WinCVS and other all-in-one tools. The reactions we got to a context >> menu ranged from outright loathing to more of a "oh well, if that's all >> there is then it'll have to do". NOBODY was a fan of it. >> >> The 0.9 release has really gone a long way towards alleviating a lot of >> those concerns. One look at the new Repository Explorer converted a few >> of the ones on the fence. >> >> Having an integrated file browser would bring even more into the fold. >> Also, it would allow us to push it for our Linux developers a bit more, >> as well (Nautilus use is rare). >> >> I'm not saying that wanting Explorer integration is less ideal or >> anything... just that it's not everybody's cup of tea. > > > This has been a great thread, thanks for all the feedback. I've > certainly learned quite a bit about how TortoiseHg is being used. > > The working plan going forward is to add a file browser to hgtk, > perhaps to the Repository Explorer as the idea has some intriguing > possibilities. > > The installer (probably starting in 0.10) will make the overlays and > context menus separately configurable (in 0.9 you could have both or > neither). If the overlays are not installed, we will not start the > taskbar app and we will not install TortoiseOverlays.
It looks like I have to stick around here for maintaining the shell extension (or it gets thrown out by Steve). I'm sorry to say this, but the real threat here for me are not only technical ones (instead it is - among other problems - Steve threatening to throw out the overlays for problems that are exaggerated a fair deal). Other problems are that we need a bit more flexibility in the release process. (And access to Windows 7. Sigh, looks like I have to pay that damn thing now.) We have previously pushed out a couple of changes to the shell extension via the stable branch without much discussions and it worked well (mostly for N.1, decreasingly for later point releases). I'm not very happy with the new trends in release process now (and recent discussions on -dev about it). Having to wait 4 months to get improvements in the shell extension out of the door, bundled together with major GUI changes in the same package, is not optimal, IMHO. We should do some shell extension changes on stable branch, and release it with the point releases. And we shouldn't be afraid to push out a fix release for a point release if needed (I can't remember this being needed in the past due to the shell extension bugs though - in contrast to other parts of the package, interestingly). On another note, I've started to think about extracting the thg shell extension into a wholly separate independent from TortoiseHg project, which builds a separate installer containing only the shell extension and the rpc server. If TortoiseHg decides to kill the shell extension, people could continue to use that then. If TortoiseHg agrees to use it, it could install that with its installer. So the installer layering would be: layer 3: TortoiseHg (containing hgtk + cli hg) layer 2: thg shell extension + rpc server layer 1: TortoiseOverlays (as provided by the SVN project) Preferrably, this would be packed into an msi installer package, using the WIX tools (like it is used for the TortoiseOverlays package we depend on). Maybe I should extract the currently hard coded cmenu config out of the code into a file that is read by the shell extension on init while I'm at it (would contain the ui strings, icon file names and the exact command line that is started). (Sigh, looks like quite a bit of yet more unpaid work). > Sune has gamely volunteered to keep the overlays working at their > current functionality level going forward, which guarantees they will > not be going away. Fair enough. Having more help on the shell extension would be appreciated. Especially since I still lack access to Windows 7 (feedback on how it runs there would already be a help). Subscribing to the issue tracker list would be recommended to read new bug reports coming in: https://lists.sourceforge.net/lists/listinfo/tortoisehg-issues Unfortunateley, the issue tracker mails are no longer sent to the dev list these days (which was needed because of the sheer volume). We have quite a couple of dubious bug reports there against the shell extension, and I would recommend not to take everything that seriously as a bug of the shell extension. Due to the design of the shell extension mechanism, we are inside the same process space with all others, meaning any other shell extension is able to shoot in our address space. So if we have an isolated explorer crash report that no one is able to reproduce, chances are high that something fishy is going on we might not be responsible for. But of course we must have an eye on it. > I would not object to someone simplifying the > overlays to only mark revisioned folders, so long as this was run-time > selectable. I fail to see what that would simplify, it it has to be run-time selectable. ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
