Very nice program. Comments and usage questions...
Matt Mackall
mpm at selenic.com
Sun Jul 10 21:56:36 UTC 2005
On Sun, Jul 10, 2005 at 02:23:12PM -0700, Marc Singer wrote:
> On Sun, Jul 10, 2005 at 02:12:48PM -0700, Matt Mackall wrote:
> > > So, now you've got changes from the upstream feed intermingled with
> > > your own. All of this still has to be committed, right?
> >
> > SCMs are all about committing stuff, yes.
>
> Not always. hg import doesn't require a commit.
The commit here is implied. My point is that everything has to be
committed eventually, otherwise you're not actually using an SCM.
> SCMs are about tracking changes to set of files. Once my changes are
> mixed with the mainline changes, the utility of the SCM is diluted.
>
> > >
> > > / SCSI-development-tree \
> > > Linus -> ATAPI-development-tree -> test-tree
> > > \ PXA-development-tree /
> >
> > As far as I know, having never actually used BK, Mercurial matches
> > that part of the BK model. As does Git. None of them allow applying
> > upstream changes 'underneath'. In all of these systems, things work
> > best if you actually use 'pull' rather than exporting things as
> > patches.
>
> But if I pull and then have to commit, the original change sets are
> lost.
Huh?
> > > In the absence of that, it would be helpful to be able to do this.
> > >
> > > # hg pull
> > > # hg update -C REVISION_FOR_NEW_BASELINE
> > > # hg apply-from-revision REVISION_OF_PREVIOUS_PATCH_SET
> >
> > Sounds like you want quilt.
>
> Quilt doesn't do this either. With quilt, you still have to remove
> your patches before reapplying them. The changeset already has this
> information and shouldn't require that I export the changes before
> reapplying.
>
> We should be able to conceive of this the same was as merging changes
> from several upstream sources into a single development tree. How
> does HG work in this mode?
>
> If there are three upstream repositories, MASTER, SCSI, and SERIAL.
> SCSI and SERIAL pull from MASTER. Then there is WORK which pulls from
> all three. Does HG allow me to pull from all three sources? How does
> it order and then apply changes made in MASTER, SCSI, and SERIAL in
> WORK?
hg clone master work
cd work
hg pull scsi
hg update -m
<test and fix>
hg commit
hg pull serial
hg update -m
<test and fix>
hg commit
>From the old kernel docs, this worked something like the following
with BK:
bk clone path_to_master work
cd work
bk pull path_to_scsi
bk resolve
<test and fix>
bk citool # make a second commit to fix up anything that broke in resolve
bk pull path_to_scsi
bk resolve
<test and fix>
bk citool # make a second commit to fix up anything that broke in resolve
The primary difference is that Mercurial does resolution in the
working directory. It used to do it behind the scenes. That's a bad
idea as it often needs that second commit step when the merge is
broken.
Also, Mercurial has a concept of multiple heads, whereas BK always
forces you to resolve. So you could do this as:
hg clone master work
cd work
hg pull scsi
hg pull serial
hg heads
hg update -m <scsi head>
<test and fix>
hg commit
hg update -m <serial head>
<test and fix>
hg commit
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial
mailing list