I think doing the re-org in git might make our lives a bit easy and leave the existing svn repo untouched. As you said, git might make it more easy to handle the tags.
Given the change is quite disruptive, why not make the move into git at the same time. Otherwise developers will have to change their bearing again when we switch to git. I'd say kill two birds with one stone :p On Tue, Mar 17, 2015 at 2:45 PM, Robbie Gemmell <[email protected]> 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 :) > > Robbie > > On 17 March 2015 at 18:13, Rajith Muditha Attapattu <[email protected]> > wrote: > > Could we take this opportunity to move to git completely ? > > (The svn repo will be read only). > > > > We could perhaps then leave whatever we think might not change in the svn > > repo (read-only) and only include items in the git tree that would see > > change going forward. > > > > Rajith > > > > On Tue, Mar 17, 2015 at 1:49 PM, Robbie Gemmell < > [email protected]> > > wrote: > > > >> On 17 March 2015 at 15:45, Alan Conway <[email protected]> wrote: > >> > On Mon, 2015-03-16 at 18:12 +0000, Keith W wrote: > >> >> Hello all, > >> >> > >> >> I believe we reached agreement on the following thread [1] that we > would > >> >> reorganise trunk (to support independent component releases) once the > >> 0.32 > >> >> was branched. > >> >> > >> >> Justin previously published a source tree layout proposal. I have > just > >> >> extended it to include the Java subtree too. > >> >> > >> >> > >> > https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal > >> >> > >> >> As 0.32 is branched (and at the voting stage), is there anything that > >> >> blocks us from beginning the re-org task? Are there comments on the > >> >> proposed layouts? > >> >> > >> >> I am ready to work with other committers to help make sure the > >> transition > >> >> is a smooth one. > >> >> > >> >> cheers, Keith. > >> >> > >> >> > >> >> [1] > >> >> > >> > https://www.mail-archive.com/[email protected]&q=subject:%22Re%3A+Any+ETA+on+a+QPid+0.32+release%22&o=newest > >> > > >> > Looks good but one request: can we please call the sub-directories > >> > proton, dispatch, cpp, jms ... > >> > NOT > >> > qpid-proton, qpid-dispatch, qpid-cpp... > >> > > >> > The repo is already called qpid, it has a (redundant) top level > >> > directory called qpid, lets not make everybody type qpid/qpid/qpid- > >> > first thing every morning. > >> > > >> > Cheers, > >> > Alan. > >> > > >> > >> Agreed. I think theyd only want to have qpid- if they were in git, > >> like qpid-proton and qpid-jms. > >> > >> The existing second qpid dir will go away with these changes either > >> way though since it is within the trunk dir currently, and these > >> proposed new dirs would contain the trunk etc. > >> > >> Robbie > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
