From: Deskin Miller <hidden> Date: 2016-06-15 22:45:44
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 <redacted>
---
Patch is based on maint.
This was a nasty bug that took some work to figure out; I knew two
git-svn copies had diverged, but though I could look at the commits
where they diverged there was no good way to figure out what git-svn had
been doing at that point. I ended up writing a script to automate the
process and save information for me to analyse later; I'll be posting an
announcement with further explanation, but the repository is available
at
git://git.deskinm.fdns.net/git-svn-bugfix.git
Deskin Miller
git-svn.perl | 14 +++++++++++---
t/t9104-git-svn-follow-parent.sh | 33 +++++++++++++++++++++++++++++++++
2 files changed, 44 insertions(+), 3 deletions(-)
From: Deskin Miller <hidden> Date: 2016-06-15 22:45:44
git-svn has some bugs where it won't create identical commits in
different git-svn copies of the same svn history, despite all relevant
configuration being identical; oftentimes, the copies will diverge from
each other at some point. My theory for a long time was that
interrupting git svn fetch could cause this, and it turns out I was
right in one case, but since it's not something I could easily interrupt
my normal workflow with to do forensics when it occurred, I ended up
writing a script to repeatedly fetch from a certain svn repository, and
compare refs to a supposedly pristine fetch until the refs diverged or
one fetched all the svn history; then, rinse and repeat the process from
the beginning. It's available at
git://git.deskinm.fdns.net/git-svn-bugfix.git
Using this script, r3924 of SVN's svn repository flagged one bug
repeatedly, for which I've posted a patch. I'm posting the repo because
there are other places where history diverges that I've not had a chance
to debug yet, so others should feel free to use the script to find and
fix them. If anyone feels inclined, I'll gladly take patches to the
script, but I don't really care to handle data or bug reports you
generate with it (at least not at this point); I can generate plenty of
data myself.
Deskin Miller
From: Deskin Miller <hidden> Date: 2016-06-15 22:45:44
On Sun, Dec 07, 2008 at 11:06:10AM -0500, Deskin Miller wrote:
[...]
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.
On looking at the patch again, I think I might have introduced a bug:
it'll take the most commit on the parent branch, even if it was branched
from an earlier point. I'll spend more time looking at it and should
have a v2 in a day at most if I'm rigth, hopefully more like a few
hours.
Deskin Miller
From: Deskin Miller <hidden> Date: 2016-06-15 22:45:44
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 <redacted>
---
Fixes the bug I found after sending v1. I squashed in a check for it
into the testcase; if it's preferable I can split it into its own
testcase (this one runs quite long as-is).
Deskin Miller
git-svn.perl | 16 ++++++++++---
t/t9104-git-svn-follow-parent.sh | 43 ++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+), 4 deletions(-)