Tracking 3rd-party sources

[Marcin Kasperski]

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

I hoped I wrote it clearly, but let me rephrase it. In case 
things go significantly wrong, I often prefer to drop my 
patches altogether (maybe to reimplement then later,
maybe because they are no longer needed). 

If I try to merge new maintainer version in this scenario, 
computer is not telling me that such and such my patch or 
changeset is bad. It tells me that new maintainer release 
contains conflicts. The odds are on the maintainer changes, 
while those should be on the patch.

To give you simple example, imagine the patch which corrects some 
build nuisances (say, extends configure's and Makefile.conf's to 
give more freedom in specifying destination directories) and 
situation when new mainstream version completely changes the 
build system.
Or the patch which modifies the app to work with newer version of 
some helper library and maintainer release which does the same 
(or, maybe switches to different library).
{ It seems to me that in many 'tracking 3rd party sources' 
scenarios one has a couple of changes which remove some 
nuisances, add minor feature, adapts app to changed build or 
runtime environment etc }

And this is just the problem of direction - in such scenarios it 
is better to think about new mainstream release as 'base' and 
try to apply own work on it (modifying or dropping it when it is 
no longer suitable), than to apply mainstream (frequently huge) 
changes on top of already applied own changes.


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

I've already took a look at them, although I mosty 
omitted 'advanced tricks'. Looks like it is time to go back to 
them ;-)

Let me nevertheless, diff is not the only thing, there is no 'hg 
qct' for MQ for instance (heh, isn't it funny that qct command 
name starts from q?)

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

Yes, that's rather obvious. But handling this in practice is a 
bit cumbersome. I spotted those ignored file, so I 
edit .hgignore.  If I try to pop patches to return to the 
baseline 'cleanup' patch, then I loose uncommited changes.
So I keep working. When I am done, I frequently forget what I did
(would there be sth like hg qct, I would probably notice changed 
files which does not suit, but ...)

Would be nice if immediately after editing those .hgignore I 
could save this file to the first patch (giving it by name) 
without touching the directory content. But I am not sure 
whether this is implementable.

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

Yes, of course. But it can be as easy as 'hg qdelete mypatch' or 
as difficult as ... hmm, I am not able at the moment to write 
the commands to revert my changesets from memory ;-)

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

Using MQ is the conclusion to which I came on the very beginning. 
But I am not feeling fully happy with it, therefore this thread.

The fact that almost everybody is suggesting slightly different 
method of solving the same problem also to some degree proves 
that it deserves being discussed and, ekhem, documented...