git-commit-vandalism/t/t9151/svn-mergeinfo.dump

1923 lines
41 KiB
Plaintext
Raw Normal View History

SVN-fs-dump-format-version: 2
UUID: d6191530-2693-4a8e-98e7-b194d4c3edd8
Revision-number: 0
Prop-content-length: 56
Content-length: 56
K 8
svn:date
V 27
2010-01-19T04:14:02.832406Z
PROPS-END
Revision-number: 1
Prop-content-length: 134
Content-length: 134
K 7
svn:log
V 36
(r1) Setup trunk, branches, and tags
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:03.055172Z
PROPS-END
Node-path: branches
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Node-path: tags
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Revision-number: 2
Prop-content-length: 111
Content-length: 111
K 7
svn:log
V 13
(r2) ancestor
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:04.064506Z
PROPS-END
Node-path: trunk/Makefile
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 2401
Text-content-md5: bfd8ff778d1492dc6758567373176a89
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Text-content-sha1: 103205ce331f7d64086dba497574734f78439590
Content-length: 2411
PROPS-END
# -DCOLLISION_CHECK if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# enough guarantees about no collisions between objects ever hapenning.
#
# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
# Note that you need some new glibc (at least >2.2.4) for this, and it will
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
CFLAGS=-g -O3 -Wall
CC=gcc
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
check-files ls-tree merge-base
all: $(PROG)
install: $(PROG)
install $(PROG) $(HOME)/bin/
LIBS= -lssl -lz
init-db: init-db.o
update-cache: update-cache.o read-cache.o
$(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
show-diff: show-diff.o read-cache.o
$(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
write-tree: write-tree.o read-cache.o
$(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
read-tree: read-tree.o read-cache.o
$(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
commit-tree: commit-tree.o read-cache.o
$(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
cat-file: cat-file.o read-cache.o
$(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
fsck-cache: fsck-cache.o read-cache.o
$(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o $(LIBS)
checkout-cache: checkout-cache.o read-cache.o
$(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
diff-tree: diff-tree.o read-cache.o
$(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
rev-tree: rev-tree.o read-cache.o
$(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o $(LIBS)
show-files: show-files.o read-cache.o
$(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
check-files: check-files.o read-cache.o
$(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
ls-tree: ls-tree.o read-cache.o
$(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
merge-base: merge-base.o read-cache.o
$(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o $(LIBS)
read-cache.o: cache.h
show-diff.o: cache.h
clean:
rm -f *.o $(PROG)
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
Revision-number: 3
Prop-content-length: 119
Content-length: 119
K 7
svn:log
V 21
(r3) make left branch
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:06.040389Z
PROPS-END
Node-path: branches/left
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 1
Node-copyfrom-path: trunk
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Node-path: branches/left/Makefile
Node-kind: file
Node-action: add
Node-copyfrom-rev: 2
Node-copyfrom-path: trunk/Makefile
Text-copy-source-md5: bfd8ff778d1492dc6758567373176a89
Text-copy-source-sha1: 103205ce331f7d64086dba497574734f78439590
Revision-number: 4
Prop-content-length: 120
Content-length: 120
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 7
svn:log
V 22
(r4) make right branch
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 10
svn:author
V 3
adm
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 8
svn:date
V 27
2010-01-19T04:14:08.040905Z
PROPS-END
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Node-path: branches/right
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 1
Node-copyfrom-path: trunk
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Node-path: branches/right/Makefile
Node-kind: file
Node-action: add
Node-copyfrom-rev: 2
Node-copyfrom-path: trunk/Makefile
Text-copy-source-md5: bfd8ff778d1492dc6758567373176a89
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Text-copy-source-sha1: 103205ce331f7d64086dba497574734f78439590
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Revision-number: 5
Prop-content-length: 116
Content-length: 116
K 7
svn:log
V 18
(r5) left update 1
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:09.049169Z
PROPS-END
Node-path: branches/left/Makefile
Node-kind: file
Node-action: change
Text-content-length: 2465
Text-content-md5: 16e38d9753b061731650561ce01b1195
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Text-content-sha1: 36da4b84ea9b64218ab48171dfc5c48ae025f38b
Content-length: 2465
# -DCOLLISION_CHECK if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# enough guarantees about no collisions between objects ever hapenning.
#
# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
# Note that you need some new glibc (at least >2.2.4) for this, and it will
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
CFLAGS=-g -O3 -Wall
CC=gcc
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
check-files ls-tree merge-base
all: $(PROG)
install: $(PROG)
install $(PROG) $(HOME)/bin/
LIBS= -lssl -lz
init-db: init-db.o
update-cache: update-cache.o read-cache.o
$(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
show-diff: show-diff.o read-cache.o
$(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
write-tree: write-tree.o read-cache.o
$(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
read-tree: read-tree.o read-cache.o
$(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
commit-tree: commit-tree.o read-cache.o
$(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
cat-file: cat-file.o read-cache.o
$(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
fsck-cache: fsck-cache.o read-cache.o
$(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o $(LIBS)
checkout-cache: checkout-cache.o read-cache.o
$(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
diff-tree: diff-tree.o read-cache.o
$(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
rev-tree: rev-tree.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
show-files: show-files.o read-cache.o
$(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
check-files: check-files.o read-cache.o
$(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
ls-tree: ls-tree.o read-cache.o
$(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
merge-base: merge-base.o read-cache.o
$(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o $(LIBS)
read-cache.o: cache.h
show-diff.o: cache.h
clean:
rm -f *.o $(PROG)
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Revision-number: 6
Prop-content-length: 117
Content-length: 117
K 7
svn:log
V 19
(r6) right update 1
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:10.049350Z
PROPS-END
Node-path: branches/right/Makefile
Node-kind: file
Node-action: change
Text-content-length: 2521
Text-content-md5: 0668418a621333f4aa8b6632cd63e2a0
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Text-content-sha1: 4f29afd038e52f45acb5ef8c41acfc70062a741a
Content-length: 2521
# -DCOLLISION_CHECK if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# enough guarantees about no collisions between objects ever hapenning.
#
# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
# Note that you need some new glibc (at least >2.2.4) for this, and it will
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
CFLAGS=-g -O3 -Wall
CC=gcc
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
check-files ls-tree merge-base merge-cache
all: $(PROG)
install: $(PROG)
install $(PROG) $(HOME)/bin/
LIBS= -lssl -lz
init-db: init-db.o
update-cache: update-cache.o read-cache.o
$(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
show-diff: show-diff.o read-cache.o
$(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
write-tree: write-tree.o read-cache.o
$(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
read-tree: read-tree.o read-cache.o
$(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
commit-tree: commit-tree.o read-cache.o
$(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
cat-file: cat-file.o read-cache.o
$(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
fsck-cache: fsck-cache.o read-cache.o
$(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o $(LIBS)
checkout-cache: checkout-cache.o read-cache.o
$(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
diff-tree: diff-tree.o read-cache.o
$(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
rev-tree: rev-tree.o read-cache.o
$(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o $(LIBS)
show-files: show-files.o read-cache.o
$(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
check-files: check-files.o read-cache.o
$(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
ls-tree: ls-tree.o read-cache.o
$(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
merge-base: merge-base.o read-cache.o
$(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o $(LIBS)
merge-cache: merge-cache.o read-cache.o
$(CC) $(CFLAGS) -o merge-cache merge-cache.o read-cache.o $(LIBS)
read-cache.o: cache.h
show-diff.o: cache.h
clean:
rm -f *.o $(PROG)
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Revision-number: 7
Prop-content-length: 116
Content-length: 116
K 7
svn:log
V 18
(r7) left update 2
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:11.049209Z
PROPS-END
Node-path: branches/left/Makefile
Node-kind: file
Node-action: change
Text-content-length: 2529
Text-content-md5: f6b197cc3f2e89a83e545d4bb003de73
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Text-content-sha1: 2f656677cfec0bceec85e53036ffb63e25126f8e
Content-length: 2529
# -DCOLLISION_CHECK if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# enough guarantees about no collisions between objects ever hapenning.
#
# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
# Note that you need some new glibc (at least >2.2.4) for this, and it will
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
CFLAGS=-g -O3 -Wall
CC=gcc
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
check-files ls-tree merge-base
all: $(PROG)
install: $(PROG)
install $(PROG) $(HOME)/bin/
LIBS= -lssl -lz
init-db: init-db.o
update-cache: update-cache.o read-cache.o
$(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
show-diff: show-diff.o read-cache.o
$(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
write-tree: write-tree.o read-cache.o
$(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
read-tree: read-tree.o read-cache.o
$(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
commit-tree: commit-tree.o read-cache.o
$(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
cat-file: cat-file.o read-cache.o
$(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
fsck-cache: fsck-cache.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
checkout-cache: checkout-cache.o read-cache.o
$(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
diff-tree: diff-tree.o read-cache.o
$(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
rev-tree: rev-tree.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
show-files: show-files.o read-cache.o
$(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
check-files: check-files.o read-cache.o
$(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
ls-tree: ls-tree.o read-cache.o
$(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
merge-base: merge-base.o read-cache.o
$(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o $(LIBS)
read-cache.o: cache.h
show-diff.o: cache.h
clean:
rm -f *.o $(PROG)
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Revision-number: 8
Prop-content-length: 116
Content-length: 116
K 7
svn:log
V 18
(r8) left update 3
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:12.049234Z
PROPS-END
Node-path: branches/left/Makefile
Node-kind: file
Node-action: change
Text-content-length: 2593
Text-content-md5: 5ccff689fb290e00b85fe18ee50c54ba
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Text-content-sha1: a13de8e23f1483efca3e57b2b64b0ae6f740ce10
Content-length: 2593
# -DCOLLISION_CHECK if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# enough guarantees about no collisions between objects ever hapenning.
#
# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
# Note that you need some new glibc (at least >2.2.4) for this, and it will
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
CFLAGS=-g -O3 -Wall
CC=gcc
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
check-files ls-tree merge-base
all: $(PROG)
install: $(PROG)
install $(PROG) $(HOME)/bin/
LIBS= -lssl -lz
init-db: init-db.o
update-cache: update-cache.o read-cache.o
$(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
show-diff: show-diff.o read-cache.o
$(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
write-tree: write-tree.o read-cache.o
$(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
read-tree: read-tree.o read-cache.o
$(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
commit-tree: commit-tree.o read-cache.o
$(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
cat-file: cat-file.o read-cache.o
$(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
fsck-cache: fsck-cache.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
checkout-cache: checkout-cache.o read-cache.o
$(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
diff-tree: diff-tree.o read-cache.o
$(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
rev-tree: rev-tree.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
show-files: show-files.o read-cache.o
$(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
check-files: check-files.o read-cache.o
$(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
ls-tree: ls-tree.o read-cache.o
$(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
merge-base: merge-base.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
read-cache.o: cache.h
show-diff.o: cache.h
clean:
rm -f *.o $(PROG)
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Revision-number: 9
Prop-content-length: 123
Content-length: 123
K 7
svn:log
V 25
(r9) make left sub-branch
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:14.040894Z
PROPS-END
Node-path: branches/left-sub
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 3
Node-copyfrom-path: branches/left
Node-path: branches/left-sub/Makefile
Node-kind: file
Node-action: delete
Node-path: branches/left-sub/Makefile
Node-kind: file
Node-action: add
Node-copyfrom-rev: 8
Node-copyfrom-path: branches/left/Makefile
Text-copy-source-md5: 5ccff689fb290e00b85fe18ee50c54ba
Text-copy-source-sha1: a13de8e23f1483efca3e57b2b64b0ae6f740ce10
Revision-number: 10
Prop-content-length: 128
Content-length: 128
K 7
svn:log
V 30
(r10) left sub-branch update 1
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:15.049935Z
PROPS-END
Node-path: branches/left-sub/README
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 7
Text-content-md5: fdbcfb6be9afe1121862143f226b51cf
Text-content-sha1: 1d1f5ea4ceb584337ffe59b8980d92e3b78dfef4
Content-length: 17
PROPS-END
crunch
Revision-number: 11
Prop-content-length: 125
Content-length: 125
K 7
svn:log
V 27
(r11) Merge left to trunk 1
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:18.056594Z
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: change
Prop-content-length: 54
Content-length: 54
K 13
svn:mergeinfo
V 19
/branches/left:2-10
PROPS-END
Node-path: trunk/Makefile
Node-kind: file
Node-action: change
Text-content-length: 2593
Text-content-md5: 5ccff689fb290e00b85fe18ee50c54ba
Text-content-sha1: a13de8e23f1483efca3e57b2b64b0ae6f740ce10
Content-length: 2593
# -DCOLLISION_CHECK if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# enough guarantees about no collisions between objects ever hapenning.
#
# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
# Note that you need some new glibc (at least >2.2.4) for this, and it will
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
CFLAGS=-g -O3 -Wall
CC=gcc
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
check-files ls-tree merge-base
all: $(PROG)
install: $(PROG)
install $(PROG) $(HOME)/bin/
LIBS= -lssl -lz
init-db: init-db.o
update-cache: update-cache.o read-cache.o
$(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
show-diff: show-diff.o read-cache.o
$(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
write-tree: write-tree.o read-cache.o
$(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
read-tree: read-tree.o read-cache.o
$(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
commit-tree: commit-tree.o read-cache.o
$(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
cat-file: cat-file.o read-cache.o
$(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
fsck-cache: fsck-cache.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
checkout-cache: checkout-cache.o read-cache.o
$(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
diff-tree: diff-tree.o read-cache.o
$(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
rev-tree: rev-tree.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
show-files: show-files.o read-cache.o
$(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
check-files: check-files.o read-cache.o
$(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
ls-tree: ls-tree.o read-cache.o
$(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
merge-base: merge-base.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
read-cache.o: cache.h
show-diff.o: cache.h
clean:
rm -f *.o $(PROG)
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
Revision-number: 12
Prop-content-length: 117
Content-length: 117
K 7
svn:log
V 19
(r12) left update 4
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:19.049620Z
PROPS-END
Node-path: branches/left/zlonk
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 7
Text-content-md5: 8b9d8c7c2aaa6167e7d3407a773bbbba
Text-content-sha1: 9716527ebd70a75c27625cacbeb2d897c6e86178
Content-length: 17
PROPS-END
touche
Revision-number: 13
Prop-content-length: 118
Content-length: 118
K 7
svn:log
V 20
(r13) right update 2
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:20.049659Z
PROPS-END
Node-path: branches/right/bang
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 8
Text-content-md5: 34c28f1d2dc6a9adeccc4265bf7516cb
Text-content-sha1: 0bc5bb345c0e71d28f784f12e0bd2d384c283062
Content-length: 18
PROPS-END
thwacke
Revision-number: 14
Prop-content-length: 140
Content-length: 140
K 7
svn:log
V 42
(r14) Cherry-pick right 2 commits to trunk
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:23.041991Z
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: change
Prop-content-length: 75
Content-length: 75
K 13
svn:mergeinfo
V 40
/branches/left:2-10
/branches/right:6-13
PROPS-END
Node-path: trunk/Makefile
Node-kind: file
Node-action: change
Text-content-length: 2713
Text-content-md5: 0afbe34f244cd662b1f97d708c687f90
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Text-content-sha1: 46d9377d783e67a9b581da110352e799517c8a14
Content-length: 2713
# -DCOLLISION_CHECK if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# enough guarantees about no collisions between objects ever hapenning.
#
# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
# Note that you need some new glibc (at least >2.2.4) for this, and it will
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
CFLAGS=-g -O3 -Wall
CC=gcc
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
check-files ls-tree merge-base merge-cache
all: $(PROG)
install: $(PROG)
install $(PROG) $(HOME)/bin/
LIBS= -lssl -lz
init-db: init-db.o
update-cache: update-cache.o read-cache.o
$(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
show-diff: show-diff.o read-cache.o
$(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
write-tree: write-tree.o read-cache.o
$(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
read-tree: read-tree.o read-cache.o
$(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
commit-tree: commit-tree.o read-cache.o
$(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
cat-file: cat-file.o read-cache.o
$(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
fsck-cache: fsck-cache.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
checkout-cache: checkout-cache.o read-cache.o
$(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
diff-tree: diff-tree.o read-cache.o
$(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
rev-tree: rev-tree.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
show-files: show-files.o read-cache.o
$(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
check-files: check-files.o read-cache.o
$(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
ls-tree: ls-tree.o read-cache.o
$(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
merge-base: merge-base.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
merge-cache: merge-cache.o read-cache.o
$(CC) $(CFLAGS) -o merge-cache merge-cache.o read-cache.o $(LIBS)
read-cache.o: cache.h
show-diff.o: cache.h
clean:
rm -f *.o $(PROG)
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
Node-path: trunk/bang
Node-kind: file
Node-action: add
Node-copyfrom-rev: 13
Node-copyfrom-path: branches/right/bang
Text-copy-source-md5: 34c28f1d2dc6a9adeccc4265bf7516cb
Text-copy-source-sha1: 0bc5bb345c0e71d28f784f12e0bd2d384c283062
Revision-number: 15
Prop-content-length: 126
Content-length: 126
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 7
svn:log
V 28
(r15) Merge right to trunk 1
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 10
svn:author
V 3
adm
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 8
svn:date
V 27
2010-01-19T04:14:26.054456Z
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: change
Prop-content-length: 75
Content-length: 75
K 13
svn:mergeinfo
V 40
/branches/left:2-10
/branches/right:2-14
PROPS-END
Revision-number: 16
Prop-content-length: 118
Content-length: 118
K 7
svn:log
V 20
(r16) right update 3
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:27.049955Z
PROPS-END
Node-path: branches/right/urkkk
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 6
Text-content-md5: 5889c8392e16251b0c80927607a03036
Text-content-sha1: 3934264d277a0cf886b6b1c7f2b9e56da2525302
Content-length: 16
PROPS-END
whamm
Revision-number: 17
Prop-content-length: 118
Content-length: 118
K 7
svn:log
V 20
(r17) trunk update 1
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:28.049615Z
PROPS-END
Node-path: trunk/vronk
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 4
Text-content-md5: b2f80fa02a7f1364b9c29d3da44bf9f9
Text-content-sha1: e994d980c0f2d7a3f76138bf96d57f36f9633828
Content-length: 14
PROPS-END
pow
Revision-number: 18
Prop-content-length: 134
Content-length: 134
K 7
svn:log
V 36
(r18) Merge right to left sub-branch
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:31.061460Z
PROPS-END
Node-path: branches/left-sub
Node-kind: dir
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Node-action: change
Prop-content-length: 55
Content-length: 55
K 13
svn:mergeinfo
V 20
/branches/right:2-17
PROPS-END
Node-path: branches/left-sub/Makefile
Node-kind: file
Node-action: change
Text-content-length: 2713
Text-content-md5: 0afbe34f244cd662b1f97d708c687f90
Text-content-sha1: 46d9377d783e67a9b581da110352e799517c8a14
Content-length: 2713
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
# -DCOLLISION_CHECK if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# enough guarantees about no collisions between objects ever hapenning.
#
# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
# Note that you need some new glibc (at least >2.2.4) for this, and it will
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
CFLAGS=-g -O3 -Wall
CC=gcc
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
check-files ls-tree merge-base merge-cache
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
all: $(PROG)
install: $(PROG)
install $(PROG) $(HOME)/bin/
LIBS= -lssl -lz
init-db: init-db.o
update-cache: update-cache.o read-cache.o
$(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
show-diff: show-diff.o read-cache.o
$(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
write-tree: write-tree.o read-cache.o
$(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
read-tree: read-tree.o read-cache.o
$(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
commit-tree: commit-tree.o read-cache.o
$(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
cat-file: cat-file.o read-cache.o
$(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
fsck-cache: fsck-cache.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
checkout-cache: checkout-cache.o read-cache.o
$(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
diff-tree: diff-tree.o read-cache.o
$(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
rev-tree: rev-tree.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
show-files: show-files.o read-cache.o
$(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
check-files: check-files.o read-cache.o
$(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
ls-tree: ls-tree.o read-cache.o
$(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
merge-base: merge-base.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
merge-cache: merge-cache.o read-cache.o
$(CC) $(CFLAGS) -o merge-cache merge-cache.o read-cache.o $(LIBS)
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
read-cache.o: cache.h
show-diff.o: cache.h
clean:
rm -f *.o $(PROG)
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
Node-path: branches/left-sub/bang
Node-kind: file
Node-action: add
Node-copyfrom-rev: 17
Node-copyfrom-path: branches/right/bang
Text-copy-source-md5: 34c28f1d2dc6a9adeccc4265bf7516cb
Text-copy-source-sha1: 0bc5bb345c0e71d28f784f12e0bd2d384c283062
Node-path: branches/left-sub/urkkk
Node-kind: file
Node-action: add
Node-copyfrom-rev: 17
Node-copyfrom-path: branches/right/urkkk
Text-copy-source-md5: 5889c8392e16251b0c80927607a03036
Text-copy-source-sha1: 3934264d277a0cf886b6b1c7f2b9e56da2525302
Revision-number: 19
Prop-content-length: 128
Content-length: 128
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 7
svn:log
V 30
(r19) left sub-branch update 2
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 10
svn:author
V 3
adm
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 8
svn:date
V 27
2010-01-19T04:14:32.049244Z
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
PROPS-END
Node-path: branches/left-sub/wham_eth
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 6
Text-content-md5: 757bcd5818572ef3f9580052617c1c8b
Text-content-sha1: b165019b005c199237ba822c4404e771e93b654a
Content-length: 16
PROPS-END
zowie
Revision-number: 20
Prop-content-length: 117
Content-length: 117
K 7
svn:log
V 19
(r20) left update 5
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:33.049332Z
PROPS-END
Node-path: branches/left/glurpp
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 8
Text-content-md5: 14a169f628e0bb59df9c2160649d0a30
Text-content-sha1: ef7d929e52177767ecfcd28941f6b7f04b4131e3
Content-length: 18
PROPS-END
eee_yow
Revision-number: 21
Prop-content-length: 146
Content-length: 146
K 7
svn:log
V 48
(r21) Cherry-pick left sub-branch commit to left
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:36.041839Z
PROPS-END
Node-path: branches/left
Node-kind: dir
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
Node-action: change
Prop-content-length: 56
Content-length: 56
K 13
svn:mergeinfo
V 21
/branches/left-sub:19
PROPS-END
Node-path: branches/left/wham_eth
Node-kind: file
Node-action: add
Node-copyfrom-rev: 19
Node-copyfrom-path: branches/left-sub/wham_eth
Text-copy-source-md5: 757bcd5818572ef3f9580052617c1c8b
Text-copy-source-sha1: b165019b005c199237ba822c4404e771e93b654a
Revision-number: 22
Prop-content-length: 133
Content-length: 133
K 7
svn:log
V 35
(r22) Merge left sub-branch to left
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:39.045014Z
PROPS-END
Node-path: branches/left
Node-kind: dir
Node-action: change
Prop-content-length: 79
Content-length: 79
K 13
svn:mergeinfo
V 44
/branches/left-sub:4-19
/branches/right:2-17
PROPS-END
Node-path: branches/left/Makefile
Node-kind: file
Node-action: change
Text-content-length: 2713
Text-content-md5: 0afbe34f244cd662b1f97d708c687f90
Text-content-sha1: 46d9377d783e67a9b581da110352e799517c8a14
Content-length: 2713
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
# -DCOLLISION_CHECK if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# enough guarantees about no collisions between objects ever hapenning.
#
# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
# Note that you need some new glibc (at least >2.2.4) for this, and it will
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
CFLAGS=-g -O3 -Wall
CC=gcc
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
check-files ls-tree merge-base merge-cache
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
all: $(PROG)
install: $(PROG)
install $(PROG) $(HOME)/bin/
LIBS= -lssl -lz
init-db: init-db.o
update-cache: update-cache.o read-cache.o
$(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
show-diff: show-diff.o read-cache.o
$(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
write-tree: write-tree.o read-cache.o
$(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
read-tree: read-tree.o read-cache.o
$(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
commit-tree: commit-tree.o read-cache.o
$(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
cat-file: cat-file.o read-cache.o
$(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
fsck-cache: fsck-cache.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
checkout-cache: checkout-cache.o read-cache.o
$(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
diff-tree: diff-tree.o read-cache.o
$(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
rev-tree: rev-tree.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
show-files: show-files.o read-cache.o
$(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
check-files: check-files.o read-cache.o
$(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
ls-tree: ls-tree.o read-cache.o
$(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
merge-base: merge-base.o read-cache.o object.o commit.o tree.o blob.o
$(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
merge-cache: merge-cache.o read-cache.o
$(CC) $(CFLAGS) -o merge-cache merge-cache.o read-cache.o $(LIBS)
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
read-cache.o: cache.h
show-diff.o: cache.h
clean:
rm -f *.o $(PROG)
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
Node-path: branches/left/README
Node-kind: file
Node-action: add
Node-copyfrom-rev: 18
Node-copyfrom-path: branches/left-sub/README
Text-copy-source-md5: fdbcfb6be9afe1121862143f226b51cf
Text-copy-source-sha1: 1d1f5ea4ceb584337ffe59b8980d92e3b78dfef4
Node-path: branches/left/bang
Node-kind: file
Node-action: add
Node-copyfrom-rev: 18
Node-copyfrom-path: branches/left-sub/bang
Text-copy-source-md5: 34c28f1d2dc6a9adeccc4265bf7516cb
Text-copy-source-sha1: 0bc5bb345c0e71d28f784f12e0bd2d384c283062
Node-path: branches/left/urkkk
Node-kind: file
Node-action: add
Node-copyfrom-rev: 18
Node-copyfrom-path: branches/left-sub/urkkk
Text-copy-source-md5: 5889c8392e16251b0c80927607a03036
Text-copy-source-sha1: 3934264d277a0cf886b6b1c7f2b9e56da2525302
Revision-number: 23
Prop-content-length: 125
Content-length: 125
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 7
svn:log
V 27
(r23) Merge left to trunk 2
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 10
svn:author
V 3
adm
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 8
svn:date
V 27
2010-01-19T04:14:42.052798Z
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: change
Prop-content-length: 99
Content-length: 99
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
K 13
svn:mergeinfo
V 64
/branches/left:2-22
/branches/left-sub:4-19
/branches/right:2-17
PROPS-END
Node-path: trunk/README
Node-kind: file
Node-action: add
Node-copyfrom-rev: 22
Node-copyfrom-path: branches/left/README
Text-copy-source-md5: fdbcfb6be9afe1121862143f226b51cf
Text-copy-source-sha1: 1d1f5ea4ceb584337ffe59b8980d92e3b78dfef4
Node-path: trunk/glurpp
Node-kind: file
Node-action: add
Node-copyfrom-rev: 22
Node-copyfrom-path: branches/left/glurpp
Text-copy-source-md5: 14a169f628e0bb59df9c2160649d0a30
Text-copy-source-sha1: ef7d929e52177767ecfcd28941f6b7f04b4131e3
Node-path: trunk/urkkk
Node-kind: file
Node-action: add
Node-copyfrom-rev: 22
Node-copyfrom-path: branches/left/urkkk
Text-copy-source-md5: 5889c8392e16251b0c80927607a03036
Text-copy-source-sha1: 3934264d277a0cf886b6b1c7f2b9e56da2525302
Node-path: trunk/wham_eth
Node-kind: file
Node-action: add
Node-copyfrom-rev: 22
Node-copyfrom-path: branches/left/wham_eth
Text-copy-source-md5: 757bcd5818572ef3f9580052617c1c8b
Text-copy-source-sha1: b165019b005c199237ba822c4404e771e93b654a
Node-path: trunk/zlonk
Node-kind: file
Node-action: add
Node-copyfrom-rev: 22
Node-copyfrom-path: branches/left/zlonk
Text-copy-source-md5: 8b9d8c7c2aaa6167e7d3407a773bbbba
Text-copy-source-sha1: 9716527ebd70a75c27625cacbeb2d897c6e86178
Revision-number: 24
Prop-content-length: 130
Content-length: 130
K 7
svn:log
V 32
(r24) non-merge right to trunk 2
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:44.038434Z
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: change
Prop-content-length: 99
Content-length: 99
K 13
svn:mergeinfo
V 64
/branches/left:2-22
/branches/left-sub:4-19
/branches/right:2-22
git svn: handle SVN merges from revisions past the tip of the branch When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
PROPS-END
Revision-number: 25
Prop-content-length: 135
Content-length: 135
K 7
svn:log
V 37
(r25) add subdirectory to left branch
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:46.052649Z
PROPS-END
Node-path: branches/left/subdir
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Node-path: branches/left/subdir/cowboy
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 7
Text-content-md5: f1d6530278ad409e68cc675476ad995f
Text-content-sha1: 732d9e3e5c391ffd767a98b45ddcc848de778cea
Content-length: 17
PROPS-END
Yeehaw
Revision-number: 26
Prop-content-length: 123
Content-length: 123
K 7
svn:log
V 25
(r26) merge left to trunk
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:49.040783Z
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: change
Prop-content-length: 99
Content-length: 99
K 13
svn:mergeinfo
V 64
/branches/left:2-25
/branches/left-sub:4-19
/branches/right:2-22
PROPS-END
Node-path: trunk/subdir
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 25
Node-copyfrom-path: branches/left/subdir
Revision-number: 27
Prop-content-length: 118
Content-length: 118
K 7
svn:log
V 20
(r28) partial update
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:53.049037Z
PROPS-END
Node-path: branches/partial
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 26
Node-copyfrom-path: trunk/subdir
Node-path: branches/partial/palindromes
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 8
Text-content-md5: 5d1c2024fb5efc4eef812856df1b080c
Text-content-sha1: 5f8509ddd14c91a52864dd1447344e706f9bbc69
Content-length: 18
PROPS-END
racecar
Revision-number: 28
Prop-content-length: 126
Content-length: 126
K 7
svn:log
V 28
(r29) merge partial to trunk
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:14:56.041526Z
PROPS-END
Node-path: trunk/subdir
Node-kind: dir
Node-action: change
Prop-content-length: 142
Content-length: 142
K 13
svn:mergeinfo
V 106
/branches/left/subdir:2-25
/branches/left-sub/subdir:4-19
/branches/partial:27
/branches/right/subdir:2-22
PROPS-END
Node-path: trunk/subdir/palindromes
Node-kind: file
Node-action: add
Node-copyfrom-rev: 27
Node-copyfrom-path: branches/partial/palindromes
Text-copy-source-md5: 5d1c2024fb5efc4eef812856df1b080c
Text-copy-source-sha1: 5f8509ddd14c91a52864dd1447344e706f9bbc69
Revision-number: 29
Prop-content-length: 131
Content-length: 131
K 7
svn:log
V 33
(r31) make bugfix branch from tag
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:15:00.039761Z
PROPS-END
Node-path: tags/v1.0
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 28
Node-copyfrom-path: trunk
Revision-number: 30
Prop-content-length: 120
Content-length: 120
K 7
svn:log
V 22
(r32) commit to bugfix
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:15:03.043218Z
PROPS-END
Node-path: branches/bugfix
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 29
Node-copyfrom-path: tags/v1.0
Node-path: branches/bugfix/subdir/palindromes
Node-kind: file
Node-action: change
Text-content-length: 14
Text-content-md5: 3b12d98578a3f4320ba97e66da54fe5f
Text-content-sha1: 672931c9e8ac2c408209efab2f015638b6d64042
Content-length: 14
racecar
kayak
Revision-number: 31
Prop-content-length: 125
Content-length: 125
K 7
svn:log
V 27
(r33) Merge BUGFIX to TRUNK
K 10
svn:author
V 3
adm
K 8
svn:date
V 27
2010-01-19T04:15:06.043723Z
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: change
Prop-content-length: 133
Content-length: 133
K 13
svn:mergeinfo
V 98
/branches/bugfix:30
/branches/left:2-25
/branches/left-sub:4-19
/branches/right:2-22
/tags/v1.0:29
PROPS-END
Node-path: trunk/subdir
Node-kind: dir
Node-action: change
Prop-content-length: 190
Content-length: 190
K 13
svn:mergeinfo
V 154
/branches/bugfix/subdir:30
/branches/left/subdir:2-25
/branches/left-sub/subdir:4-19
/branches/partial:27
/branches/right/subdir:2-22
/tags/v1.0/subdir:29
PROPS-END
Node-path: trunk/subdir/palindromes
Node-kind: file
Node-action: change
Text-content-length: 14
Text-content-md5: 3b12d98578a3f4320ba97e66da54fe5f
Text-content-sha1: 672931c9e8ac2c408209efab2f015638b6d64042
Content-length: 14
racecar
kayak