INCOMING PATCHES
Test case: give me a shell script, testpatch:
testpatch [repository] -r<rev1> -r<rev2>
The revs are cset revs, earlier followed by later.
The test does the following:
if they specified repository then cd there fi bk export -kwr<rev1> /tmp/tp1$$ bk export -kwr<rev2> /tmp/tp2$$ bk resync -r..<rev1> /tmp/tpr$$ cd /tmp diff -Nru tp1$$ tp2$$ > /tmp/P$$ cd tpr$$ bk -r edit -q patch -p1 < ../P # Freak out if there are .rej cd /tmp diff -Nru <whatever option it is to ignore SCCS> tpr$$ tp2$$ # freak out if not the same
RENAMES
Construct some little test cases (or find them in our tree) where the following happens:
a) a file is deleted XXX - make sure that if patch deletes a file which has an s.file and a p.file associated with it, that patch doesn't screw with those. b) a file is moved someplace else c) a file is deleted and a new file is created on top d) a file is deleted and another file is moved on top of it
------
Next step is to pick up /home/bk/lm/src/gnu and figure out how to extract the creates and deletes from patch. Run with --verbose and the information you want is printed, mixed in with a bunch of other garbage.
First, extract the create/delete events from the patch output. Second, construct information for renametool so that you can hand it the lists. It wants a file like this on stdin
file/which/was/deleted another/delete and/one/more
file/which/was/added another/add another/file/added and/one/more