selectively applying changesets

Eric Hopper hopper at omnifarious.org
Wed Sep 28 18:00:49 CDT 2005


On Mon, Sep 26, 2005 at 09:23:41AM +0200, 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.

I've thought of a reason that this is the wrong thing to do...

(the numbers are changesets)

                          merge(6) re-merge(7)---new mainline----
                          |        |
-1---2--mainline----3-----+--4-----+
   \                     /        /
    `--5-your change----'--------'

Once you do the re-merge, you should mark changeset 6 (the first merge)
as non-exported.  But that doesn't mean the branch line containing
changeset 5 shouldn't be exported.  In fact, it might well be the
maintainer has specifically requested that she do all merging, and
doesn't want to pull merges from other people's repositories.  So any
merges you do are for your own benefit and not 'official'.

So, you should be able to mark changeset 6 as non-exported without
having any effect on the exportability of anything else.  You could
solve this by saying a non-exported head only effects the exported
status of until the first changeset with more than one parent, but that
doesn't feel right either.

Marking a changeset as non-exported and having it effect all changesets
that depend on it is a better solution.  If some other repository got
that changeset before you marked it then they have it, but can't get any
of the updates that need the non-exported changeset until you mark it as
exported again.

Have fun (if at all possible),
-- 
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg."  --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company."  -- Mark Twain
-- Eric Hopper (hopper at omnifarious.org  http://www.omnifarious.org/~hopper) --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.selenic.com/pipermail/mercurial/attachments/20050928/6a936bb3/attachment.pgp


More information about the Mercurial mailing list