Previously, importing a case-only rename patch on a case insensitive filesystem
caused the original file to be marked as '!' in status. The source was being
forgotten properly in patch.workingbackend.close(), but the call it makes to
scmutil.marktouched() then put the file back into the 'n' state (but it was
still missing from the filesystem).
The cause of this was scmutil._interestingfiles() would walk dirstate,
and since dirstate was able to lstat() the old file via the new name,
was treating this as a forgotten file, not a removed file.
scmutil.marktouched() re-adds forgotten files, so dirstate got out of
sync with the filesystem.
This could be handled with less code in the "kind == regkind or kind
== lnkkind" branch of dirstate._walkexplicit(), but this avoids
filesystem accesses unless case collisions occur. _discoverpath() is
used instead of normalize(), since the dirstate case is given first
precedence, and the old file is still in it. What matters is the
actual case in the filesystem.
This check was a legacy bit from when the file data was being fetched manually
with 'ctx[wfn]', but archive() does that now. 2032c5b369f5 seems to indicate
that this avoided a problem where a merge adds a file to another branch, and
that test still passes.
Unfortunately, I don't see a way to create a test that modifies the file in the
temporary directory before the command exits.
I wonder if the os.lstat() call needs to be wrapped in an exception handler for
the case where archive didn't create a file because the file didn't exist in
that revision. But I wasn't able to trigger a problem without it on a real
repository.
Since 862fc5f60fef, .hgignore is ignored on Windows because a pat may have
a drive letter, but pathutil.join is posixpath.join.
"z:\foo\bar/z:\foo\bar\.hgignore"
Instead, this patch uses os.path.join() and util.localpath() to process both
parts as file-system paths.
Maybe we can remove os.path.join() at dirstate._ignore because 'include:' is
resolved relative to repo root? It was introduced by 29ce78e5f35c.
"Tags" and "Bookmarks" sections on this page already have the similar links,
and so does the "Branches" on summary page in gitweb, so let's do the same in
monoblue.
Index page, which shows the list of available repositories, has a column where
the last modification date for each repo is shown. paper, coal and spartan
already show the dates in relative format (e.g. "2 weeks ago"), because these
styles have the required process_dates() js function call in their footer
templates, which are included on every page. But monoblue and gitweb styles
have more things in the footer templates, such as repo name and its atom/rss
links, so they don't include the footer on index page (as this page doesn't
have a single repo context).
Let's call process_dates() without including the footer.
When reading pattern files, we just call open(path), which is relative to the
current directory. Let's fix this by resolving the paths before attempting to
read the file.
Previously the hgignore test just called hg init in the test directory. A future
patch needs to test hgignore stuff from outside of the repo, so let's move the
entire test repo into a subdirectory.
On Windows Perforce command line client uses default system locale to encode
output. Using 'latin_1' causes locale-specific characters to be replaced with
question marks. With this patch we will use default locale by default whilst
allowing to specify it explicity with 'convert.p4.encoding' config option.
This is a potentially breaking change for any scripts relying on output treated
as in 'latin_1' encoding.
Also because hgext.convert.convcmd overwrites detected default system locale
with UTF-8 we had to introduce an import cycle in hgext.convert.p4 to retrieve
originally detected encoding from hgext.convert.convcmd.
As it turned out, even when getting relatively small files, concatenating
string data every time when new chunk is received is very inefficient.
Maintaining a string list of data chunks and concatenating everything in one go
at the end seems much more efficient - in my testing it made getting 40 MB file
7 times faster, whilst converting of a particularly big changelist with some big
files went down from 20 hours to 3 hours.
There are a lot of non-human consumers of Mercurial. And the challenges
and considerations for machines consuming Mercurial is significantly
different from what humans face.
I think there are enough special considerations around how machines
consume Mercurial that a dedicated help topic is warranted. I concede
the audience for this topic is probably small compared to the general
audience. However, lots of normal Mercurial users do things like create
one-off shell scripts for common workflows that I think this is useful
enough to be in the install (as opposed to, say, a wiki page - which
most users will likely never find).
This text is by no means perfect. But you have to start somewhere. I
think I did cover the important parts, though.
Before this patch, transplant can't restore dirstate as expected at
failure other than one while patching. This causes:
- unexpected file status
- dirstate refers already rollback-ed parent
(only at failure of transplanting the 2nd or later revision)
To restore dirstate correctly also at unexpected failure, this patch
encloses scope of store lock and transaction by 'dirstateguard'.
This is temporary fixing for stable branch. See
DirstateTransactionPlan wiki page for detail about the future plan to
treat dirstate consistently around scope boundary of transaction.
https://mercurial.selenic.com/wiki/DirstateTransactionPlan
This patch also adds 'if lock' examination for safety
'lock.release()', because creating 'dirstateguard' object may fail
unexpectedly (e.g. IOError for saving dirstate).
BTW, in the test script, putting section header '[extensions]' into
'.hg/hgrc' is needed to fix incomplete disabling 'abort' extension at
d0d06f4ca862.
Before this patch, in-memory dirstate changes aren't written out at
opening transaction, even though 'journal.dirstate' is created
directly from '.hg/dirstate'.
Therefore, subsequent 'hg rollback' uses incomplete 'undo.dirstate' to
restore dirstate, if dirstate is changed and isn't written out before
opening transaction.
In cases below, the condition "dirstate is changed and isn't written
out before opening transaction" isn't satisfied and this problem
doesn't appear:
- "wlock scope" and "transaction scope" are almost equivalent
e.g. 'commit --amend', 'import' and so on
- dirstate changes are written out before opening transaction
e.g. 'rebase' (via 'dirstateguard') and 'commit -A' (by separated
wlock scopes)
On the other hand, 'backout' may satisfy the condition above.
To make 'journal.dirstate' contain in-memory changes before opening
transaction, this patch explicitly invokes 'dirstate.write()' in
'localrepository.transaction()'.
'dirstate.write()' is placed before not "writing journal files out"
but "invoking pretxnopen hooks" for visibility of dirstate changes to
external hook processes.
BTW, in the test script, 'touch -t 200001010000' and 'hg status' are
invoked to make file 'c' surely clean in dirstate, because "clean but
unsure" files indirectly cause 'dirstate.write()' at 'repo.status()'
in 'repo.commit()' (see e1d123a2ee1f for detail) and prevents from
certainly reproducing the issue.
In 064b658181dd, age calculation was made dynamic (i.e. in javascript), but for
some reason bookmarkentry template in monoblue/map got a wrong class. It
resulted in /summary and /bookmarks pages always showing exact dates for
bookmarks, no age calculation was performed. Let's fix this by using "age"
class that is already used in branchentry and tagentry templates in the same
map file.
As usual, the exact date for such elements is still available in title
attribute, so it shows in a tooltip on hover.
Due to how the colorized output from pygments was stripped of <pre> elements,
when there was an empty line at the end of a file, highlight extension produced
an incorrect markup (no closing tags from the fileline/annotateline template).
It wasn't usually noticeable, because browsers were smart enough to see where
the missing tags should've been, but in monoblue style it resulted in the last
line having twice the normal height.
Instead of awkwardly trying to strip outer <pre></pre> tags, let's make the
formatter with nowrap=True, which should do what we need in pygments since at
least 0.5 (2006-10-30).
Example from monoblue style:
Before:
<div class="source">
<div style="font-family:monospace" class="parity0">
<pre><a class="linenr" href="#l1" id="l1"> 1</a> </pre>
</div>
<div style="font-family:monospace" class="parity1">
<pre><a class="linenr" href="#l2" id="l2"> 2</a>
</div>
Now:
<div class="source">
<div style="font-family:monospace" class="parity0">
<pre><a class="linenr" href="#l1" id="l1"> 1</a> </pre>
</div>
<div style="font-family:monospace" class="parity1">
<pre><a class="linenr" href="#l2" id="l2"> 2</a> </pre>
</div>
</div>
(Notice the missing </pre></div> now in place)
The output of the files command uses native separator. MSYS then seems to drop
the '\' on Windows when invoking python:
--- c:/Users/Matt/Projects/hg/tests/test-check-config-hg.t
+++ c:/Users/Matt/Projects/hg/tests/test-check-config-hg.t.err
@@ -6,22 +6,10 @@
$ hg files "set:(**.py or **.txt) - tests/**" |
> xargs python contrib/check-config.py Traceback (most recent call last):
File "contrib/check-config.py", line 93, in <module>
sys.exit(main(sys.argv[1:]))
File "contrib/check-config.py", line 24, in main
for l in open(f):
IOError: [Errno 2] No such file or directory: 'contriball-revsets.txt'
[123]
When using the -r option to Solaris diff, any directores that compare
identically are mentioned in the output. We don't really care about these
directories for the purposes of this test, so ignore them.
GNU grep allows you to use "a\|b" in a regular expression to match either
"a" or "b", but at least Solaris grep does not; only egrep allows for that.
And egrep considers "a+" to be "a{1,}" instead of an "a" and a literal plus
sign, so escape that as well.
Before this patch if clone --updaterev points to branch which head
on src repo wasnt in dest repo, clone updated dest repo to
default branch. After applying this patch, if changeset from
src repo pointing at given branch is not in dest repo, it searches
for changeset pointing for given branch locally in dest repo.
Lookup in destination repo:
559: uprev = destrepo.lookup(update)
is wrapped by try/except block to preserve current behaviour when
given revset to -u is not found - it will not fail,but silently update
dest repo to head of default branch.
Before this patch, follow only supports full, exact filenames.
This patch makes follow argument to be treated like file
pattern same way like log treats their arguments.
It preserves current behaviour of follow() matching paths
relative to the repository root by default.
As the content of a smartset never changes, min and max will never change
either. This will save us time when this function is called multiple times.
This is relevant for issue4782 but does not fix it.
Not only does this defeat the purpose of having `branchgroupiter` an iterable, but
this also makes revs something else than a smartset preventing to use revs.min()
in the call to reachablerevs.
Changeset 79b4c33e868f uses smartset lazy sorting for the C version. We need to
apply the same to the pure version for consistency. This is fixing the tests
with --pure.
As of this change, we no longer produce broken debs, but I've already
got followups written that will produce much more standard-looking
packages and test the resulting packages.
`make debian-jessie` was a poor name choice on my part, because it
really builds a package for the current debian platform, whatever that
happens to be, rather than a specific platform. Rename it to just
`make deb` so that it's a little clearer. As a result, it now places
built debs in a "debian-unknown" directory.
When running tests with -j100 or so on a large machine, I see this
os.remove call failing semi-regularly. Since it's not really a problem
when the file is already gone, just suppress the error in that case.
