Patch generation with mercurial

[Wahazar]

I applied this patch to the just cloned trunk (r27185), corrected some failed hunks, compiled successfully - now how to properly generate new patch?
I used

Code: Select all

hg export -o isp_patch.diff

but this patch applied to copy of original trunk is patching only existing sources and does not generate new files (infrastructure*.*).

How to generate and apply such patch properly?

EDIT: invalid patch removed

[planetmaker]

I applied this patch to the just cloned trunk (r27185), corrected some failed hunks, compiled successfully - now how to properly generate new patch?
I used

Code: Select all

hg export -o isp_patch.diff

but this patch applied to copy of original trunk is patching only existing sources and does not generate new files (infrastructure*.*).

How to generate and apply such patch properly?

You probably forgot to teach mercurial about the newly added files, thus forgot one or more

Code: Select all

hg add FILENAME

If hg doesn't know about the new files, then it won't track them, thus patches it generates won't include them. You could have used hg import IS_patch.diff or hg patch IS_patch.diff which would have added the new files automatically (as opposed to patch)

Now, how to get the diff, that depends whether you committed the patch and its modification to your repository or not
Uncommitted changes:

Code: Select all

hg diff > mypatch.diff

If you have committed the patch (or used hg import or hg patch), you can use (XXX is the revision which adds the patch)

Code: Select all

hg log -p -rXXX > mypatch.diff

you can give several revisions this way. Or use hg diff -rXXX::YYY

[Wahazar]

Thank for reply, indeed I just forget about add, using commit only.
Additionally, I messed up relative links due to plain copy of repository to another directory.

[Wahazar]

OK, patch applied via patch command, source and .hgignore corrected, hg files added, and now:
1. hg diff produce 235kB large file (in comparison to original 59kB patch applied);
2. after add and commit, hg export produce similar large file (example of original file and generated, attached).
Seems, that instead of adding some lines, it removes whole parts of the code and add them again.
What I'm doing wrong?

If you have committed the patch (or used hg import or hg patch), you can use (XXX is the revision which adds the patch)
hg log -p -rXXX > mypatch.diff

I have no idea, how to check this revision number.
hg parent return following (not important data dotted):

Code: Select all

changeset:   22075:9a020e755fc9
tag:         tip
parent:      22028:99087ab020b6
user:        McZapkie <...>
date:        <...>
summary:     Hirundo patch applied

(the last one is my commit note, in original source there is revision number)

This particular patch is not patching properly (hunks failed), therefore I must touch code a little - and generate new up-to date patch.
I'm not familiar with any control version and little bit puzzled with all these options.

[planetmaker]

What I would try is:

* apply the patch to the version it was meant to apply to. That should not fail.
* Then do one of the following, possibly in an interative process with the goal to update it:
** rebase the revision to successively newer versions of trunk. Go smaller steps, then less things are to fix and it's easier to see where things need adoption.

Code: Select all

hg rebase -sXXX -dYYY

where XXX is the revision of your patch and YYY any later trunk revision. The XXX will change after each rebase, of course.
** merge successively newer versions of trunk onto your patched revision. Same reason as above.

Code: Select all

hg merge -rYYY

where YYY is again the trunk revision you want to merge onto your patch

The patch size might be bigger when trunk has uncommitted changes to the translation of the base set; it will then update openttd.grf which is not tiny Check whether that's the case with your new diff

when using mercurial, revision number means mercurial revision numbers, not svn. It can be referred to by the numeric ID (left part, 22075) or the hexadecimal hash (right part):

Code: Select all

changeset:   22075:9a020e755fc9

I recommend to take a quick tour through the basics of version control: http://hgbook.red-bean.com/read/

[Wahazar]

Of course I surfed over above mentioned manual (goggling the command often gives link to it), however from the beginner point of view, you brief explanation clarify a much - I was thinking that I can clone the newest repository, apply old patch, simply correct rejected hunks and generate diff against newest trunk.

Another, maybe less topic related question - linux compilation have quite different version than windows one, despite same source and changeset.
How to proceed to achieve same version number?EDIT: solved, there was hg and svn mismatch.

[Eddi]

if it seemingly removes and adds the same lines, probably you mixed up the line endings between DOS and Unix style. try to use the "unix2dos" or "dos2unix" tools

[Wahazar]

Eddi was right, I was shovelling files between Linux and Windows, dos2unix tool works perfectly and gets rid of these ^M chars.

Once more question - how to deal with version of modified source?

Assume, that I cloned trunk, and modified some source.
It have still same revision, and it is changed after commit?

[Eddi]

if you have an SVN checkout, you cannot commit, and any modifications show up only as an "M" in the version name. the revision that you generated the patch with is important information, as applying it to a different revision may cause conflicts.

if you have a HG or GIT clone, you can commit locally, and the version will show up as "hXXXX" or "gXXXX", where XXXX is a part of the commit hash. this may help in developing your patch, but the information which revision the patch is based on will get lost to the general public, unless you publish your entire repo. also, that is the only way other people can make compiles that have the same version string. it will still add "M" if you had uncommitted changes in your repo upon compiling.