templater: respect stop position while parsing template string It has no effect now because stop is len(tmpl).

hgweb: provide links to branches, tags and bookmarks by name (paper and coal) It's sometimes handy to, say, have a url always point to branch head, not just at the current branch head by node hash. Previously, this was only possible by manually editing url and replacing node hash with branch/tag/bookmark name. It wasn't very convenient, or easy - in case the name contained special characters that needed to be urlencoded. Let's have /branches, /tags and /bookmarks pages in paper and coal style provide links both to symbolic revisions and to node hashes. This feature was wished for in issue3594.

templates: introduce revescape filter for escaping symbolic revisions There needs to be a way to escape symbolic revisions containing forward slashes, but urlescape filter doesn't escape slashes at all (in fact, it is used in places where forward slashes must be preserved). The filter considers @ to be safe just for bookmarks like @ and @default to look good in urls.

hgweb: allow symbolic revisions with forward slashes in urls It's possible to have a branch/tag/bookmark with all kinds of special characters, such as {}/\!?. While not very conveniently, symbolic revisions with such characters work from command line if user correctly quotes the characters. These characters also work in hgweb, when they are properly encoded, with one exception: '/' (forward slash, urlencoded as '%2F'), which was getting decoded before hgweb could parse it as a part of PATH_INFO. Because of that, hgweb was seeing it as any other forward slash, that is, as just another url parts separator. For example, if user wanted to see the content of dir/file at bookmark 'feature/eggs', url could be: '/file/feature%2Feggs/dir/file'. But hgweb tried to find a revision 'feature' and get contents of 'eggs/dir/file'. To fix this, let's assume forward slashes are doubly-urlencoded (%252F), so CGI/WSGI server decodes it into %2F. Then we can decode %2F in the revision part of the url into an actual '/' character. Making hgweb produce such urls will be done in the next 2 patches.

convert: ignore case changes in vieworder for Perforce Perforce sometimes mixes the case resulting in files being ignored.

convert: if getting a file from Perforce fails try to get it one more time When converting a particularly large Perforce changelist (especially with some big files), it is very likely to run into an intermittent network issue (e.g. WSAECONNRESET or WSAETIMEDOUT) getting one of the files, which will result in the entire changelist converting being aborted. Which can be quite unfortunate since you might have waited hours getting all other files. To mitigate this let's attempt to get the file one more time, escalating original exception if that attempt fails.

shelve: keep old backups if timestamp can't decide exact order of them Before this patch, backups to be discarded are decided by steps below at 'hg unshelve' or so: 1. list '(st_mtime, filename)' tuples of each backups up 2. sort list of these tuples, and 3. discard backups other than 'maxbackups' ones at the end of list This doesn't work well in the case below: - "sort by name" order differs from actual backup-ing order, and - some of backups have same timestamp For example, 'test-shelve.t' satisfies the former condition: - 'default-01' < 'default-1' in "sort by name" order - 'default-1' < 'default-01' in actual backup-ing order Then, 'default-01' is discarded instead of 'default-1' unexpectedly, if they have same timestamp. This failure appears occasionally, because the most important condition "same timestamp" is timing critical. To avoid such unexpected discarding, this patch keeps old backups if timestamp can't decide exact order of them. Timestamp of the border backup (= the oldest one of recent 'maxbackups' ones) as 'bordermtime' is used to examine whether timestamp can decide exact order of backups.

subrepo: use vfs.dirname instead of os.path.dirname This patch uses "wvfs of the parent repository" ('pwvfs') instead of 'wvfs' of own repository, because 'self._path' is the path to this subrepository as seen from the parent repository.

vfs: add dirname

subrepo: use vfs.basename instead of os.path.basename

vfs: add basename

subrepo: use repo.pathto instead of util.pathto to simplify invocation This centralization into 'repo.pathto()' should reduce the cost of vfs migration around 'getcwd()' and so on in the future.

subrepo: prefetch ctx.repo() for efficiency and centralization 'subrepo.state()' refers same 'ctx.repo()' in many places and times.

