Previous implementation was passing (date + "to" + date), which fails
when "<" and friends are prepended to the date specifier.
Signed-off-by: Mark Williamson <mark.williamson@cl.cam.ac.uk>
Introduce commandline.xargs() to limit argument list with respect
to ARG_MAX bytes. If no ARG_MAX information available - use POSIX
required minimum of 4096 bytes.
Under Windows, while actual argument list length is limited to 32k,
shells impose their own limits on command line length, down to 2047 bytes
for cmd.exe under Windows NT/2k and about 2500 bytes for older 4nt.exe.
See http://support.microsoft.com/kb/830473 for details about cmd.exe
limitations.
Since ARG_MAX is limit for argument list and environment, we reserve half
of it and one byte for environment variables. This way with default ARG_MAX
(4096 bytes) we get value 2047 bytes which is OK for Windows too.
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.
Link elements for Atom and RSS feeds had no end tag. <div> block element
inside <a> in-line element isn't right and caused rendering problems on
Safari. Spurious </div> tag in search forms. Branch entry missing closing
</a> tag.
- keywords are only expanded working dir, not in change history
- completely customizable keywords/expansions based on hg templates
- intrusiveness/slowdown can be reduced by specifying precise [keyword]
file patterns
- can be turned off/on anytime
- changesets can be exchanged regardless of remote/local keyword settings
If copy logged in file revision, we report copy for changeset only
if file revisions linkrev points back to the changeset in question
or both changeset parents contain different file revisions.
This fixes extra copies reported when executable bit was changed for
previously copied file.
If we know original changeset we are working with - try hard to
preserve it. Fallback to filelog.linkrev() only if we have no way
to get original changeset, since linkrev() may point to other
changeset.
On win32, the command line arguments seems to be limited about 2400
bytes. So 'add', 'delete', 'propget' and 'propdel' operations are
called several times within this limitation. And also 'commit'
operation is changed to be called without passing target files not to
exceeds this limitation because it cannot be a separated like other
operations above.
