On Mon, 2015-03-23 at 11:06 -0400, Andrew Stitcher wrote: > On Tue, 2015-03-17 at 18:45 +0000, Robbie Gemmell wrote: > > I'd love to move everything to Git, but was saving the discussion for > > later, since I figured it probably made sense to reorganise things > > within the current svn repo even if we did transition, resulting in > > area-specific repos afterwards. > > > > That said, I guess you could import the whole existing trunk into each > > new repo and then trim out the things not wanted instead. That might > > actually be a way to get useful tags of the existing content (with all > > the other components still included of course), I'm not actually sure > > how tags would be handled in a transition if we reorganise first. > > Though I'm not sure how we plan to handle them in svn anyway, hadnt > > thought of it until now :) > > I agree with Rajith - It would make good sense to keep the svn repo as > is - note that it is an archive only and create separate git repos for > each of the top level Qpid projects. > > One strong reason (IMO) for not reorganising the existing svn qpid repo > is that it will completely screw up the repo history of anyone (like me) > who is using git-svn to do their qpid development. > > If my repo is going to be screwed up anyway, I see no reason not to just > migrate to a git only solution for each sub-tree.
Have finished the full thread now: I think that Robbie's suggestion of importing the full qpid tree into a each new repo and then trimming and reorganising would be an excellent way to maintain all the previous history of a component. The only potential issue with this approach is that it will enlarge each repo. One real advantage is that it will be possible to script the reorganisations and try them in private repos and test them before committing them to the upstream repo. This should improve the documentation of the reorganisation and it's quality. An alternative might be to rearange inside the current tree (../qpid/trunk/qpid/...) into the current top level location (where it currently exists) and then migrate just that sub tree to git and remove it from svn with a forwarding readme. This is maybe not so good as it won't retain the previous tags. I think it is actually important to think through the mechanics of the reorganisation to ensure that it is "repeatable" and testable before it is actually executaed and this seems to me to be a major advantage of Robbie's suggestion above. Andrew > > Andrew > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
