RE: RE: Multiple Projects that make up a Product

I agree with Aaron. There must be a reason to divide the product into components, and he points out the two major reasons for doing it.

I strongly favor to divide the product into "components" even if they are released at the same rate inside a Product. They should be logical components with related functionality, fitting some architectural design that layers the application.

Creating a huge source java tree with the whole source code for a whole product would make it impossible to extract a library to reuse it. (I saw this happen. I was amazed anybody would even think on having a single tree for such a complex product).

-Jorge

-----Original Message-----
From: Anderson, Aaron [mailto:AndersonA_at_gsicommerce.com]
Sent: Thursday, May 29, 2008 12:34 PM
To: Jorge Medina; users_at_subversion.tigris.org
Subject: RE: RE: Multiple Projects that make up a Product

Another question to ask is why you are dividing up the master product into components... Some people do this because they want to organizationally control who works on which pieces, but they are all rev'ed and released at the same rate - at which point the directory structuring below works.

Some people split up into components because they want to release the different components at varying velocities. If you are doing this, then you really have a dependency management issue and you probably want to look into something like using Maven or Ant/Ivy to force your build process to pull specifically published versions of the components together to assemble builds that you want. Using SVN externals or directory structuring won't work so well for this.

- Aaron Anderson
andersona_at_gsicommerce.com

-----Original Message-----
From: Jorge Medina [mailto:jmedina_at_e-dialog.com]
Sent: Thursday, May 29, 2008 11:56 AM
To: users_at_subversion.tigris.org
Subject: RE: Multiple Projects that make up a Product

Hi Chris,

Your question is an interesting topic of discussion.
I would love to hear from other organizations and theirs repository organization.

You need to design your repository organization and adapt your build system around it.

If you are making a Product, composed of several "components" (those pieces that create the jar files, but it could be composed of DLLs, jars, config files, etc) and you are just interested on building the Product as a whole entity, then you may consider to organize your repository in a single Project, still with different "components" that are build independently.
In this case, you would need a "component" that I called below the "builder" that knows the order of how to build the Product. Using this organization it is easier to keep the build instructions within the Project itself, rather than leaving this task to the build system.

/TheProduct
        /trunk
                /components
                        /component1
                                /src
                                build.xml
                                build.properties
                        /component2
                                /src
                                /build.xml
                                /build.properties
                        /componentN
                        /builder
                                /mybuildscript.sh
        /branches
                /FeatureA
                     /components
                           /component1
                                /src
                                build.xml
                                build.properties
                           /component2
                                /src
                                /build.xml
                                /build.properties
                           /componentN
                /FeatureB
        /tags
                /Release-1.0
                /Release-1.1
                /Release-2.0

In this way, you track your entire product as a single project that contains all the code. You can build the previous version just by getting a tagged release.
You could even build the product with a given feature that crosses several components by just taking a branch where that feature is being implemented.
The disadvantage is that every developer gets the whole source code for the whole product for each branch they need to work on, but this only happens a few times....and disk space is cheap! (I don't know if Subversion allows getting "partial" trees, it would be wonderful!)

In the original repository organization shown in your message, you would need to tag the version that you released. That is not too bad.
You would normally build the product with the trunk of each component on a daily basis. When you release the Product, then you create the tagged copies.
Branches would normally be used by the developers, not your build system.
In this case, your build system holds the knowledge of how to build the Product, and you need to keep track if you take the trunk, a branch or a tagged copy to build a particular instance of the Product.

/components
        /component1
                /trunk
                        /src
                        build.xml
                        build.properties
                /branches
                        /featureA
                        /featureB
                /tags
                        /As-In-Release-1.0
                        /As-In-Release-2.0
        /component2
                /trunk
                        /src
                        build.xml
                        build.properties
                /branches
                        /featureA
                        /featureC
                /tags
                        /As-In-Release-1.0
                        /As-In-Release-2.0

With this approach you can release each component as an independent library...but if you are not sharing built components with other teams, I don't see the benefit of tracking at such fine-granularity.

I am new to Subversion, I used Accurev before.
I'm planning on using the approach I described at the beginning; if later on I discover that a component has to be shared among two Products -for example a great utilities library-, then I would probably make such library a Product itself and manage it as a final Product.

-Jorge

___________________________
From: Chris Gilliam [mailto:chris.gilliam_at_gmail.com]
Sent: Thursday, May 29, 2008 10:49 AM
To: users_at_subversion.tigris.org
Subject: Multiple Projects that make up a Product

Hello all,
 
I am new to SVN and have a question about how to setup and manage a repository.  We are building an Enterprise Level application that will have multiple projects that will be compiled into Jars and the group of Jars will make up the Product. When I look at the SVN documentation about multiple Projects in SVN it seems straight forward. However, the documentation doesn't lend itself to the product level.

So, I have multiple projects

repo/
 -project 1
   - branches
   - trunk
 -project 2
   - branches
   - trunk

Now I want to make a build of the product that will be compiling project 1 and project 2 into jar files and package them for the product.  I can see how managing this could get real crazy... All of a sudden project1 has several branches and  project 2 has several branches and I need to provide a build script that know which ones to pull into the project.

Has anyone done something like this before and is there a better way to manage it?

Thanks,

-- 
The Hardest thing in the world to do is Think,
Mark Twain 
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org