Wouldn't the SHA-1 values of all the SVN commits be different between v1
and v2 because of the missing files?

Remember the commit you pointed us to where a previously missing file
was first modified, after SVN #12399.  From svn2git's perspective, the
file didn't exist in Git so svn2git spontaneously brought the whole file
into existence.  So what should have been just a one or two line diff,
became a whole file inclusion.  That would change the SHA-1 value for
that commit.

Now we come to the extraction of patch sets from v1, the patches
reference SHA-1 values that exist in the botched SVN migration.  So
git-am would complain about missing SHA-1 values and abort.  In order to
fix that situation I created a new branch, manually applied the patch,
extracted the patch, copy the patch header from the old patch file to
the new patch file, rename new patch file to the old patch file,
checkout master and apply modified patch.

It turns out line feed issues from the svn2git migration were my biggest
nemesis.  

Since any subsequent commit depends on the SHA-1 value of the previous
version of said file I would expect every file changed post-SVN
migration to be considered different from gits perspective.  I'm not
sure git would be a good tool to use to check differences on files as it
would tend to take shortcuts based on that it stores in the object
database. You'll probably need to use a diffing tool that will look at
the contents of a file.

I've uploaded the patch sets I applied post-svn conversion:
http://boinc.berkeley.edu/dl2/boincgitpatches.zip

patches contains all the patches I applied post SVN migration and brings
the tree up to 12/14/2012.

patches-2 picks up from 12/14/2012 and goes until I hit a bump in the
road with a reverse integration (7.0b -> master) with the WCG project
files.  Git wouldn't take the patch without a bunch of extra line feed
conversions.

patches-3 after fiddling with things for an hour or so I let it win and
committed the extra line feed conversions too.

patches-4 picks up after the WCG project file changes and brings master
and the rest of the branches to current.

With 7.0b we started fresh with what was in master.  Until a commit is
committed that shouldn't be part of the 7.0.x release, everything is
updated from master before a release.  I created the 7.0b branch and did
the merges at the same points in the git log as they existed in
boinc-v1.  I only applied the tag/version change commits after the
merge.  I created the tag after that.  I uploaded the new branch in
boinc-v2 after everything was finished.

I suspect the differences in the way things look is probably because
there wasn't a remote origin branch at the time I was bringing the 7.0b
branch up-to-date.

----- Rom


-----Original Message-----
From: Oliver Bock [mailto:[email protected]] 
Sent: Monday, February 25, 2013 11:03 AM
To: Rom Walton
Cc: David Anderson (BOINC)
Subject: Re: BOINC-v2 Git Repo Updated

On 2/25/13 5:29 , Rom Walton wrote:
> I've uploaded all the updates for master, 7.0a, and 7.0b.
> 
> I'll begin the validation process in the morning.

Some first checks for branch equivalency, in terms of tracked content:
(I'd expect all of the following checks to return no differences)

----------------------------------------------------------------

Last SVN revision (26153) in our old tracking repo vs. boinc-v2:
a)
> https://git.aei.uni-hannover.de/cgi-bin/gitweb.cgi?p=tracking/boinc/tr
> unk.git;a=summary
b)
> http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=summary

Test:
git diff --shortstat c40dafd 4df017d

Result:
No differences!

:-)

----------------------------------------------------------------

Earliest fixed tree commit in boinc vs boinc-v2:

a)
> http://boinc.berkeley.edu/gitweb/?p=boinc.git;a=summary
b)
> http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=summary

Test(s):
git diff --shortstat 1365018 9fdfff6
git diff --shortstat ccad5d0 865e9b3

Result(s):
121 files changed, 4443 insertions(+), 35 deletions(-)
122 files changed, 4272 insertions(+), 73 deletions(-)

:-(

----------------------------------------------------------------

Latest common master in boinc vs. boinc-v2:

a)
> http://boinc.berkeley.edu/gitweb/?p=boinc.git;a=summary
b)
> http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=summary

Test:
git diff --shortstat 2a0bf8a b5c336e

Result:
275 files changed, 57176 insertions(+), 53413 deletions(-)

:-(

----------------------------------------------------------------

Latest common 7.0a in boinc vs. boinc-v2:

a)
> http://boinc.berkeley.edu/gitweb/?p=boinc.git;a=shortlog;h=refs/heads/
> client_release_7.0a
b)
> http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=shortlog;h=refs/hea
> ds/client_release/7/7.0a

Test:
git diff --shortstat 60f0ce6 86b58bd

Result:
123 files changed, 4545 insertions(+), 37 deletions(-)

:-(

----------------------------------------------------------------

Latest common 7.0b in boinc vs. boinc-v2:

a)
> http://boinc.berkeley.edu/gitweb/?p=boinc.git;a=shortlog;h=refs/heads/
> client_release_7.0b
b)
> http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=shortlog;h=refs/hea
> ds/client_release/7/7.0b

Test:
git diff --shortstat 642bbb2 9ffb000

Result:
275 files changed, 57178 insertions(+), 53415 deletions(-)

:-(

----------------------------------------------------------------

Looking into the boinc-v2 differences/issues above:
> http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=shortlog;pg=5

You should make sure you use the author date as commit date or there
will be questions why there's seemingly a cut in the timeline (as of
v2-commit 33b2ee8).

----------------------------------------------------------------

What's going on with 7.0b?
> http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=shortlog;h=refs/hea
> ds/client_release/7/7.0b

What are those "merge commits"?
Why are the tags 7.0.45 to 7.0.53 completely out of place?

----------------------------------------------------------------

Preliminary conclusion:

The automatic svn2git migration of master seems fine to me. It's hard to
tell what's wrong with everything that follows because we don't have a
trusted base for comparison. It could be that a) boinc.git never reached
a state where all the missing commits got fully fixed, which means it
can't be used for the checks above Or b), if it got fixed, the checks
above show that your patch set produces a significantly different state
compared to what's in boinc.git and thus needs fixing.

I need to look into the details more closely. Is there anything you can
tell me about the actual migration your did? Any errors, warnings,
problems?


Cheers,
Oliver

_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to