selectively applying changesets

Jan Hudec bulb at ucw.cz
Mon Sep 26 02:23:41 CDT 2005


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.

> > - a way to record that information in a form that works naturally with
> >   history, merge, annotate, etc.
> 
> Well, I don't think this is much of a problem for a repository that
> marks some of its changesets as non-exportable.  For someone using that
> repository, those changesets show up fine.  And for anybody who pulls
> stuff, well, they never get those changesets anyway.  The interesting
> question is if they push stuff based on changesets that are now marked
> non-exportable in the destination repository.

It should not be non-exportable, but non-exported. Now the changes are
needed, so they get exported nevertheless.

> [...]

--
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.selenic.com/pipermail/mercurial/attachments/20050926/55590aff/attachment.pgp


More information about the Mercurial mailing list