On Fri, 2009-02-06 at 22:28 -0600, Steve Borho wrote: > On Sat, 2009-02-07 at 02:24 +0000, Tristan Wibberley wrote: > > Hi,
[etc... snip] > I like this visualization of the patches when they're applied. It lets > you know they're temporary additions. Thanks > I've envisioned a dialog that would show you unapplied patches and would > allow you to push/pull the queue, or reorder the unapplied list. The > problem I always run into is there's no real clean solution for when > patches do not apply cleanly. It would be nice if there was a tool that > helped you merge in rejected patch hunks. IMHO, the best solution to this problem (short of making mq do unapplied patches as a branch and rebase them to apply - or waiting for an alternative) is to adopt a merge program and change it. And that is something I plan to do. For plugging and code simplicity's sake I am thinking very seriously about diffuse (http://diffuse.sourceforge.net/) - working well with source control seems to be a particular goal - it also looks almost as nice as xxdiff. It is also written in python and gtk and is new enough that these enhancements might not disturb the developers too much (haven't stuck my oar in yet, though) > The other issue is that lately there's been a lot of buzz about > replacing MQ with something less fragile. There's this new attic > extension that is like a stackless MQ. Then there's pbranches. I was > planning on allowing this discussion to come to some conclusion and then > supporting the winner(s). Well, I don't like waiting for people to finish their feature replacements before supporting the old features, especially when there is valuable refactoring, UI code structural enhancements and educational requirements in common. You sometimes end up waiting forever and lose useful changes. So I'll start studying towards mq support anyway. [snip] > Drag & drop in GTK on Windows hasn't worked very well for us yet, but > perhaps DND within a single app will be possible. I'll have a play and see what happens. > As for splicing changes around, I'm pretty hesitant to support > operations that aren't already features of Mercurial itself, or at least > in popular extensions. Rebase gets us some of this, but not all, and it > is a pretty new extension that still seems to lose data occasionally. I would have thought that rebasing optionally combined with change reversion would get you all of this, but you'd just need to do more than one operation. For example, a cutsplice into the middle of an existing branch requires: 1) select region X to splice 2) rebase the changes after X onto the change before X - giving the new branch to replace the one containing X 3) rebase X onto the destination - giving the start of the new branch to replace the one that is to contain X (hereafter named X') 4) rebase the branch that X should be in onto X' 5) optionally revert the two old branches -- Tristan ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
