I'm not entirely happy with using a trailing / on a "file" entry for
transferring a treemanifest. We've discussed putting some flags on
each file header[0], but I'm unconvinced that's actually any better:
if we were going to add another feature to the cg format we'd still be
doing a version bump anyway to cg4, so I'm inclined to not spend time
coming up with a more sophisticated format until we actually know what
the next feature we want to stuff in a changegroup will be.
Test changes outside test-treemanifest.t are only due to the new CG3
bundlecap showing up in the wire protocol.
Many thanks to adgar@google.com and martinvonz@google.com for helping
me with various odd corners of the changegroup and treemanifest API.
0: It's not hard refactoring, nor is it a lot of work. I'm just
disinclined to do speculative work when it's not clear what the
customer would actually be.
This means that the diff code does less work, potentially
significantly less in the case of treemanifests. It also should ease
implementation with narrowed clone cases (such as narrowhg) when we
don't always have the entire set of treemanifest revlogs locally.
As far as I can tell, this codepath is currently only used by record,
so it'll probably die in the near future, and then narrowhg won't have
to worry about composing with some unknown matching system.
It made output order unpredictable because two separate buffers are flushed
individually. Let's use a thin wrapper that just sends close() to black hole.
It was introduced at fa80944106df, where "template" argument could be a file
object. After that, 426525670e45 added "len(template)", so "template" must be
a string now. Therefore, "fp != template" should always be True.
It seems fa80944106df was intended to work around a bug in TortoiseHg, and
I'm sure I've fixed it completely in TortoiseHg source.
https://selenic.com/pipermail/mercurial-devel/2011-February/028467.html
Because makefileobj() duplicates or wraps stdout, "fp != sys.stdout" didn't
work correctly. Python doc states that special file objects are named in the
form '<...>', and absolute filenames should never start with '<', we can
ignore names start with '<'. We can't test fp.fileno() because fp may be a
command-server channel.
https://docs.python.org/2.7/library/stdtypes.html#file.name
In the test output, "exporting patch:" line is printed after patch content.
This is caused by fdopen() and will be fixed by the subsequent patch.
Because unknown attributes are delegated to the underlying file object,
commandserver channels said they were '<stdout>' or '<stdin>' even though
they weren't. This patch makes them say '<X-channel>'.
The default behaviour to forbid this makes a lot of sense for novice users
because it's safeguarding them from dangerous behavior but making it
configurable will be apprieciated by power users in at least one big
organization.
It allows an user to look an histedit rules from declarative perspective and
make the rules reflect the state after histedit. If we can move lines t move
commits why can't we drop lines to drop commits?
Let's put this behind config knob and inform users about this feature the very
moment they are trying to use it so they can choose desired behaviour.
The diff output without binaries is definitely great for interactive users - a
binary patch is not meaningful for them. Although setting diff.nobinary flag
can break the automation. Let's force full output for automation.
Rather than sleep for 2 seconds, we sleep until the next even-numbered
second, which has the same effect, but makes tests faster. This
removes test-largefiles-update as the long pole of the test suite.
This gives one line of output per second with one column per -j level
that allows analyzing test scheduling problems. First 24 seconds of
output at -j 30 looks like this:
0 .
1 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = s.
2 c c o c r l g r s s = c p = c h c a h c g c h c b c c l l c ss
3 h o b o e a e u u u c o a h o e o c g o l h g h u o = a o = s
4 e n s n b r n n b b m t g n l n l w n o e w e n n e r g i .
5 c t o = a g d - r r = m c w v p v . e v g c e c d v x g . m
6 k r l r s e o t e e b a h e e . e . b e . k b k l e t e . p
7 - i e e e f c e p p u n b b r . r . - r . - - - e r e f . o .
8 p b t v - i . s o o n d o d t . t . c t . c s = 2 t n i . r
9 y - e s c l . t - . d - m i - . - . o - . o y r - - s l . t
10 3 p - e h e . s s . l t b r s . s . m s . d m e f s i e . .
11 - e c t e s . . v . e e . . v . v . m v . e r n o v o s . .
12 c r h . c - . . n . 2 m . . n . n . a n . . e a r n n . . .
13 o f e . k u . . . . - p . . - . - . n - . . v m m - . . . .
14 m . c . - p . . . . e l . . s . m . d s . . . e a e . . . .
15 p . k . r d . . . . x a . . i . o . s o . . . - t n . . . .
16 a . h . e a . . . . c t . . n . v . . u . . . m . c . . . .
17 t . e . s t . . . . h e . . k . e . . r . . . e . o . . . .
18 . . a . t e . . . . a . . . . . . . . c . . . r . d . . . .
19 . . d . o . . . . . n . . . . . . . . e . . . g . i . . . .
20 . . s . r . . . . . g . . . . . . . . . . . . e . n . . . .
21 . . . . e . . . . . e . . . . . . . . . . . . 2 . g . . . .
22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24 . . . . . . . . . . . . . . . . . . . . . . . . . = . . . . ^C
Test names read off vertically, beginning with '='. Idle time (not
shown) appears as blank space.
The scheduler would like to order test execution by expected run-time,
but doesn't know much about how long a test will run. It thus uses
test size as a proxy for run-time. By tweaking these weights we can
keep CPUs more evenly busy and thus finish sooner.
In particular, this change pushes the three currently longest-running
tests closer to the beginning:
test-largefiles-update.t
test-run-tests.t
test-gendoc.t
As the largefiles test is currently the long pole of the test suite
with higher -j factors, the sooner it's started, the sooner the tests
can end.
We also up the weight on some shorter but long-running tests that
could have previously delayed completion with low -j factors by
running very close to the end.
Previously, we could be calling os.utime or os.chflags (via shutil.copystat) on
a symlink. These functions dereference symlinks, so this would have caused the
timestamp of the target to be set. On a read-only or similarly weird
filesystem, this might cause an exception to be raised.
This is pretty hard to test because conjuring up a read-only filesystem for
test purposes is non-trivial.
