Tracking 3rd-party sources

greg at maptuit.com greg at maptuit.com
Mon Apr 30 09:55:28 CDT 2007


On Mon, Apr 30, 2007 at 12:31:58PM +0200, Marcin Kasperski wrote:
> > now you work on active.  when an update comes out you unpack
> > into proj-pristine, hg addremove ; hg ci.  then you do hg pull
> > inside of proj-active.  this only pulls the CHANGES from the
> > old to new version.  you do NOT have worry about re-applying
> > your patch in any way, 
> 
> My patch is already in... So I have to worry.

I don't understand -- you have to manually fix this situation no
matter what you do; a computer can't figure it out for you. It can
tell you which parts are in conflict, but that's it.

There are two possibilities here: either you care about keeping your
patches tidy, or you don't.

If your patches are going to a maintainer, then "patch hygiene" is
important. MQ is a natural choice here. If you don't care about your
individual patches (i.e. you are really forking the project) then I
don't see why you'd bother with it. This makes it harder to merge from
upstream, but c'est la vie.

Re: Mercurial queues:
> 1) I feel that my code (code of the patches I develop) is not truly
> version controlled. qrefresh offers none of the functionality usual
> commit offers (prompting for description, showing changed files,
> ability to review diffs ...), qcommit shows me only that the patch
> file changed (and diffs of patches are not very readable)

See chapters 12 and 13 of "Distributed Revision Control with
Mercurial". You can set up a hook in .hg/patches/.hg/hgrc to use
"interdiff", which gets you the diff behaviour you are looking for. In
fact, this should probably be a default setting somehow.

> 2) (maybe here I did not learn MQ enough) I repeatably find myself
> in situation when I want to develop sth not relevant to the patch
> (trivial example: add sth to .hgignore) while working on the
> patch. I should probably just do it and then omit while
> qrefresh-ing, but I repeatably forget that there are some files I do
> not want to put into the patch.

To keep things tidy you need to be diligent about patch hygiene: no
tool can automate this. Here I'd probably have a separate patch at the
very bottom of the stack to accumulate these types of changes.

Re: Two repositories:
> 1) Merge happens in the opposite direction - instead of trying to
> reapply my patches (and check whether they still are suitable) I am
> trying to merge upstream changes on top of my code. The decision
> like throwing out my patch is more difficult to implement (one must
> carefully reconsider what and where is to be removed).

Here human intervention is required no matter what you do. If you are
working with two repositories then you probably don't care quite as
much about the contents of individual changesets: history's immutable
without performing complicated circus tricks, so a bugfix on a patch
goes in a separate changeset. As you've noticed, this makes it more
complicated to back out patches (especially if you committed changes
to two modules in one changeset), but that's a tradeoff you make for
being able to throw your clothes all over the floor.

You could always keep separate lines of work in different hg branches
(indeed this is common), but that's at least as fiddly as MQ.

My opinion is that MQ doesn't add too much overhead to your working
process; it's a pain to keep changes in neat, manageable little piles
(and it's maybe not quite as natural as it could be), but if the
upstream maintainer makes a change that renders one of your patches
unnecessary, your life becomes much easier.

G.


More information about the Mercurial mailing list