selectively applying changesets
Zbynek Winkler
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
>is public.
>
>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
anyway?).
Zbynek
--
http://zw.matfyz.cz/ http://robotika.cz/
Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic
More information about the Mercurial
mailing list