On 23 March 2015 at 15:21, Andrew Stitcher <[email protected]> wrote: > 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. >
Its worth noting that everyone might not be onboard with moving to git right now, discussion thus far hasnt really covered that too directly as it was initially seen to be separate from doing a reorg. > 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. I wouldnt go as far as saying I was suggesting it, that was more of a thinking-and-typing-it exercise ;) That way would presumably still be somewhat annoying from a history point of view. It would all be there, but because the first thing we would have to do is move or delete every file in the repo (for everything other than Dispatch) to create the new structure you would always need to 'follow' to actually get at the file history prior to that. > The only > potential issue with this approach is that it will enlarge each repo. Which is a little annoying admittedly. Having a small repo to clone for the client has been really quite nice. That said, I dont really see a way around largish Git repos if they have all history, since we had some very sizable things in there for the older revisions. Thinking further however, in some cases the things havent existed as long as the other bitsin the repo and so having all the history and all the tags for everything would really make no sense for them, particularly where it massively bloats a migrated git 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. > We should be able to do this either way, we could copy some/all of our svn contents and history to play around with locally, or even ask infra to copy it for speed. > 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. > It might be possibly to do something ugly like temporarily copy the tags into place in the [trunk or qpid] tree and treat things as a non standard repo layout (where trunk was treated as the subdir) when migrating. > 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 > Its possibly worth [someone other than me, since I'm meant to be on vacation just now :P] discussing with infra before we proceed with svn changes, to find out what they think in case it should impact any subsequent migrations to Git that were to be made. I'm not sure how the git migration process really works, but its worth remembering the qpid repo contents have been moved before (albeit as a whole) when graduating so the process is presumably able to handle certain rearrangements if not others, since the Qpid GitHub mirror contains the commits prior to that move, whereas the mirror for Dispatch does not contain commits prior to the move to its current structure. That might be related to the qpid parent dir being what moved with existing trunk etc inside it, whereas for dispatch the trunk dir looks to have been created by adding a new directory and then moving the contents from its previous 'not-trunk' dir within the qpid tree. Perhaps it just involves migrating the commits before the move and then those after the move. I'm not really sure. Robbie --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
