These leaks may occur in environments that don't employ a reference
counting GC, i.e. PyPy.
This implies:
- changing opener(...).read() calls to opener.read(...)
- changing opener(...).write() calls to opener.write(...)
- changing open(...).read(...) to util.readfile(...)
- changing open(...).write(...) to util.writefile(...)
This is a long desired cleanup and paves the way for new discovery.
To specify subsets for bundling changes, all code should use the heads
of the desired subset ("heads") and the heads of the common subset
("common") to be excluded from the bundled set. These can be used
revlog.findmissing instead of revlog.nodesbetween.
This fixes an actual bug exposed by the change in test-bundle-r.t
where we try to bundle a changeset while specifying that said changeset
is to be assumed already present in the target. This used to still
bundle the changeset. It no longer does. This is similar to the bugs
fixed by the recent switch to heads/common for incoming/pull.
This adds support to identify a particular transplanted changeset or set
of changesets. The argument is optional. Examples:
hg log -r 'transplanted(1234 or 2345)'
hg log -r 'transplanted()'
Immediately sends local's heads to the server to check whether the server knows them all.
If it does, we can call getbundle immediately.
Interesting test output changes are:
- added 1 changesets with 0 changes to 1 files (+1 heads)
+ added 1 changesets with 0 changes to 0 files (+1 heads)
-> The new getbundle() actually fixes a bug vs. changegroupsubset() in that it no longer
returns unnecessary files when file revs are reused.
warning: repository is unrelated
+ requesting all changes
-> The new use of common instead of bases correctly indicates that an unrelated pull
gets all changes from the server.
Sometimes it is necessary to know the original revision ID in order to
correctly rewrite the patch or commit message when transplanting. This
patch follows the pattern set by the existing 'HGUSER' environment variable,
and adds a test that covers both HGUSER and HGREVISION.
(makes issue2135, issue2264 more obvious, but does nothing to fix
either one)
This seems to happen in two distinct cases:
* patch.patch() claims success but changes nothing (e.g.
the transplanted changeset adds an empty file that already
exists)
* patch.patch() makes changes, but repo.status() fails to report them
Both of these seem like bugs in other parts of Mercurial, so arguably
it's not transplant's job to detect the failure to commit. However:
* detecting the problem as soon as possible is desirable
* it prevents a more obscure crash later, in transplants.write()
* there might be other lurking (or future) bugs that cause
repo.commit() to do nothing
Also, in the case of issue2264 (source changesets silently dropped by
transplant), the only way to spot the problem currently is the crash
in transplants.write(). Failure to transplant a patch should abort
immediately, whether it's user error (patch does not apply) or a
Mercurial bug (e.g. repo.status() failing to report changes).
this helps users to know what kind of option is:
- no value is required(flag option)
- value is required
- value is required, and multiple occurrences are allowed
each kinds are shown as below:
-f --force force push
-e --ssh CMD specify ssh command to use
-b --branch BRANCH [+] a specific branch you would like to push
if one or more 3rd type options are shown, explanation for '[+]' mark
is also shown as footnote.
Transplant filtering used a tmp file ending with the (stripped) commit
message and thus no final LF. Text files not ending with LF is usually
not used on Unix and is thus wrong ;-)
The missing LF had bad consequences because Solaris sed chokes on
unterminated input lines, so
echo -n foo|sed 's,o,0,g'
doesn't output anything, and the filter used in tests/test-transplant
thus stripped the last (and only) line in the message away on solaris.
It is not very helpful to have 'Added tag %s for changeset %s' and
similar messages translated into different languages when people work
together using different locales.
We now use English strings without support for translations. If
needed, the user can still supply a custom string for most commands.
