Been using these for almost a month now without problems, so I figured
some other people might want them.
This allows the zsh completion to work with tags and mq patch names
containing spaces, and adds support for qgoto.
The "one revision belongs to one branch" assumptions is relaxed. Branch
revisions are parsed down to the first branch copy encountered, older history
is skipped. It means the conversion is still not satisfying when dealing with
branches overwriting themselves. This issue already existed in the previous
version.
- simplify mail._sendmail to be a function rather than a class
- simplify connect to return a function rather than a class
- move exception handling from mail.sendmail to mail.connect
- use a single connection for all messages in patchbomb
We'd mistakenly made the -p option always on, which meant there was no
way to turn it off. It also meant that we were sometimes splitting
multibyte characters in function name, which isn't a good default.
In some subversion repositories, trunk is present but no branches
are used. The current code is assuming that both trunk and branches
must exist before adding trunk's head to the heads list.
It's just better to separate the branch layout stuff from the trunk one.
I'm a former Darcs user, and I've discovered that it is very convenient to
actually perform development using MQ first, and only when the patches are
'ready' move them to project's history in stone.
Usually I work on some topic, temporarily forgetting about any version control,
and just do coding, experimenting, debugging, etc.
After some time, I approach a moment, where my work should actually go to
patches/commits, and here is the problem::
As it is now, there is no way to put part of the changes into one patch,
and another part of the changes into second patch.
This works, but only when changes are touching separate files, and for
semantically different changes touching the same file(s) there is now
pretty way to put them into separate patches.
For some time, I've tolerated the pain to run vim patches/... and move hunks
between files by hand, but I think this affects my productivity badly.
So, here is the first step towards untiing the problem:
Let's use 'hg qrecord' for mq, like we use 'hg record' for usual commits!
we'll need this soon, when record extension will optionally depend
on mq early -- when preparing cmdtable.
Also, if accepted, ExtensionHowto wiki should be updated as well.
rationale
---------
I'd like to make MQ version of record -- qrecord.
>From the first glance it seemed to be easy -- the task in essence would be to
change call to cmdutil.commit() to something like mq.qrefresh().
As it turned out queue.refresh() and cmdutil.commit() have different semantics
-- cmdutil.commit() first scans for changes and then delegate the actual commit
to lowlevel func. On the other hand queue.refresh() do it all in once, and I am
a bit scary to change it.
Maybe the right way would be to first refactor queue.refresh() to use
cmdutil.commit() machinery, and then trivially adjust record, but I feel I'm
not competent for the task right now.
Instead, I propose we refactor record to be some sort of high-level driver, or
like a high-level decorator one can say, which will first interactively filter
changes, and then delegate commit job to high-level commiter, e.g. 'commit' or
'qrefresh'
So, this patch does just that -- refactor record to be generic driver, and
update 'hg record' code to use the driver.
'hg qrecord' will follow.
The aim of this extension is to clear the problem related to having
0x5c in 2nd byte of encoded bytes. So this extension is usefull for:
* Japanese Windows user shift_jis encoding.
* Chinese Windows user using big5 encoding.
To use this extension, simply enable it without any customization.
Note that some important python built-in functions and mercurial
functions are altered for this extension to convert argument if need
to handle MBCS.
