Mercurial > hg
view mercurial/help/dates.txt @ 26402:05871262acd5
treemanifest: rework lazy-copying code (issue4840)
The old lazy-copy code formed a chain of copied manifests with each
copy. Under typical operation, the stack never got more than a couple
of manifests deep and was fine. Under conditions like hgsubversion or
convert, the stack could get hundreds of manifests deep, and
eventually overflow the recursion limit for Python. I was able to
consistently reproduce this by converting an hgsubversion clone of
svn's history to treemanifests.
This may result in fewer manifests staying in memory during operations
like convert when treemanifests are in use, and should make those
operations faster since there will be significantly fewer noop
function calls going on.
A previous attempt (never mailed) of mine to fix this problem tried to
simply have all treemanifests only have a loadfunc - that caused
somewhat weird problems because the gettext() callable passed into
read() wasn't idempotent, so the easy solution is to have a loadfunc
and a copyfunc.
author | Augie Fackler <augie@google.com> |
---|---|
date | Fri, 25 Sep 2015 22:54:46 -0400 |
parents | 7bec3f697d76 |
children |
line wrap: on
line source
Some commands allow the user to specify a date, e.g.: - backout, commit, import, tag: Specify the commit date. - log, revert, update: Select revision(s) by date. Many date formats are valid. Here are some examples: - ``Wed Dec 6 13:18:29 2006`` (local timezone assumed) - ``Dec 6 13:18 -0600`` (year assumed, time offset provided) - ``Dec 6 13:18 UTC`` (UTC and GMT are aliases for +0000) - ``Dec 6`` (midnight) - ``13:18`` (today assumed) - ``3:39`` (3:39AM assumed) - ``3:39pm`` (15:39) - ``2006-12-06 13:18:29`` (ISO 8601 format) - ``2006-12-6 13:18`` - ``2006-12-6`` - ``12-6`` - ``12/6`` - ``12/6/6`` (Dec 6 2006) - ``today`` (midnight) - ``yesterday`` (midnight) - ``now`` - right now Lastly, there is Mercurial's internal format: - ``1165411109 0`` (Wed Dec 6 13:18:29 2006 UTC) This is the internal representation format for dates. The first number is the number of seconds since the epoch (1970-01-01 00:00 UTC). The second is the offset of the local timezone, in seconds west of UTC (negative if the timezone is east of UTC). The log command also accepts date ranges: - ``<DATE`` - at or before a given date/time - ``>DATE`` - on or after a given date/time - ``DATE to DATE`` - a date range, inclusive - ``-DAYS`` - within a given number of days of today