revset: rename getkwargs() to getargsdict() This function was added recently at 48919d246a47, but its name was misleading because it processes both positional and keyword arguments.

revset: work around x:y range where x or y is wdir() All revisions must be contiguous in spanset, so we need the special case for the wdir revision.

revset: use integer representation of wdir() in revset This is the simplest way to handle wdir() revision in revset. None didn't work well because revset heavily depends on integer operations such as min(), max(), sorted(), x:y, etc. One downside is that we cannot do "wctx.rev() in set" because wctx.rev() is still None. We could wrap the result set by wdirproxyset that translates None to wdirrev, but it seems overengineered at this point. result = getset(repo, subset, tree) if 'wdir' in funcsused(tree): result = wdirproxyset(result) Test cases need the '(all() + wdir()) &' hack because we have yet to fix the bootstrapping issue of null and wdir.

localrepo: provide workingctx by integer revision This allows us to use the integer representation in revset. None doesn't work well while computing revset because revset heavily depends on and optimized for integer revisions. Still repo[wdirrev].rev() is None, which means the canonical form of the working-directory revision is None. This patch doesn't add the case for the wdirid because we can't handle short and ambiguous identifiers here. Perhaps, the wdirid will have to be handled in the changelog layer.

changeset_printer: change flush() to accept ctx instead of rev Because flush() is the function to write data buffered by show(ctx), flush(ctx) is more consistent than flush(rev). This makes sure that buffered header and hunk are always keyed by ctx.rev(). This patch will allow us to give an integer to the wdir while keeping wctx.rev() -> None.

changeset_printer: display wdirrev/wdirnode values for workingctx Because we want to eliminate "if"s in the default template, it makes sense to display wdirrev/wdirnode values for now. wdir() is still experimental, so the output of "log -r'wdir()'" may change in future.

hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.

merge with stable

cmdutil: apply dirstate.normallookup on (maybe partially) committed files To detect change of a file without redundant comparison of file content, dirstate recognizes a file as certainly clean, if: (1) it is already known as "normal", (2) dirstate entry for it has valid (= not "-1") timestamp, and (3) mode, size and timestamp of it on the filesystem are as same as ones expected in dirstate This works as expected in many cases, but doesn't in the corner case that changing a file keeps mode, size and timestamp of it on the filesystem. The timetable below shows steps in one of typical such situations: ---- ----------------------------------- ---------------- timestamp of "f" ---------------- dirstate file- time action mem file system ---- ----------------------------------- ---- ----- ----- N *** *** - change "f" N - execute 'hg commit -i' - backup "f" with timestamp N - revert "f" by 'merge.update()' N with 'partially' - apply selected hunks N by 'patch.patch()' - 'repo.commit()' - 'dirstate.normal("f")' N N+1 - 'dirstate.write()' N N - restore "f" N+1 - restore timestamp of "f" N - 'hg status' shows "f" as "clean" N N N ---- ----------------------------------- ---- ----- ----- The most important point is that 'dirstate.write()' is executed at N+1 or later. This causes writing dirstate timestamp N of "f" out successfully. If it is executed at N, 'parsers.pack_dirstate()' replaces timestamp N with "-1" before actual writing dirstate out. This issue can occur when 'hg commit -i' satisfies conditions below: - the file is committed partially, and - mode and size of the file aren't changed before and after committing The root cause of this issue is that (maybe partially changed) files are restored with original timestamp but dirstate isn't updated for them. To detect changes of files correctly, this patch applies 'dirstate.normallookup()' on restored files. Status check is needed before 'dirstate.normallookup()', because status other than "n(ormal)" should be kept at failure of committing. This patch doesn't examine whether each files are committed fully or partially, because interactive hunk selection makes it difficult. After this change, timetable is changed as below: ---- ----------------------------------- ---------------- timestamp of "f" ---------------- dirstate file- time action mem file system ---- ----------------------------------- ---- ----- ----- N *** *** - change "f" N - execute 'hg commit -i' - backup "f" with timestamp N - revert "f" by 'merge.update()' N with 'partially' - apply selected hunks N by 'patch.internalpatch()' - 'repo.commit()' - 'dirstate.normal("f")' N N+1 - 'dirstate.write()' N N - restore "f" N+1 - restore timestamp of "f" N ----------------------------------- ---- ----- ----- - normallookup("f") -1 - release wlock - 'dirstate.write()' -1 -1 N ----------------------------------- ---- ----- ----- - 'hg status' shows "f" as "clean" -1 -1 N ---- ----------------------------------- ---- ----- ----- To reproduce this issue in tests certainly, this patch emulates some timing critical actions as below: - change "f" at N 'touch -t 200001010000' before command invocation changes mtime of "f" to "2000-01-01 00:00" (= N). - apply selected hunks at N 'patch.internalpatch()' with 'fakepatchtime.py' explicitly changes mtime of patched files to "2000-01-01 00:00" (= N). - 'dirstate.write()' at N+1 (or "not at N") 'pack_dirstate()' uses actual timestamp at runtime as "now", and it should be different from the "2000-01-01 00:00" of "f". BTW, in 'test-commit-interactive.t', files are sometimes treated as modified , even though they are just committed fully via 'hg commit -i' and 'hg diff' shows nothing for them. Enabling win32text causes EOL style mismatching below: - files are changed in LF style EOL => files restored after committing uses LF style EOL (1) - 'merge.update()' reverts files in CRLF style EOL - 'patch.internalpatch()' changes files in CRLF style EOL => 'dirstate.normal()' via 'repo.commit()' uses the size of files in CRLF style EOL (2) Therefore, fully committed files are treated as "modified", because 'lstat()' returns size of (1) restored files in LF style EOL, but dirstate expects size of (2) committed files in CRLF style EOL. After this patch, 'dirstate.normallookup()' on committed files forces subsequent 'hg status' to examine changes exactly, and fully committed files are treated as clean as expected. This is reason why this patch also does: - add some 'hg status' checking status of fully committed files - clear win32text configuration before size/timestamp sensitive examination

