Fri, 14 Mar 2008 21:35:49 +0100 make sure not to reuse an existing append-file from a previous failed pull
Benoit Boissinot <benoit.boissinot@ens-lyon.org> [Fri, 14 Mar 2008 21:35:49 +0100] rev 6259
make sure not to reuse an existing append-file from a previous failed pull
Fri, 14 Mar 2008 10:32:19 -0300 Fix issue995 (copy --after and symlinks pointing to a directory)
Alexis S. L. Carvalho <alexis@cecm.usp.br> [Fri, 14 Mar 2008 10:32:19 -0300] rev 6258
Fix issue995 (copy --after and symlinks pointing to a directory) I haven't looked at other places that call os.path.isdir to make sure they're OK.
Fri, 14 Mar 2008 09:56:58 -0300 dirstate: ignore mode changes if the fs does not supports the exec bit
Alexis S. L. Carvalho <alexis@cecm.usp.br> [Fri, 14 Mar 2008 09:56:58 -0300] rev 6257
dirstate: ignore mode changes if the fs does not supports the exec bit This can make a difference when e.g. the repo is exported through NFS (which support exec bits) and CIFS (which does not).
Fri, 14 Mar 2008 09:56:58 -0300 merge: require --force when there are deleted files
Alexis S. L. Carvalho <alexis@cecm.usp.br> [Fri, 14 Mar 2008 09:56:58 -0300] rev 6256
merge: require --force when there are deleted files
Fri, 14 Mar 2008 09:56:58 -0300 add a test for a375ffc2aa1b
Alexis S. L. Carvalho <alexis@cecm.usp.br> [Fri, 14 Mar 2008 09:56:58 -0300] rev 6255
add a test for a375ffc2aa1b
Fri, 14 Mar 2008 09:56:58 -0300 localrepo.commit: normalize commit message even for rawcommit.
Alexis S. L. Carvalho <alexis@cecm.usp.br> [Fri, 14 Mar 2008 09:56:58 -0300] rev 6254
localrepo.commit: normalize commit message even for rawcommit. This normalization consists of: - stripping trailing whitespace - always using "\n" as the line separator I think the main reason rawcommit was skipping this normalization was an attempt to preserve hashes during an hg->hg conversion. While this is a nice goal, it's not particularly interesting in practice. Since SHA-1 is so strong, the only safe way to do it is to have absolutely identical revisions. But: - if the original revision was created with a recent version of hg, the commit message will be the same, with or without that normalization - if it was created with an ancient version of hg that didn't do any normalization, even if the commit message is identical, the file list in the changelog is likely to be different (e.g. no removed files), and there were some old issues with e.g. extra file merging, which will end up changing the hash anyway - in any case, if one *really* has to preserve hashes, it's easier (and faster) to fake a partial conversion using something like: hg clone -U -r rev orig-repo new-repo hg -R new-repo log --template '#node# #node#\n' > new-repo/.hg/shamap Additionally, we've had some reports of problems arising from this lack of normalization - e.g. issue871, and a user that was wondering why hg export/hg import was not preserving hashes when there was nothing unusual going on (it was just import doing the normalization that had been skipped). This also means that it's even more unlikely to get identical revisions when going $VCS->hg->$VCS.
(0) -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip