1 2 Previous Next 16 Replies Latest reply on Jul 29, 2010 1:25 AM by alexsmirnov Go to original post
      • 15. Re: Lessons Learned From M1 Build And How to Improve Build Structure.
        jbalunas

        Alexander Smirnov wrote:

         

        This is ok. The only one thing is 'tests' folder. For my opinion, they should be in 'modules' but tagged with release ( tags/4.0.x and tags/tests-4.0.x ). That allows to have identical sources in the distribution and SVN repository, so everyone could make a patch to fix particular issue without checking out QA tests, that would be pretty big. Patches for bugs is most often kind of community contributions, so we have to make it simple.

        That is fine with me, and it might be good to have QE handle their own tagging anyway in case they want to get in something specific prior to tag.  A minor questions here:

         

        /tags
          /tests-4.0.x
        
        or
        
        /modules
          /tests
            /<t/b/t>
        

         

        Another concern is branches/development folder. Many tools ( including Maven, Eclipse SVN plugins, SVN viewers ) relies on the default trunk/tags/branches structure,  so it would be more convenient to have development branches in the standard place. It should not overload repository because most of them should be deleted after merging.

        I see your point, but with we did not have to clutter the /branches so much :-(  Can the rest of the branch structure stay as is ( community, enterprise, archive)?  Do you see an issue with those?

        The steps to move build structure:

        - make archive folder and move outdated tags and branches there.

        - make tags for Alpha/M1 releases and copy there all tags from the current structure, similar to the http://anonsvn.jboss.org/repos/richfaces/tags/4.0.0.20100715-M1/ but with real copies instead of svn:externals links. I can make a shell script and perform that task.

        - move trunk modules from the 'root' into /root folder. Once agin, the /trunk already contains desired structure created by svn:externals, so that task should only replace links by the real content.

        Important: only svn move commands on the http://anonsvn.jboss.org/repos/richfaces/ repository should be used, to keep history and space ( svn does not really move files on the server, but only modifies links for them ).

        Agree - please create some jira's for these.

        Link to the 'build' folder would make more easily to build project from svn. If these projects aren't included into the source,  anyone who wants to build richfaces locally has to modify Maven settings to enable Jboss repositories.

        hmm, I guess you are right here, but the link would need to be updated when even richfaces-parent or the build resources are released.  But that should not be a big deal.

         

        Lets go with this.

        • 16. Re: Lessons Learned From M1 Build And How to Improve Build Structure.
          alexsmirnov

          I've written some instructions about development workflow with feature branches in article Trunk code policy.

          1 2 Previous Next