On Tue, Jan 15, 2013 at 3:49 PM, Satish Balay <balay at mcs.anl.gov> wrote: > On Tue, 15 Jan 2013, Jed Brown wrote: > >> On Tue, Jan 15, 2013 at 3:40 PM, Satish Balay <balay at mcs.anl.gov> wrote: >> >> > >> > Why not commit your changes, and always do 'hg pull --rebase' to get >> > latest petsc-dev stuff? >> > >> > Also - for uncommited stuff - I would get a patchfile with 'hg diff' >> > and apply it to the remote source tree. >> >> >> I would keep an hg clone on each machine. Then you can push and pull your >> changes. I'd put all your changes in a bookmark that you can rebase. Note >> that when you rebase, you'll get new commits when you pull from one of the >> other machines, and you should get rid of the old patches. > > How does one get rid of the 'old patches' in this workflow?
If you want to see how mercurial will (automatically) handle this in the future, you can install a dev version of mercurial and this extension: https://bitbucket.org/marmoute/mutable-history/ Then `hg rebase` will just mark the old commits as obsolete and the pushing / pulling to the other clones will propagate the obsolete markers. When Bitbucket fixes this issue: https://bitbucket.org/site/master/issue/4560/provide-a-method-for-setting-the-phase-of it'd be possible to use that workflow in the wild.
