selectively applying changesets
zwin at users.sourceforge.net
Mon Sep 26 04:24:51 CDT 2005
Jan Hudec wrote:
>On Sun, Sep 25, 2005 at 22:31:32 -0700, Eric M. Hopper wrote:
>>On Sun, 2005-09-25 at 16:43 -0700, Matt Mackall wrote:
>>>- a way to remember which changesets we didn't want, and why, and
>>> when, and by who
>>I think this wouldn't be the right approach. I think it would be better
>>for an individual repository to mark changes non-exportable instead.
>>>- a way to deal with the inter-changeset dependencies
>>Yes. This is an interesting problem. In the case of marking a
>>changeset as non-exportable, the means any changeset that depends on it
>>also becomes non-exportable.
>And what about trying to do it the other way round? Heads are marked
>non-exported (NOT non-exportable!) and pull/push transfers all exported
>heads + all changesets in their ancestry.
>Also, pull/push should have a revision argument, which would mean
>"transfer that revision and necessary ancestry only".
>I'd think that, and not the marking, would be the main way of using.
>Let's say I have a private branch where I hack and another branch that
>private$ hack, hack, hack... (and commit several times)
>private$ hg revert -r something # Oh, it wasn't such a good idea...
>private$ hack, hack, hack... (and commit several times again)
>... ok, now it looks sane...
>private$ hg push -r tip public
>... but the first branch is not in the ancestry of head, so it does not
>get pushed. Now others simply pull everything from public.
I guess you meant 'hg update -C -r something' instead of 'revert'? IMHO
'revert' would not go back in history, instead it would apply reverse
patch to the current head...
But I really like the idea of non-public heads by default and
transporting just the necessary ancestry (which I think it does now
Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic
More information about the Mercurial