On 17 March 2015 at 20:03, Rajith Muditha Attapattu <[email protected]> wrote: > I think doing the re-org in git might make our lives a bit easy and leave > the existing svn repo untouched.
So, I don't have a strong view on git, but I don't think leaving the svn repo untouched is actually a good goal to have. If we move to git I think we'd want to do something to make clear that the svn repo is no longer in use (except maybe for bug fix releases of old versions... would we even be able to do this?) as per Robbie's other thread on a similar issue. My question with git is how easy it would then be to the subsequently change / split the projects up. This is very much a first step, and I wouldn't want the "java" project to last very long. Ideally we'd be breaking that up into sensible components like "broker", "0-x client" etc. within a reasonably short timeframe (i.e. hopefully before the end of the year). Personally I'd think we'd want to wait until we'd worked out the final project structure before we engaged with infra to get git projects set up etc... but if it's all a no-op for infra and they'll be happy with us asking for projects to be set up / split / removed every couple of months until we're done, then I have no issue... -- Rob > 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
