I'm going to go ahead and reset the boinc-v2 repo back to the baseline (SVN migration).
Go ahead and update it as you get further along in the migration process. Are you going to handle the migration of the other branches we are currently maintaining/tracking? (wxWidgets30, 7.0a, 7.0b) ----- Rom -----Original Message----- From: Oliver Bock [mailto:[email protected]] Sent: Monday, March 04, 2013 8:40 AM To: Rom Walton Cc: David Anderson (BOINC); BOINC Developers Mailing List Subject: Re: BOINC-v2 Git Repo Updated Hi Rom, On 2/25/13 18:14 , Rom Walton wrote: > 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. On 3/1/13 17:20 , Oliver Bock wrote: > Also, the way you generated the patches (straight git format-patch) > linearized the history and changed the order of several commits (a > known effect). In contrast, I replayed the original history as close > as possible which makes it easier to do v1/v2 cross-checks > > Comparing your v2 with my v2 I also found a number of white-space > changes, presumably introduced while you edited/recreated the patches > manually, something I usually didn't have to do. I only used > combinations of format-patch/am and cherry-pick with v1 SHA1s, no need > to construct new patches. At some point (rather sooner than later) we should decide how we're going to continue in order to avoid doubling the effort. In my migration attempt so far I didn't have to manually edit any patches for the reasons you described, naturally avoiding any accidental changes of content (incl. whitespaces). My approach also doesn't linearize/flatten history or change the order of things. Since we, E@H, really do care about BOINC's code base and history I could offer to continue my effort until our repo is in sync with upstream. Thoughts? Best, 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.
