view comparison.txt @ 1587:851bc33ff545

Less annoying directory completion (see http://bugs.debian.org/343458)

The current bash completion script is quite painful in conjuntion with
deep directory trees because it adds a space after each successful
directory completion. Eg. "hg clone /ho<tab>" is completed to "hg clone
/home " when what you really want is "hg clone /home/" (assuming the
complete path to the repository looks like /home/foo/hg...).

That's because the 'complete' command does not know about the type of
completion it receives from the _hg shell function. When only a single
completion is returned, it assumes completion is complete and tells
readline to add a trailing space. This behaviour is usually wanted, but
not in the case of directory completion.

I've attached a patch that circumvents this problem by only returning
successful completions for directories that contain a .hg subdirectory.
If no repositories are found, no completions are returned either, and
bash falls back to ordinary (filename) completion. I find this behaviour
a lot less annoying than the current one.

Alternative: Use option nospace for the 'complete' command and let _hg
itself take care of adding a trailing space where appropriate. That's a
far more intrusive change, though.

                    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