Disable automatic line endings conversion on windows
The rationale behind this is that such conversion implies a particular
situation in which all files in the repo are terminated by only LF. This
is documented nowhere and it bit me sharply when I upgraded.
Furthermore, it works on the assumption that a file containing no NULL
characters are actually a text file. Therefore it cannot guarantee that
no binary file will be harmed in the process.
Currently, if a file already contains CRLF line endings when it is
copied to the working dir from the repo, then the version in the working
dir will be corrupted by an extra CR.
I'm working on a patch that will turn this into a warning. But as a side
effect, committing such a file back will strip it from its CR.
In all case, unrequested data modification can occur under the feet of
the user, which is bad(tm), ihmo.
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