selectively applying changesets

[Jan Hudec]

On Wed, Sep 28, 2005 at 16:00:49 -0700, Eric Hopper wrote:
> 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'.

As far as I can see from your diagram, merge 6 is a head. Though I think
I understand what you wanted to say.

> 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.

Well, it could be, that other changesets can also be marked non-exported,
which would mean that *if* the child pulled has two parents, only the other
will be pulled. I am not sure this is right thing to do though, as it makes
the ancestry different.

Another thing is the hidden -- the hidden flag should certainly work this
way.

> 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.

I'd fear this would quickly grow unmanageable. Marking heads has the nice
property, that you can easily get your hands at the list of heads. Finding
all the branch points is more complicated.

Also the head marking plays better with pull/push -r, because pull/push
without -r is just pull/push all exported heads. And what I expect to be
common use-case is to have private branch to work on and a public one, and
upon reaching reasonable state, simply doing "hg push -r tip public". No
caring about the exported/non-exported flags and all that...

In your case above, that would still export 6, but at least I wouldn't care.
It's in the history, so let's keep it there.

--
						 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/20050929/713dca0a/attachment.pgp