Mercurial > hgsubversion
view tests/fixtures/renames.sh @ 1233:0d0132cba155
editor: fix edge case with in memory file-store size limit
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.
| author | David Schleimer <dschleimer@fb.com> |
|---|---|
| date | Mon, 07 Apr 2014 17:51:59 -0700 |
| parents | c2a84d436202 |
| children |
line wrap: on
line source
#!/bin/sh # # Generate renames.svndump # set -e rm -rf temp mkdir temp cd temp mkdir project-orig cd project-orig mkdir trunk mkdir branches cd .. svnadmin create testrepo svnurl=file://`pwd`/testrepo svn import project-orig $svnurl -m "init project" svn co $svnurl project cd project/trunk # Entries for regular tests echo a > a echo b > b ln -s a linka ln -s b linkb mkdir -p da/db echo c > da/daf ln -s daf da/dalink echo d > da/db/dbf ln -s ../daf da/db/dblink # Entries to test delete + copy echo deleted > deletedfile ln -s b deletedlink mkdir deleteddir echo deleteddir > deleteddir/f ln -s f deleteddir/link # Entries to test copy before change echo changed > changed ln -s changed changedlink mkdir changeddir echo changed2 > changeddir/f ln -s f changeddir/link # Entries unchanged in the rest of history echo unchanged > unchanged ln -s unchanged unchangedlink mkdir unchangeddir echo unchanged2 > unchangeddir/f ln -s f unchangeddir/link # One of the files will be changed afterwards, to test # group copies detection mkdir groupdir echo a > groupdir/a echo b > groupdir/b ln -s a groupdir/linka ln -s b groupdir/linkb svn add a b linka linkb da deleted* changed* unchanged* groupdir svn ci -m "add everything" # Remove files to be copied later svn rm deletedfile svn rm deleteddir svn rm deletedlink # Update files to be copied before this change echo changed >> changed echo changed2 >> changeddir/f ln -sfn changeddir/f changedlink ln -sfn ../changed changeddir/link # Update one of the groupdir files echo a >> groupdir/a ln -sfn ../a groupdir/linka svn ci -m "delete files and dirs" cd ../branches svn cp ../trunk branch1 svn ci -m "create branch1" cd branch1 echo c > c ln -s c linkc svn add c linkc svn ci -m "add c and linkc" cd ../../trunk # Regular copy and rename svn cp a a1 svn cp linka linka1 svn mv a a2 svn mv linka linka2 # Copy and update of source and dest svn cp b b1 svn cp linkb linkb1 echo b >> b echo c >> b1 ln -sfn bb linkb ln -sfn bc linkb1 # Directory copy and renaming svn cp da da1 svn mv da da2 # Test one copy operation in branch cd ../branches/branch1 svn cp c c1 svn cp linkc linkc1 echo c >> c1 ln -sfn cc linkc1 cd ../.. svn ci -m "rename and copy a, b, c and da, plus their links" cd trunk # Copy across branch svn cp ../branches/branch1/c c svn cp ../branches/branch1/linkc linkc svn ci -m "copy c from branch1" # Copy deleted stuff from the past svn cp $svnurl/trunk/deletedfile@2 deletedfile svn cp $svnurl/trunk/deleteddir@2 deleteddir svn cp $svnurl/trunk/deletedlink@2 deletedlink svn ci -m "copy stuff from the past" # Copy data from the past before it was changed svn cp $svnurl/trunk/changed@2 changed2 svn cp $svnurl/trunk/changeddir@2 changeddir2 svn cp $svnurl/trunk/changedlink@2 changedlink2 # Harder, copy from the past before change and change it again # This confused the stupid diff path svn cp $svnurl/trunk/changed@2 changed3 svn cp $svnurl/trunk/changedlink@2 changedlink3 echo changed3 >> changed3 ln -sfn changed3 changedlink3 svn ci -m "copy stuff from the past before change" # Copy unchanged stuff from the past. Since no changed occured in these files # between the source and parent revision, we record them as copy from parent # instead of source rev. svn cp $svnurl/trunk/unchanged@2 unchanged2 svn cp $svnurl/trunk/unchangeddir@2 unchangeddir2 svn cp $svnurl/trunk/unchangedlink@2 unchangedlink2 svn ci -m "copy unchanged stuff from the past" # Copy groupdir, unfortunately one file was changed after r2 so the # copy should not be recorded at all svn cp $svnurl/trunk/groupdir@2 groupdir2 svn ci -m "copy groupdir from the past" cd ../.. svnadmin dump testrepo > ../renames.svndump