Jesse Glick <jesse.glick@sun.com> [Sat, 05 Jan 2008 15:35:46 -0500] rev 5837
Issue #880: Simple misspelling ('occured') in web error message.
mark.williamson@cl.cam.ac.uk [Fri, 11 Jan 2008 01:36:20 +0000] rev 5836
Tweak finddate to pass date directly.
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>
Michele Cella <michele.cella@gmail.com> [Wed, 09 Jan 2008 11:15:00 +0100] rev 5835
adding "prefix" option to "hg serve" (command line and [web] section)
allows "hg serve" to serve from a different path than '/' (server root)
Kevin Christen <kevin.christen@gmail.com> [Tue, 08 Jan 2008 21:12:30 -0600] rev 5834
Fix XHTML validation error on file diff page.
Replaces <div>, a block level element, with <span>, it's inline
counterpart, in <pre>, which is also an inline element.
Matt Mackall <mpm@selenic.com> [Fri, 11 Jan 2008 13:06:38 -0600] rev 5833
hook: redirect stdout to stderr for ssh and http servers
Maxim Dounin <mdounin@mdounin.ru> [Fri, 11 Jan 2008 06:07:43 +0300] rev 5832
convert: add commandline.xargs(), use it in svn_sink class
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.
Christian Ebert <blacktrash@gmx.net> [Fri, 11 Jan 2008 15:01:29 +0100] rev 5831
keyword: fix some doc strings; update copyright
Kirill Smelkov <kirr@mns.spb.ru> [Thu, 10 Jan 2008 12:07:18 +0300] rev 5830
hg qrecord -- like record, but for mq
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!
Kirill Smelkov <kirr@mns.spb.ru> [Thu, 10 Jan 2008 12:07:18 +0300] rev 5829
cmdutil.commit: extract 'addremove' from opts carefully
we are going to use cmdutil.commit for qrecord, and it's brother
qrefresh does not support addremove.
Kirill Smelkov <kirr@mns.spb.ru> [Thu, 10 Jan 2008 12:07:18 +0300] rev 5828
dispatch: allow extensions to provide setup code
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.