RE: Multiple Projects that make up a Product

Hi Chris,

     I think you replied just to me instead to the list. Here are my
comments:

     I would not do changes to the "tagged" (Version 1.0) branches.

     I would rather do the following:

            1) When Version 1.0 is released, create a copy of the trunk
and tag it (E.g. /myproject/tags/release-1.0). This code should NEVER
change

            2) At the same time, create a branch from the trunk for
maintenance of Version 1.0, for example,
/myproject/branches/maintenance-of-1.0

            3) Fix in the maintenance branch (sometimes you can't make
the change in the trunk, like when files were removed from the trunk )

            4) Merge from the maintenance to the trunk if the bugfix is
also applicable in the trunk.

            5) If you do a new release, it is no longer 1.0 , create
another tag (Perhaps /myproject/tags/release-1.0.1). Again, this code
NEVER changes.

            At this point you may want to close the branch
maintenance-of-1.0 and create a new one.
(/myproject.branches/maintenance-of-1.0.1)

________________________________

From: Chris Gilliam [mailto:chris.gilliam_at_gmail.com]
Sent: Thursday, May 29, 2008 5:43 PM
To: Jorge Medina
Subject: Re: RE: Multiple Projects that make up a Product

Thanks to everyone that has replied...

Jorge I have decided to go with your solution. After working and
playing today I had came to the same component level, i was different in
i was using branches to do release vs tags. Reason being I want
developers do be doing code off of the Tip/trunk... Once the time comes
to create a release we create a branch say Version 1.0 . After that is
created it is locked down and no direct code changes can be made in that
branch. Now when testing finds a defect that build, the fix will be done
in the Tip/Trunk and svn merged back into the branch. The goal here is
to keep from fixing defects in many releases / branches just make the
fix in tip/trunk and push it where you need it. There may be some
extreme cases where the code in the branch has to change if a client has
a old release and the Tip/trunk has moved really along. Love to hear
thoughts on this?

Aaron the main reason we are doing this is we have several develoment
teams in Beijing and they will be working on there pieces. Eventually
they will all have to play together but a lot of development can be done
with out other areas.

Thanks everyone for your help.

Chris

On 5/29/08, Jorge Medina <jmedina_at_e-dialog.com> wrote:

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
-- 
The Hardest thing in the world to do is Think,
Mark Twain