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]
