hgweb: overwrite cwd to resolve file patterns relative to repo (issue4568) It's useless to handle file patterns as relative to the cwd of the server process. The only sensible way in hgweb is to resolve paths relative to the repository root. It seems dirstate.getcwd() isn't used to get a real file path, so this patch won't cause problem.

dirstate: state that getcwd() shouldn't be used to get real file path hgweb will force it to be '' so that file patterns can be resolved relative to the repository root. I want to clarify that is correct.

merge: move merge step to the end Resolving other conflicts before merge ones is better because the state before the merge is as consistent as possible. It will also help with future work involving automatic resolution of merge conflicts with an external merge driver. There are no ordering issues here because it is easy to verify that the same file is never in both the dg/dm and the m sets.

lock: factor out lock testing into a separate function This is going to be needed for upcoming work with lock inheritance.

lock: factor code to read lock into a separate function This is going to be needed for upcoming work with lock inheritance.

tests: add unit tests for locking code We're going to make significant changes to lock behavior soon.

gitweb: port code selection without line numbers from paper This is adapted from f2e4fdb3dd27 and e92d4b8530cb. It also fixes issue4790 in gitweb; tab characters now have meaningful width on the modified pages (file view, file diff, changeset).

obsolete: remove unused _knownrevs function The call site was removed at cd62532c62a1.

bookmark: do not crash when active bookmark is forward and --date is used The logic that decides where to update according to the active bookmark location (when not on ".") was setting the rev to update to before we process --date. This lead to --date processing aborting because of duplicated specification. We reorder the two pieces of code and add a test for this.

bookmark: actually test update behavior in both cases The test claimed to test pull --update behaved the same way as pull + update, but the behavior of pull + update was never tested. We now test both.