> > > 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. > > IMO there should NEVER be qpid- prefixes on anything in the qpid repo, > regardless of whether we get rid of the useless top-level qpid directory > or whether we it all to git > > Anybody who checks out the qpid repo *knows* they have checked out the > qpid repo, there's no need to embed a reminder in every directory name > in the repo that yes, this is indeed a checkout of the qpid repo.
As far as subversion goes, the proposal doesn't include any extra qpids. It's all https://svn.apache.org/repos/asf/qpid/$module/{trunk,branches,tags} where module is cpp, java, dispatch, etc. I think Robbie's right about including qpid in the git repo name. That helps to clarify what you're getting, particularly for components with generic names such as jms. When it comes to git, there is no "the qpid repo" (as in, "anyone who checks out the qpid repo"). Since each module is a top-level entity, I think they need the association.
