Currently the convert extension spawns a new mtn process for each
operation. For a large repository, this ends up being hundreds of
thousands of processes. The following enables usage of monotone's
"automate stdio" functionality - documented at:
http://www.monotone.ca/docs/Automation.html#index-mtn-automate-stdio-188
The effect is that (after determining that a new enough mtn executable
is available) a single long-running mtn process is used for all the
operations, using stdin/stdout to send commands and read output.
This has a pretty significant effect on the performance of some parts
of the conversion process.
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.
So far we've been denying rebasing descendants onto ancestors, but there are
situations in which this kind of operation makes perfect sense to me.
Let's say we have made a commit (or more), that belongs to branch 'dev', on
top of the named branch 'stable':
... a (stable) - b (dev)
but then we realize that b should belong to branch 'stable'.
In these cases a rebase means: "move these csets from named branch A to named
branch B" and there isn't a valid reason to deny it.
This patch basically doesn't block it, if source and destination are
on different named branches.
The old behaviour still applies for rebases across the same named branch.
Can you think of any tricky corner cases in which this new behaviour could
lead to problems? (I bet there are tons of them...)
By the way, I created a brand new .t because I feel there should be more
tests I can't think of at the moment.
When converting directory additions/replacement with project directory set to
root, _iterfiles() sometimes returned paths starting with a slash making
following svn calls to fail.
I could not reproduce the issue with hand-crafted repositories.
Report and first analysis by Clinton Chau <clinton@clearcanvas.ca>
When collapsing changesets with rebase, you get a chance to edit the commit
message manually, but there is no way to pass this message from the command
line. This patch adds a `--message` (with short form `-m`) and `--logfile`
(with short form `-m`) options to the rebase command. These options suppresses
the generation of the default commit message, and instead use the message
provided in the option (in case of `-m`) or in the file it points to (in case
of `-l`).
If you use this option without the `--collapse` option, it will raise an
error.
Options documentation edited by Patrick Mezard <pmezard@gmail.com>
Before, only the first failure was reported:
abort: b.txt should not have CRLF line endings
while now all of them are listed:
abort: end-of-line check failed:
d.txt in a7040e68714f should not have CRLF line endings
b.txt in fbcf9b1025f5 should not have CRLF line endings
As first suggested by Antoine Pitrou <solipsis@pitrou.net>
Before the additional datefilters (utcdate, svnisodate, svnutcdate)
were used when kwtemplater was initialized. Now they always be used
once the extension is enabled.
The win32text extension does not break eol or vice-versa, so it is not a fatal
error to have both of them enabled. It's just folly. So spewing warnings in
this condition is preferrable to aborting. When both extensions are enabled,
the user now sees:
% hg st
the eol extension is incompatible with the win32text extension
win32text is deprecated: http://mercurial.selenic.com/wiki/Win32TextExtension
M hgext/eol.py
