Its not true that the entire cvs repository is tagged when a release is done. There are numerous cvs module aliases encompassing different release components. In a large aggregation of components such occurs in jbossas, the jbossas cvs module alias is tagged, and many components come in as binaries based on the version referenced in the jbossas thirdparty build declarations. That behavior mirrors the maven behavior. There is no clean mapping from the version reference to the cvs/svn source tree that that corresponds to the binary. This is due to different version conventions, and repositories. The version convention has been unified and now we need a unified svn convention.
This really is consistent with putting the types of branches under the project root url. How this works with tools is whay I wanted to see how one performs various tasks on a project from the command line and ide svn tools. We don't have a usecase for obtaining all trunks, qa, etc. so it would be a question for Damon as to why he suggested this convention. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim OBrien Sent: Sunday, February 12, 2006 11:57 AM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff I read the SVN branching doc on the wiki, and here is some feedback. Instead of putting branches tags directories at the repository level where "/prod", "/qa", and "/trunk" encompass everything in the SVn repository. Create "trunk", "tags", and "branches" at the subproject level. Version each subproject in a /projects subdirectory and aggregate projects using svn:externals. It's convenient to keep all of the tags and branches of a specific component in a consolidated directory as I'm almost certain that there are SVN tools in development which will expect the familiar trunk, tags, branches convention. Thinking of a branch or a tag as something that happens to an entire repository is in keeping with the way JBoss performs releases in CVS. From what I heard last year, when JBoss cuts a release or tags, someone has to tag (or branch tag) the entire JBoss CVS repository. The drawback to repository-wide branching and tagging is that it prevents different subcomponents from releasing at different rates. Hibernate, jboss-mail, jboss-media, jboss-aop...all of these components may have different release rates. From the wiki document, it looks like every project that follows the three-tiered release model would have a directory in /trunk, /qa, and /prod. I'm assuming that the idea of putting /trunk, /qa, and /prod is one of convenience? This way someone only has to check out /trunk to get all trunks? If that's the motivation, then you could handle this case by using svn:externals and preserve the convention of "trunk", "tags", and "branches". Put trunk, "tags", and "branches" at the second level (keep the names as certian toolsets will start relying on this convention). Resources on trunks, tags, branches: "Subversion Book" - http://svnbook.red-bean.com/en/1.1/ch05s04.html "How Fisheye works with Trunks, Tags, Branches" - http://www.cenqua.com/fisheye/doc/1.1/admin/svnsymbolic.html Note: I'd suggest either the second-level approach or a custom layout. Other projects have had similar discussions: http://lists.gnu.org/archive/html/gnustep-dev/2005-10/msg00057.html http://pkg-perl.alioth.debian.org/subversion.html ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
