http://127.0.0.1:3001/hgsubversion/ en-us tests/fixtures/renames.svndump revision history http://127.0.0.1:3001/hgsubversion/log/0d0132cba155/tests/fixtures/renames.svndump
There are a few cases where we will set a single file into to the
editor's FileStore object more than once. Notably, for copied and
then modified files, we will set it at least twice. Three times if
editing fails (which it can for symlinks).

If we pass the in-memory storage limit in between the first (or second
if editing fails) time we set the file and the last time we set the
file, we will write the data to the in memory store the first time and
the file store the last time. We didn't remove it form the in-memory
store though, and we always prefer reading from the in-memory store.
This means we can sometimes end up with the wrong version of a file.

This is fairly unlikely to happen in normal use since you need to hit
the memory limit between two writes to the store for the same file.
We only write a file multiple times if a) the file (and not one of
it's parent directories) is copied and then modified or b) editing
fails. From what I can tell, it's only common for editing to fail for
symlinks, and they ten to be relatively small data that is unlikely to
push over the limit. Finally, the default limit is 100MB which I
would expect to be most often either well over (source code) or well
under (binaries or automated changes) the size of the changes files in
a single commit.

The easiest way to reproduce this is to set the in-memory cache size
to 0 and then commit a copied and modified symlink. The empty-string
version from the failed editing will be the one that persists. I
happened to stumble upon this while trying (and failing) to test a
bug-fix for a related bug with identical symptoms (empty simlink). I
have seen this in the wild, once, but couldn't reproduce it at the
time. The repo in question is quite large and quite active, so I am
quite confident in my estimation that this is a real, but very rare,
problem.

The test changes attached to this was mneant to test a related bug,
but turned out not to actually cover the bug in question. They did
trigger this bug though, and are worthwhile to test, so I kept them.]]> David Schleimer <dschleimer@fb.com> Mon, 07 Apr 2014 17:51:59 -0700 http://127.0.0.1:3001/hgsubversion/log/c2a84d436202/tests/fixtures/renames.svndump Patrick Mezard <pmezard@gmail.com> Wed, 10 Dec 2008 11:03:22 -0600 http://127.0.0.1:3001/hgsubversion/log/bf1e8b8ed452/tests/fixtures/renames.svndump Patrick Mezard <pmezard@gmail.com> Wed, 05 Nov 2008 13:37:08 +0100 http://127.0.0.1:3001/hgsubversion/log/63ece4ea25c9/tests/fixtures/renames.svndump
Handle copies of items from revision X into revision Y where X is not the
parent of Y. This cannot happen in Mercurial because copies always happen
between parents and children. A file copy is recorded if:
1- Source and destination revs are in the same branch.
2- The file is unchanged (content, type, removal) through all revisions between
destination and source, not including source and destination.

Directory copies are registered only if the previous rules apply on all copied
items.

[1] is there because file copies across branches are meaningless in Mercurial
world. We could have tried to remap the source rev to a similar one in the
correct branch, but anyway the intent is wrong.

[2] is more questionable but I think it's better this way for we live in a
non-perfect svn world. In theory, 99% of copies out there should come from the
direct parent. But the direct parent is a fuzzy notion when you can have a
working directory composed of different directory at different revisions. So we
assume that stuff copied from past revisions exactly matching the content of
the direct parent revision is really copied from the parent revision. The
alternative would be to discard the copy, which would always happen unless
people kept updating the working directory after every commit (see
tests).]]> Patrick Mezard <pmezard@gmail.com> Wed, 05 Nov 2008 13:37:08 +0100 http://127.0.0.1:3001/hgsubversion/log/e0c86ebe05e3/tests/fixtures/renames.svndump Patrick Mezard <pmezard@gmail.com> Wed, 05 Nov 2008 13:37:08 +0100 http://127.0.0.1:3001/hgsubversion/log/e319c9168910/tests/fixtures/renames.svndump Patrick Mezard <pmezard@gmail.com> Wed, 05 Nov 2008 13:37:07 +0100