existing clone code uses pull to get changes from remote repo. is very
slow, uses lots of memory and cpu.
new clone code has server write file data straight to client, client
writes file data straight to disk. memory and cpu used are very low,
clone is much faster over lan.
new client can still clone with pull, can still clone from older servers.
new server can still serve older clients.
Sometimes there's a non-tip head waiting to be merged, especially after
pulling in remote changes while there were local modifications in the working
directory which had to be committed before 'hg merge' can work.
Rearranged the clone command a good bit to make sure it validates that
the source does exist and that the destination doesn't before doing anything.
Before I moved the source repo check it would create the destination
repository before it verified the source existed.
Moved the responsibility for creating the destination repo root directory
entirly into the localrepo class so that local to local cloning doesn't break.
This also simplifies the code a bit since it's no longer being done in both
clone and init.
Changed the names of the 'repo' and 'other' variables to 'dest_repo' and
'src_repo' to maintain my sanity.
Passes 82/83 tests. The only failure is the version number test, which I
suspect is supposed to fail since it comes from a generated file.
cold cache diff performance has regressed in two ways. localrepo.changes
has optimizations for diffing against the working dir parent that expect
node1 to be None. commands.revpair() usage means that commands.dodiff()
never sends node1 == None. This is fixed in localrepo.changes by checking
against the dirstate parents.
In the non-dirstate parents case, localrepo.changes does a loop comparing
files without first sorting the file names, leading to random access
across the disk.
now all repositories have capabilities slot, tuple with list of names.
if 'unbundle' capability present, repo supports push where client does
not need to lock server. repository classes that have unbundle capability
also have unbundle method.
implemented for ssh now, will be base for push over http.
unbundle protocol acts this way. server tells client what heads it
has during normal negotiate step. client starts unbundle by repeat
server's heads back to it. if server has new heads, abort immediately.
otherwise, transfer changes to server. once data transferred, server
locks and checks heads again. if heads same, changes can be added.
else someone else added heads, and server aborts.
if client wants to force server to add heads, sends special heads list of
'force'.
Use case: If a remote repo has two heads and I _want_ to merge them, I merge
and push. Meanwhile someone else pushed on top of one of the heads. He won't
get a warning, because he doesn't create a new head, I won't notice that I
don't close a head, because I don't get a message telling me.
The number of csets and the hooks where wrong (negative number of csets) when
we unbundled a bundle which contains csets we already had.
Remove unused variables.
- add documentation about what the function does, notably
the fact that it updates 'base'
- transform the workflow to a more simple 'if elif elif else'
- do not call remote.branches if not necessary
- some nodes where missing in 'base' (from what I understand,
if the root of a branch is missing but one parent is present,
the parent should be in 'base')
- add a testcase for an incorrect outgoing that is fixed by
this cset
- add a testcase for an empty group bug, it needs fixing
old code read every head of .hgtags. delete and recreate of .hgtags gave
new head, but if error in deleted rev, .hgtags had error messages every
time it was parsed. this was very hard to fix, because deleted revs hard
to get back and update, needed merges too.
new code reads .hgtags on every head. advantage is if parse error
happens with new code, is possible to fix them by editing .hgtags on a
head and committing.
NOTE: new code uses binary search of manifest of each head to be fast,
but still much slower than old code. best thing would be to have delete
record stored in filelog so we never touch manifest. could find live
heads directly from filelog. this is more work than i want now.
new tests check for parse of tags on different heads, and inaccessible
heads created by delete and recreate of .hgtags.
This changes revlog specify revlogng by default. Inlined
data files are also used unless a flags option is found in the .hgrc.
Some example hgrc files:
[revlog]
# use the original revlog format
format=0
[revlog]
# use revlogng. Because no flags are included, inlined data files
# also be selected
format=1
[revlog]
# use revlogng but do not inline the data files with the index
flags=
[revlog]
# the new default
format=1
flags=inline
