osutil: add a C function getting filesystem type Currently it only has Linux filesystems, according to my Linux manpage, built at 2016-03-15. The code uses "if" instead of "switch" because there could be some duplicated values.

setup: test some header files The next patch will use "statfs", which requires different header files on different platforms. Linux: sys/vfs.h or sys/statfs.h FreeBSD or OSX: sys/param.h and sys/mount.h Therefore test them so we can include the correct ones.

setup: detect statfs statfs is not defined by POSIX but is available in various systems to help decide filesystem type. Let's detect it and set the macro HAVE_STATFS.

setup: add a function to test header files

setup: split "hasfunction" to test arbitrary code The next patch wants to test include files.

rebase: add flag to require destination In some mercurial workflows, the default destination for rebase does not always work well and can lead to confusing behavior. With this flag enabled, every rebase command will require passing an explicit destination, eliminating this confusion.

update: add flag to require update destination In some mercurial workflows, the default destination for update does not always work well and can lead to confusing behavior. With this flag enabled, every update command will require passing an explicit destination, eliminating this confusion.

mq: reject new patch name containing leading/trailing whitespace We could create a patch of such name, but it wouldn't be processed properly by mq as parseseries() strips leading/trailing whitespace. The test of default message (added by b9a16ed5acec) is no longer be useful so removed. This issue was reported as: https://bitbucket.org/tortoisehg/thg/issues/4693/

shelve: rename stripnodes to nodestoprune Since we are introducing obs-based shelve, we are no longer stripping temporary nodes, we are obsoleting them. Therefore it looks like stipnodes would be a misleading name, while prune has a connotaion of "strip but with obsolescense", so nodestoprune seems like a good rename.

shelve: add an ability to write key-val data to a new type of shelve files Obsolescense-based shelve only needs metadata stored in .hg/shelved and if feels that this metadata should be stored in a simplekeyvaluefile format for potential extensibility purposes. I want to avoid storing it in an unstructured text file where order of lines determines their semantical meanings (as now happens in .hg/shelvedstate. .hg/rebasestate and I suspect other state files as well). Not included in this series, I have ~30 commits, doubling test-shelve.t in size and testing almost every tested shelve usecase for obs-shelve. Here's the series for the curious now: http://pastebin.com/tGJKx0vM I would like to send it to the mailing list and get accepted as well, but: 1. it's big, so should I send like 6 patches a time or so? 2. instead of having a commit per test case, it more like a commit per some amount of copy-pasted code. I tried to keep it meaningful and named commits somewhat properly, but it is far from this list standards IMO. Any advice on how to get it in without turning it into a 100 commits and spending many days writing descriptions? 3. it makes test-shelve.t run for twice as long (and it is already a slow test). Newest test-shelve.r runs for ~1 minute.

scmutil: add a simple key-value file helper The purpose of the added class is to serve purposes like save files of shelve or state files of shelve, rebase and histedit. Keys of these files can be alphanumeric and start with letters, while values must not contain newlines. In light of Mercurial's reluctancy to use Python's json module, this tries to provide a reasonable alternative for a non-nested named data. Comparing to current approach of storing state in plain text files, where semantic meaning of lines of text is only determined by their oreder, simple key-value file allows for reordering lines and thus helps handle optional values. Initial use-case I see for this is obs-shelve's shelve files. Later we can possibly migrate state files to this approach. The test is in a new file beause I did not figure out where to put it within existing test suite. If you give me a better idea, I will gladly follow it.

graphlog: draw multiple edges towards null node (issue5440) Before, edge (r, null) was processed only once by newparents. However what we really need is just stripping the edge (null, null).

merge with stable

localrepo: use tryunlink

vfs: use tryunlink

server: use tryunlink

dirstate: use tryunlink

debug: use tryunlink

chgserver: use tryunlink

bookmarks: use tryunlink

shelve: use tryunlink

vfs: add tryunlink method Thoughout hg code, we see a pattern of attempting to remove a file and then catching and ignoring any errors due to a missing file in the calling code. Let's unify this pattern in a single implementation in the vfs layer.

util: use tryunlink in unlinkpath We just introduced a func to attempt a file removal. Start using it.

util: add tryunlink function Throughout mercurial cdoe, there is a common pattern of attempting to remove a file and ignoring ENOENT errors. Let's move this into a common function to allow for cleaner code.

util: unify unlinkpath Previously, there were two slightly different versions of unlinkpath between windows and posix, but these differences were eliminated in previous patches. Now we can unify these two code paths inside of the util module.

posix: use local reference to removedirs We have a local reference to os.removedirs in module scope, but we still used os.removedirs inside functions. This changes util to use the local reference, which will pave the way for combining duplicated code in future patches.

posix: use local reference to unlink We have a local reference to os.unlink in module scope, but we still used os.unlink inside functions. This changes util to use the local reference, which will pave the way for combining duplicated code in future patches.

localrepo: improve vfs documentation At the beginning of March, I promised Yuya that I would follow up a comment I made on a patch with improved documention for these vfs objects. Also hat tip to Pierre-Yves for adding the documentation here in the first place.

ui: restrict length of autogenerated blocked tags Long autogenerated blocked tags tend to be because the command has an absolute path; at Facebook, we've had a few where the tag is thousands of characters long (in association with the mergedriver). Change the default to use a suffix of a command as the default tag, limiting us to 85 characters (for a 100 character tag). This is long enough to overflow a standard terminal (thus be obviously autogenerated), but short enough to be readable.

commit: keep opts as byteskwargs as much as possible This fixes many flag-handling bugs on 'hg commit' in Python 3.