2009-10-20 04:42:02 +02:00
|
|
|
SVN-fs-dump-format-version: 2
|
|
|
|
|
|
2009-12-19 17:20:30 +01:00
|
|
|
UUID: 64142547-0943-4db2-836a-d1e1eb2f9924
|
2009-10-20 04:42:02 +02:00
|
|
|
|
|
|
|
|
Revision-number: 0
|
|
|
|
|
Prop-content-length: 56
|
|
|
|
|
Content-length: 56
|
|
|
|
|
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:17:51.232640Z
|
2009-10-20 04:42:02 +02:00
|
|
|
PROPS-END
|
|
|
|
|
|
|
|
|
|
Revision-number: 1
|
2009-12-19 17:20:30 +01:00
|
|
|
Prop-content-length: 128
|
|
|
|
|
Content-length: 128
|
2009-10-20 04:42:02 +02:00
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
2009-12-19 17:20:30 +01:00
|
|
|
V 29
|
|
|
|
|
(r1) Setup trunk and branches
|
2009-10-20 04:42:02 +02:00
|
|
|
K 10
|
|
|
|
|
svn:author
|
2009-12-19 17:20:30 +01:00
|
|
|
V 4
|
|
|
|
|
samv
|
2009-10-20 04:42:02 +02:00
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:17:51.831965Z
|
2009-10-20 04:42:02 +02:00
|
|
|
PROPS-END
|
|
|
|
|
|
|
|
|
|
Node-path: branches
|
|
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
Prop-content-length: 112
|
|
|
|
|
Content-length: 112
|
2009-10-20 04:42:02 +02:00
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
2009-12-19 17:20:30 +01:00
|
|
|
V 13
|
|
|
|
|
(r2) ancestor
|
2009-10-20 04:42:02 +02:00
|
|
|
K 10
|
|
|
|
|
svn:author
|
2009-12-19 17:20:30 +01:00
|
|
|
V 4
|
|
|
|
|
samv
|
2009-10-20 04:42:02 +02:00
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:17:52.300075Z
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
Prop-content-length: 120
|
|
|
|
|
Content-length: 120
|
2009-10-20 04:42:02 +02:00
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
2009-12-19 17:20:30 +01:00
|
|
|
V 21
|
|
|
|
|
(r3) make left branch
|
2009-10-20 04:42:02 +02:00
|
|
|
K 10
|
|
|
|
|
svn:author
|
2009-12-19 17:20:30 +01:00
|
|
|
V 4
|
|
|
|
|
samv
|
2009-10-20 04:42:02 +02:00
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:17:52.768800Z
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
Prop-content-length: 121
|
|
|
|
|
Content-length: 121
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
V 4
|
|
|
|
|
samv
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:17:53.177879Z
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
|
|
|
|
|
2009-10-20 04:42:02 +02:00
|
|
|
|
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
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-10-20 04:42:02 +02:00
|
|
|
|
|
|
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
Prop-content-length: 117
|
|
|
|
|
Content-length: 117
|
2009-10-20 04:42:02 +02:00
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
2009-12-19 17:20:30 +01:00
|
|
|
V 18
|
|
|
|
|
(r5) left update 1
|
2009-10-20 04:42:02 +02:00
|
|
|
K 10
|
|
|
|
|
svn:author
|
2009-12-19 17:20:30 +01:00
|
|
|
V 4
|
|
|
|
|
samv
|
2009-10-20 04:42:02 +02:00
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:17:53.604691Z
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
Prop-content-length: 118
|
|
|
|
|
Content-length: 118
|
2009-10-20 04:42:02 +02:00
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
2009-12-19 17:20:30 +01:00
|
|
|
V 19
|
|
|
|
|
(r6) right update 1
|
2009-10-20 04:42:02 +02:00
|
|
|
K 10
|
|
|
|
|
svn:author
|
2009-12-19 17:20:30 +01:00
|
|
|
V 4
|
|
|
|
|
samv
|
2009-10-20 04:42:02 +02:00
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:17:54.063555Z
|
2009-10-20 04:42:02 +02:00
|
|
|
PROPS-END
|
|
|
|
|
|
2009-12-19 17:20:30 +01:00
|
|
|
Node-path: branches/right/Makefile
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
Prop-content-length: 117
|
|
|
|
|
Content-length: 117
|
2009-10-20 04:42:02 +02:00
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
2009-12-19 17:20:30 +01:00
|
|
|
V 18
|
|
|
|
|
(r7) left update 2
|
2009-10-20 04:42:02 +02:00
|
|
|
K 10
|
|
|
|
|
svn:author
|
2009-12-19 17:20:30 +01:00
|
|
|
V 4
|
|
|
|
|
samv
|
2009-10-20 04:42:02 +02:00
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:17:54.523904Z
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
Prop-content-length: 117
|
|
|
|
|
Content-length: 117
|
2009-10-20 04:42:02 +02:00
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
2009-12-19 17:20:30 +01:00
|
|
|
V 18
|
|
|
|
|
(r8) left update 3
|
2009-10-20 04:42:02 +02:00
|
|
|
K 10
|
|
|
|
|
svn:author
|
2009-12-19 17:20:30 +01:00
|
|
|
V 4
|
|
|
|
|
samv
|
2009-10-20 04:42:02 +02:00
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:17:54.975970Z
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
Prop-content-length: 124
|
|
|
|
|
Content-length: 124
|
2009-10-20 04:42:02 +02:00
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
2009-12-19 17:20:30 +01:00
|
|
|
V 25
|
|
|
|
|
(r9) make left sub-branch
|
|
|
|
|
K 10
|
|
|
|
|
svn:author
|
|
|
|
|
V 4
|
|
|
|
|
samv
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
|
|
|
|
2009-12-19T16:17:55.459904Z
|
|
|
|
|
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: 129
|
|
|
|
|
Content-length: 129
|
|
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
|
|
|
|
V 30
|
|
|
|
|
(r10) left sub-branch update 1
|
2009-10-20 04:42:02 +02:00
|
|
|
K 10
|
|
|
|
|
svn:author
|
2009-12-19 17:20:30 +01:00
|
|
|
V 4
|
|
|
|
|
samv
|
2009-10-20 04:42:02 +02:00
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:17:55.862113Z
|
|
|
|
|
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: 126
|
|
|
|
|
Content-length: 126
|
|
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
|
|
|
|
V 27
|
|
|
|
|
(r11) Merge left to trunk 1
|
|
|
|
|
K 10
|
|
|
|
|
svn:author
|
|
|
|
|
V 4
|
|
|
|
|
samv
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
|
|
|
|
2009-12-19T16:17:56.413416Z
|
2009-10-20 04:42:02 +02:00
|
|
|
PROPS-END
|
|
|
|
|
|
|
|
|
|
Node-path: trunk
|
|
|
|
|
Node-kind: dir
|
|
|
|
|
Node-action: change
|
2009-12-19 17:20:30 +01:00
|
|
|
Prop-content-length: 54
|
|
|
|
|
Content-length: 54
|
2009-10-20 04:42:02 +02:00
|
|
|
|
|
|
|
|
K 13
|
|
|
|
|
svn:mergeinfo
|
2009-12-19 17:20:30 +01:00
|
|
|
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: 118
|
|
|
|
|
Content-length: 118
|
|
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
|
|
|
|
V 19
|
|
|
|
|
(r12) left update 4
|
|
|
|
|
K 10
|
|
|
|
|
svn:author
|
|
|
|
|
V 4
|
|
|
|
|
samv
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
|
|
|
|
2009-12-19T16:17:56.831014Z
|
|
|
|
|
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: 119
|
|
|
|
|
Content-length: 119
|
|
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
|
|
|
|
V 20
|
|
|
|
|
(r13) right update 2
|
|
|
|
|
K 10
|
|
|
|
|
svn:author
|
|
|
|
|
V 4
|
|
|
|
|
samv
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
|
|
|
|
2009-12-19T16:17:57.341143Z
|
|
|
|
|
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: 141
|
|
|
|
|
Content-length: 141
|
|
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
|
|
|
|
V 42
|
|
|
|
|
(r14) Cherry-pick right 2 commits to trunk
|
|
|
|
|
K 10
|
|
|
|
|
svn:author
|
|
|
|
|
V 4
|
|
|
|
|
samv
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
|
|
|
|
2009-12-19T16:17:57.841851Z
|
|
|
|
|
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
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
2009-10-20 04:42:02 +02:00
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
2009-12-19 17:20:30 +01:00
|
|
|
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: 127
|
|
|
|
|
Content-length: 127
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
V 4
|
|
|
|
|
samv
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:17:58.368520Z
|
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
|
|
|
|
|
|
2009-12-19 17:20:30 +01:00
|
|
|
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: 119
|
|
|
|
|
Content-length: 119
|
|
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
|
|
|
|
V 20
|
|
|
|
|
(r16) right update 3
|
|
|
|
|
K 10
|
|
|
|
|
svn:author
|
|
|
|
|
V 4
|
|
|
|
|
samv
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
|
|
|
|
2009-12-19T16:17:58.779056Z
|
|
|
|
|
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: 119
|
|
|
|
|
Content-length: 119
|
|
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
|
|
|
|
V 20
|
|
|
|
|
(r17) trunk update 1
|
|
|
|
|
K 10
|
|
|
|
|
svn:author
|
|
|
|
|
V 4
|
|
|
|
|
samv
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
|
|
|
|
2009-12-19T16:17:59.221851Z
|
|
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
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: 135
|
|
|
|
|
Content-length: 135
|
|
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
|
|
|
|
V 36
|
|
|
|
|
(r18) Merge right to left sub-branch
|
|
|
|
|
K 10
|
|
|
|
|
svn:author
|
|
|
|
|
V 4
|
|
|
|
|
samv
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
|
|
|
|
2009-12-19T16:17:59.781666Z
|
|
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
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 \
|
2009-12-19 17:20:30 +01:00
|
|
|
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)
|
|
|
|
|
|
2009-12-19 17:20:30 +01:00
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
2009-12-19 17:20:30 +01:00
|
|
|
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: 129
|
|
|
|
|
Content-length: 129
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
V 4
|
|
|
|
|
samv
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:18:00.200531Z
|
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
|
|
|
|
|
|
2009-12-19 17:20:30 +01:00
|
|
|
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: 118
|
|
|
|
|
Content-length: 118
|
|
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
|
|
|
|
V 19
|
|
|
|
|
(r20) left update 5
|
|
|
|
|
K 10
|
|
|
|
|
svn:author
|
|
|
|
|
V 4
|
|
|
|
|
samv
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
|
|
|
|
2009-12-19T16:18:00.659636Z
|
|
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
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: 147
|
|
|
|
|
Content-length: 147
|
|
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
|
|
|
|
V 48
|
|
|
|
|
(r21) Cherry-pick left sub-branch commit to left
|
|
|
|
|
K 10
|
|
|
|
|
svn:author
|
|
|
|
|
V 4
|
|
|
|
|
samv
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
|
|
|
|
2009-12-19T16:18:01.194402Z
|
|
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
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: 134
|
|
|
|
|
Content-length: 134
|
|
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
|
|
|
|
V 35
|
|
|
|
|
(r22) Merge left sub-branch to left
|
|
|
|
|
K 10
|
|
|
|
|
svn:author
|
|
|
|
|
V 4
|
|
|
|
|
samv
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
|
|
|
|
2009-12-19T16:18:01.679218Z
|
|
|
|
|
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 \
|
2009-12-19 17:20:30 +01:00
|
|
|
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)
|
|
|
|
|
|
2009-12-19 17:20:30 +01:00
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
2009-12-19 17:20:30 +01:00
|
|
|
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: 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
|
2009-12-19 17:20:30 +01:00
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
V 4
|
|
|
|
|
samv
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
2009-12-19T16:18:02.212349Z
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
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
|
2009-12-19 17:20:30 +01:00
|
|
|
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: 131
|
|
|
|
|
Content-length: 131
|
|
|
|
|
|
|
|
|
|
K 7
|
|
|
|
|
svn:log
|
|
|
|
|
V 32
|
|
|
|
|
(r24) non-merge right to trunk 2
|
|
|
|
|
K 10
|
|
|
|
|
svn:author
|
|
|
|
|
V 4
|
|
|
|
|
samv
|
|
|
|
|
K 8
|
|
|
|
|
svn:date
|
|
|
|
|
V 27
|
|
|
|
|
2009-12-19T16:18:02.672148Z
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|