Hi Paul et al., Am 20.07.2012 um 01:09 schrieb Paul Hoadley:
> I've found that git-svn-clone does a pretty reasonable job of converting the > Subversion conventions for branches/tags into their Git counterparts. > Combined with git-filter-branch, you should be able to extract individual > projects from your existing repo into their own Git repos. Further, unless > you have currently active branches, you could just forget about _converting_ > them altogether (in which case they would end up in a folder called > 'branches'), or simply ignore them. It depends how particular you are about > preserving history. (I used to think I was very particular about preserving > history. It's amazing how _actually trying to do it_ can relax your outlook.) > >> Good thing is, I can clone and look at it at will locally, so I'm now >> experimenting with different layouts. The most probably outcome so far looks >> like one repo for the app and the app-specific frameworks, and separate >> repos for each generic framework. But I have no idea yet how to manage the >> dependencies between those. > > That's pretty much what I decided on. I've made the move with a couple of > applications, one of which has four Eclipse projects in it as mentioned > above—that's about as big as I would like to get. What are the dependency > issues you're worried about? > > This is a topic I am very interested in—keep us up to date with how you go, > Maik. I've finished converting fow now. What I finally decided on is: 1) one git repo for the main app and all frameworks that are specific to that app 2) leave all generic frameworks in subversion for the time being. Decision 2 is based on the fact that changes in those frameworks are both low-traffic and mostly independent of the individual projects using them. We already took care to make only changes that don't break existing APIs there, and had to communicate and do some decisionmaking anyway when that wasn't possible. Plus, I have an easy point to stop putting time into the conversion and postpone the rest for later when I've accumulated more experience with git. So, the conversion was as follows: git clone --preserve-empty-dirs --username=maik svn://path.to.host/ParentFolder/ProjectFolderContainingAppAndRelatedFrameworks Then deleted all frameworks within the converted folder that had trunk/tags/branches structures in them, and made separate clones of them in another directory using the -s option. Then added these as new remotes to the main clone: cd $mainRepo git remote add -f Framework1 /path/to/Framework1 git merge -s ours --no-commit Framework1/master git read-tree --prefix=Framework1/ -u Framework1/master git commit -m "merge Framework1 into main" Main helping reference for this was: http://nuclearsquid.com/writings/subtree-merging-and-you/ Subsequent commits to svn showed up in the svn remote that resulted from the conversion automatically. When I wanted to start merging new git-local branches however, SourceTree warned about that being actions that could not be synced any more with the svn remote. Since I didn't want to be restrained by svn in the future anyway, I decided to cut the connection to svn at that point, doing: git branch -r -d git-svn git config --remove-section svn-remote.svn rm -rf .git/svn and added a final commit to svn, commenting that it's an abandoned repo now. All that resulted in working local git repos. I then installed gitolite on the same OS X server running subversion, created a repo there, added that as remote and pushed everything there. Works fine. The one feature that we don't have for now is pull requests. Gitlab failed to install on OS X, and I'll probably use a Linux box for that later on. Using github is out of the question because we can't and won't host customer-related source code anywhere outside our control. And a final remark: branching and merging with new features and other changes since the conversion has been an amazing experience so far. I should have done that a long time ago. This is so much better than stinkin' subversion... Maik _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
