Re: hggroup available in graphics archive

[John W. Eaton]

On 29-Apr-2008, Michael Goffioul wrote:

| On Tue, Apr 29, 2008 at 8:19 AM, John W. Eaton <address@hidden> wrote:
| > On 25-Apr-2008, David Bateman wrote:
| >  | Get it in to the main repository and I'm sure someone will look at it :-)
| >
| >  I would be happy to start merging the changes.  I just need to know
| >  which changesets to extract so that I can evaluate and apply them to
| >  my archive.
| 
| What do you want to import? Only the hggroup support?

I was thinking of catching up to all the changes.

| While not being impossible, it might be a little bit tricky to isolate
| the required changesets, because of the inter-dependency between
| all changes in the graphics branch. So it might take me some time...

OK.  When did the split occur?  Is there a tag in the archive marking
the point of the split?  Have there been any changes for graphics
checked in to your archive by anyone other than you or Shai?  If so,
who appears in the "user" field of the "hg log" output?  Knowing these
things might make it easier to quickly isolate the individual
changesets.

In the future, maybe we should encourage the use of Mercurial Queues
for major development branches like this since I think that would make it
simpler to keep the patches you are creating separate, and to still
keep up to date with the main development branch.  The idea is you
push your patchset off to the queue, pull in changes from the archive,
then push your changes back on to the source tree.  That way, the
state of the sources looks just like the remote "master" archive when
you pull, so there should never be any conflicts there.  Only when you
push your changes on to the source tree can there be conflicts, but MQ
makes it easy to fix the conflicts (just edit the sources to fix
any part of the sources where a patch failed to apply) and then merge
the new set of changes them back into your local set of patches (using
hg refresh).

Even though changes like this might be managed as one giant patch in a
queue, I think it would be helpful for the person doing the merging
later if they were kept in smaller pieces, for example, grouped by the
purpose of the patch.

jwe