From 553589f7823db530d03b49db42251fbea624041f Mon Sep 17 00:00:00 2001 From: Deskin Miller Date: Mon, 8 Dec 2008 08:31:31 -0500 Subject: git-svn: Make following parents atomic find_parent_branch generates branch@rev type branches when one has to look back through SVN history to properly get the history for a branch copied from somewhere not already being tracked by git-svn. If in the process of fetching this history, git-svn is interrupted, then when one fetches again, it will use whatever was last fetched as the parent commit and fail to fetch any more history which it didn't get to before being terminated. This is especially troubling in that different git-svn copies of the same SVN repository can end up with different commit sha1s, incorrectly showing the history as divergent and precluding easy collaboration using git push and fetch. To fix this, when we initialise the Git::SVN object $gs to search for and perhaps fetch history, we check if there are any commits in SVN in the range between the current revision $gs is at, and the top revision for which we were asked to fill history. If there are commits we're missing in that range, we continue the fetch from the current revision to the top, properly getting all history before using it as the parent for the branch we're trying to create. Signed-off-by: Deskin Miller Acked-by: Eric Wong Signed-off-by: Junio C Hamano --- git-svn.perl | 16 +++++++++++---- t/t9104-git-svn-follow-parent.sh | 42 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+), 4 deletions(-) diff --git a/git-svn.perl b/git-svn.perl index 56238dad08..25ed2f4333 100755 --- a/git-svn.perl +++ b/git-svn.perl @@ -2318,12 +2318,20 @@ sub find_parent_branch { $gs = Git::SVN->init($u, $p, $repo_id, $ref_id, 1); } my ($r0, $parent) = $gs->find_rev_before($r, 1); - if (!defined $r0 || !defined $parent) { - my ($base, $head) = parse_revision_argument(0, $r); - if ($base <= $r) { + { + my ($base, $head); + if (!defined $r0 || !defined $parent) { + ($base, $head) = parse_revision_argument(0, $r); + } else { + if ($r0 < $r) { + $gs->ra->get_log([$gs->{path}], $r0 + 1, $r, 1, + 0, 1, sub { $base = $_[1] - 1 }); + } + } + if (defined $base && $base <= $r) { $gs->fetch($base, $r); } - ($r0, $parent) = $gs->last_rev_commit; + ($r0, $parent) = $gs->find_rev_before($r, 1); } if (defined $r0 && defined $parent) { print STDERR "Found branch parent: ($self->{ref_id}) $parent\n"; diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh index 4d964e2db7..d80ea64e49 100755 --- a/t/t9104-git-svn-follow-parent.sh +++ b/t/t9104-git-svn-follow-parent.sh @@ -149,6 +149,48 @@ test_expect_success "track initial change if it was only made to parent" ' "`git rev-parse r9270-d~1`" ' +test_expect_success "follow-parent is atomic" ' + ( + cd wc && + svn up && + svn mkdir stunk && + echo "trunk stunk" > stunk/readme && + svn add stunk/readme && + svn ci -m "trunk stunk" && + echo "stunk like junk" >> stunk/readme && + svn ci -m "really stunk" && + echo "stink stank stunk" >> stunk/readme && + svn ci -m "even the grinch agrees" + ) && + svn copy -m "stunk flunked" "$svnrepo"/stunk "$svnrepo"/flunk && + { svn cp -m "early stunk flunked too" \ + "$svnrepo"/stunk@17 "$svnrepo"/flunked || + svn cp -m "early stunk flunked too" \ + -r17 "$svnrepo"/stunk "$svnrepo"/flunked; } && + git svn init --minimize-url -i stunk "$svnrepo"/stunk && + git svn fetch -i stunk && + git update-ref refs/remotes/flunk@18 refs/remotes/stunk~2 && + git update-ref -d refs/remotes/stunk && + git config --unset svn-remote.svn.fetch stunk && + mkdir -p "$GIT_DIR"/svn/flunk@18 && + rev_map=$(cd "$GIT_DIR"/svn/stunk && ls .rev_map*) && + dd if="$GIT_DIR"/svn/stunk/$rev_map \ + of="$GIT_DIR"/svn/flunk@18/$rev_map bs=24 count=1 && + rm -rf "$GIT_DIR"/svn/stunk && + git svn init --minimize-url -i flunk "$svnrepo"/flunk && + git svn fetch -i flunk && + git svn init --minimize-url -i stunk "$svnrepo"/stunk && + git svn fetch -i stunk && + git svn init --minimize-url -i flunked "$svnrepo"/flunked && + git svn fetch -i flunked + test "`git rev-parse --verify refs/remotes/flunk@18`" \ + = "`git rev-parse --verify refs/remotes/stunk`" && + test "`git rev-parse --verify refs/remotes/flunk~1`" \ + = "`git rev-parse --verify refs/remotes/stunk`" && + test "`git rev-parse --verify refs/remotes/flunked~1`" \ + = "`git rev-parse --verify refs/remotes/stunk~1`" + ' + test_expect_success "track multi-parent paths" ' svn cp -m "resurrect /glob" "$svnrepo"/r9270 "$svnrepo"/glob && git-svn multi-fetch && -- cgit v1.2.1 From aa971cb9bf4105eefb435b9e6f282f019529c35f Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Sun, 7 Dec 2008 18:38:46 -0800 Subject: work around Python warnings from AsciiDoc It appears that a reference to an anchor defined as [[anchor-name]] from another place using <> syntax, when the anchor name contains a string "-with-" in its name, triggers these warnings from Python interpreter. asciidoc -b docbook -d book user-manual.txt :1: Warning: 'with' will become a reserved keyword in Python 2.6 :1: Warning: 'with' will become a reserved keyword in Python 2.6 :1: Warning: 'with' will become a reserved keyword in Python 2.6 :1: Warning: 'with' will become a reserved keyword in Python 2.6 There currently is no reference to "Finding comments with given content", but for consistency and for futureproofing, the anchor is also updated as the other ones that are actually used and trigger these warnings. Signed-off-by: Junio C Hamano Signed-off-by: Junio C Hamano --- Documentation/user-manual.txt | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index b6533fa206..99cb80878b 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -13,7 +13,7 @@ to build and test a particular version of a software project, search for regressions, and so on. People needing to do actual development will also want to read -<> and <>. +<> and <>. Further chapters cover more specialized topics. @@ -389,7 +389,7 @@ the order it uses to decide which to choose when there are multiple references with the same shorthand name, see the "SPECIFYING REVISIONS" section of linkgit:git-rev-parse[1]. -[[Updating-a-repository-with-git-fetch]] +[[Updating-a-repository-With-git-fetch]] Updating a repository with git-fetch ------------------------------------ @@ -945,7 +945,7 @@ echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new" and then he just cut-and-pastes the output commands after verifying that they look OK. -[[Finding-comments-with-given-content]] +[[Finding-comments-With-given-Content]] Finding commits referencing a file with given content ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -962,7 +962,7 @@ Figuring out why this works is left as an exercise to the (advanced) student. The linkgit:git-log[1], linkgit:git-diff-tree[1], and linkgit:git-hash-object[1] man pages may prove helpful. -[[Developing-with-git]] +[[Developing-With-git]] Developing with git =================== @@ -1665,7 +1665,7 @@ dangling objects can arise in other situations. Sharing development with others =============================== -[[getting-updates-with-git-pull]] +[[getting-updates-With-git-pull]] Getting updates with git-pull ----------------------------- @@ -1673,7 +1673,7 @@ After you clone a repository and make a few changes of your own, you may wish to check the original repository for updates and merge them into your own work. -We have already seen <> with linkgit:git-fetch[1], and how to merge two branches. So you can merge in changes from the original repository's master branch with: @@ -1784,7 +1784,7 @@ Public git repositories Another way to submit changes to a project is to tell the maintainer of that project to pull the changes from your repository using -linkgit:git-pull[1]. In the section "<>" we described this as a way to get updates from the "main" repository, but it works just as well in the other direction. @@ -1994,7 +1994,7 @@ $ git push ssh://yourserver.com/~you/proj.git +master Normally whenever a branch head in a public repository is modified, it is modified to point to a descendant of the commit that it pointed to before. By forcing a push in this situation, you break that convention. -(See <>.) +(See <>.) Nevertheless, this is a common practice for people that need a simple way to publish a work-in-progress patch series, and it is an acceptable @@ -2563,7 +2563,7 @@ There are numerous other tools, such as StGIT, which exist for the purpose of maintaining a patch series. These are outside of the scope of this manual. -[[problems-with-rewriting-history]] +[[problems-With-rewriting-history]] Problems with rewriting history ------------------------------- -- cgit v1.2.1