cmdutil: put recordfunc invocation into wlock scope for consistency Before this patch, 'recordfunc()' for interactive hunk selection does below outside wlock scope at 'hg commit -i' and so on: - backup files, which may be partially changed - apply selected hunks on files - restore files from backup-ed ones These should be executed inside wlock scope for consistency. To put them into wlock scope without largely changing indents in 'recordfunc()', this patch adds another wrapper function. This patch is also a preparation for subsequent patch fixing the issue to correctly recognize partially committed files as "modified".

context: write dirstate out explicitly at the end of markcommitted To detect change of a file without redundant comparison of file content, dirstate recognizes a file as certainly clean, if: (1) it is already known as "normal", (2) dirstate entry for it has valid (= not "-1") timestamp, and (3) mode, size and timestamp of it on the filesystem are as same as ones expected in dirstate This works as expected in many cases, but doesn't in the corner case that changing a file keeps mode, size and timestamp of it on the filesystem. The timetable below shows steps in one of typical such situations: ---- ----------------------------------- ---------------- timestamp of "f" ---------------- dirstate file- time action mem file system ---- ----------------------------------- ---- ----- ----- * *** *** - 'hg transplant REV1 REV2 ...' - transplanting REV1 .... N - change "f", but keep size N (via 'patch.patch()') - 'dirstate.normal("f")' N *** (via 'repo.commit()') - transplanting REV2 - change "f", but keep size N (via 'patch.patch()') - aborted while patching N+1 - release wlock - 'dirstate.write()' N N N - 'hg status' shows "r1" as "clean" N N N ---- ----------------------------------- ---- ----- ----- The most important point is that 'dirstate.write()' is executed at N+1 or later. This causes writing dirstate timestamp N of "f" out successfully. If it is executed at N, 'parsers.pack_dirstate()' replaces timestamp N with "-1" before actual writing dirstate out. This issue can occur when 'hg transplant' satisfies conditions below: - multiple revisions to be transplanted change the same file - those revisions don't change mode and size of the file, and - the 2nd or later revision of them fails after changing the file The root cause of this issue is that files are changed without flushing in-memory dirstate changes via 'repo.commit()' (even though omitting 'dirstate.normallookup()' on files changed by 'patch.patch()' for efficiency also causes this issue). To detect changes of files correctly, this patch writes in-memory dirstate changes out explicitly after marking files as clean in 'committablectx.markcommitted()', which is invoked via 'repo.commit()'. After this change, timetable is changed as below: ---- ----------------------------------- ---------------- timestamp of "f" ---------------- dirstate file- time action mem file system ---- ----------------------------------- ---- ----- ----- * *** *** - 'hg transplant REV1 REV2 ...' - transplanting REV1 .... N - change "f", but keep size N (via 'patch.patch()') - 'dirstate.normal("f")' N *** (via 'repo.commit()') ----------------------------------- ---- ----- ----- - 'dirsttate.write()' -1 -1 ----------------------------------- ---- ----- ----- - transplanting REV2 - change "f", but keep size N (via 'patch.patch()') - aborted while patching N+1 - release wlock - 'dirstate.write()' -1 -1 N - 'hg status' shows "r1" as "clean" -1 -1 N ---- ----------------------------------- ---- ----- ----- To reproduce this issue in tests certainly, this patch emulates some timing critical actions as below: - change "f" at N 'patch.patch()' with 'fakepatchtime.py' explicitly changes mtime of patched files to "2000-01-01 00:00" (= N). - 'dirstate.write()' via 'repo.commit()' at N 'fakedirstatewritetime.py' forces 'pack_dirstate()' to use "2000-01-01 00:00" as "now", only if 'pack_dirstate()' is invoked via 'committablectx.markcommitted()'. - 'dirstate.write()' via releasing wlock at N+1 (or "not at N") 'pack_dirstate()' via releasing wlock uses actual timestamp at runtime as "now", and it should be different from the "2000-01-01 00:00" of "f". BTW, this patch doesn't test cases below, even though 'patch.patch()' is used similarly in these cases: 1. failure of 'hg import' or 'hg qpush' 2. success of 'hg import', 'hg qpush' or 'hg transplant' Case (1) above doesn't cause this kind of issue, because: - if patching is aborted by conflicts, changed files are committed changed files are marked as CLEAN, even though they are partially patched. - otherwise, dirstate are fully restored by 'dirstateguard' For example in timetable above, timestamp of "f" in .hg/dirstate is restored to -1 (or less than N), and subsequent 'hg status' can detect changes correctly. Case (2) always causes 'repo.status()' invocation via 'repo.commit()' just after changing files inside same wlock scope. ---- ----------------------------------- ---------------- timestamp of "f" ---------------- dirstate file- time action mem file system ---- ----------------------------------- ---- ----- ----- N *** *** - make file "f" clean N - execute 'hg foobar' .... - 'dirstate.normal("f")' N *** (e.g. via dirty check or previous 'repo.commit()') - change "f", but keep size N - 'repo.status()' (*1) (via 'repo.commit()') ---- ----------------------------------- ---- ----- ----- At a glance, 'repo.status()' at (*1) seems to cause similar issue (= "changed files are treated as clean"), but actually doesn't. 'dirstate._lastnormaltime' should be N at (*1) above, because 'dirstate.normal()' via dirty check is finished at N. Therefore, "f" changed at N (= 'dirstate._lastnormaltime') is forcibly treated as "unsure" at (*1), and changes are detected as expected (see 'dirstate.status()' for detail). If 'hg import' is executed with '--no-commit', 'repo.status()' isn't invoked just after changing files inside same wlock scope. But preceding 'dirstate.normal()' is invoked inside another wlock scope via 'cmdutil.bailifchanged()', and in-memory changes should be flushed at the end of that scope. Therefore, timestamp N of clean "f" should be replaced by -1, if 'dirstate.write()' is invoked at N. It means that condition of this issue isn't satisfied.