Re: [seam-dev] Seam patches and SVN logistics

Hi guys, Isn't it cleaner/safer to create a new branch for each JIRA issue and then re-integrate with trunk when that fix/enhancement is complete and tested rather than having all the devs work directly off of trunk? I know there are more merges involved but this way if a JIRA is postponed or canceled it's easier to manage/isolate b/c it has its own trunk for that JIRA issue. Also, if somebody checks in a change set for a JIRA issue and breaks the build, the Hudson build will also break if it builds off trunk. And the other problem is that if another dev wants to 'svn co' from trunk, it's immediately a broken build. Then you have to coordinate with the developer who checked in the files that broke the build, etc. So as a matter of svn best practices, I'm wondering if it's best to create branches for each JIRA issue (esp. if they're more complicated enhancements, for example, that involve modifying/refactoring a lot of files and/or adding a lot of new files) or having all devs work right off the trunk? And maybe the answer depends on if it's a minor release (e.g. Seam 2.2) or patch fix release (e.g. Seam 2.2.1) or a large feature release like Seam 3.0.... Perhaps there is a svn URL for each Seam 3.0 module? Is that the strategy to keep it fairly isolated? On Thu, Mar 18, 2010 at 7:31 AM, Lincoln Baxter, III < lincolnbaxter(a)gmail.com&gt; wrote: > Hey Arbi, > > Long story short, we're still working on setting up the infrastructure and > providing that information to everyone so they can be on the same page. > > Hopefully we'll have this under wraps soon, > --Lincoln > > On Thu, Mar 18, 2010 at 1:36 AM, Arbi Sookazian <asookazian(a)gmail.com&gt;wrote: > >> HI all, >> >> Are there any documented "rules of engagement" or best practices >> concerning committing patches, bug fixes, etc. for JIRA issues with respect >> to Seam 3.0, for example? >> >> Specifically, do the Seam core devs and miscellaneous committers work >> directly off of trunk for all JIRA issues for a particular release or do >> they create a separate branch for each JIRA issue which is then reintegrated >> back into trunk? >> >> If the latter, then what about using Mylyn in Eclipse for task mgmt and >> context mgmt? The activation of tasks and tracking of change sets by Mylyn >> are useful in Eclipse workspaces where there are multiple JIRA issues (or >> tasks) to work on and isolate context for. >> >> And is a continuous integration server like Hudson or Continuum used as >> well? Is a build created by the CI server every time a file or change set >> is committed to trunk or is it schedule by CRON job? >> >> thx. >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> > > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" >