merge: short-circuit search for merge into empty repo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
merge: short-circuit search for merge into empty repo
We should have 3 cases for merge:
- - we have no changesets
- - we have less than half the changesets
- - we have more than half the changesets
For no changesets, we can immediately tell that we need everything.
This happens when we initially branch from a remote repo, so we simply shortcircuit the search and grab everything from the root
When we're actually tracking a project, we should generally have most
of the changesets, so the current search algorithm should minimize
searching.
It should rarely occur that upstreams gets far ahead of us, in which
case, we suffer a longer search.
manifest hash: eabd55841b03225176ea72b985aad36431a438a9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCmfajywK+sNU5EO8RAuyKAKCf7Nw6XSK5HEzbrZae7Q06e3dk4wCgjbK6
YUTEfkpPP1h3mNHIHRKz+aI=
=eGMq
-----END PGP SIGNATURE-----
Mercurial git BK (*)
storage revlog delta compressed revisions SCCS weave
storage naming by filename by revision hash by filename
merge file DAGs changeset DAG file DAGs?
consistency SHA1 SHA1 CRC
signable? yes yes no
retrieve file tip O(1) O(1) O(revs)
add rev O(1) O(1) O(revs)
find prev file rev O(1) O(changesets) O(revs)
annotate file O(revs) O(changesets) O(revs)
find file changeset O(1) O(changesets) ?
checkout O(files) O(files) O(revs)?
commit O(changes) O(changes) ?
6 patches/s 6 patches/s slow
diff working dir O(changes) O(changes) ?
< 1s < 1s ?
tree diff revs O(changes) O(changes) ?
< 1s < 1s ?
hardlink clone O(files) O(revisions) O(files)
find remote csets O(log new) rsync: O(revisions) ?
git-http: O(changesets)
pull remote csets O(patch) O(modified files) O(patch)
repo growth O(patch) O(revisions) O(patch)
kernel history 300M 3.5G? 250M?
lines of code 2500 6500 (+ cogito) ??
* I've never used BK so this is just guesses