octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hggroup available in graphics archive


From: Shai Ayal
Subject: Re: hggroup available in graphics archive
Date: Tue, 29 Apr 2008 20:21:45 +0300

On Tue, Apr 29, 2008 at 6:42 PM, John W. Eaton <address@hidden> wrote:
>
> 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.

Only Micheal and I commit to the graphics archive and neither of us
commit to the main octave repository, so I suspect this will make
finding our commits easy.
Our commits are either "real" changes or merges with the main octave archive.

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

OK, but it will take time to familiarize with this method.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]