You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Chris Gilliam <ch...@gmail.com> on 2008/05/29 14:48:37 UTC
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
RE: Re: Multiple Projects that make up a Product
Posted by "Gleason, Todd" <tg...@impac.com>.
On the topic of repo structure, I have been looking at something a bit
different from what I generally see proposed, and would like comments on
it. Here's the general layout for one large product with lots of
versions.
/[Product]/
projects/ (intended to contain different product versions,
could as easily be called "releases")
[product version 1]/
branches/
main/ (the "trunk"-equivalent for this
product version)
.../ (areas for customer patches, bug
fixes, features, etc.)
tags/
[product version 2]/ (one of these would contain tags
and certain branches for the trunk's current product version)
...
trunk/
The thinking behind hiding branches and tags under product versions is
that I want it to scale a little easier than having thousands of tags in
one folder, or dozens of branches under one folder. In this respect I
don't think the SVN "best practices" lend themselves well to larger
projects.
The main development in this scenario still occurs in the trunk (an
unstable trunk in our case). Each build would get a tag under the
product version corresponding to the trunk. At some point near release
(feature-complete, generally), the trunk gets copied to branches/main
for that product version, and all subsequent commits to branches/main
tightly controlled (lots of ways to do this; I don't need to go over
them here). The subsequent builds for that release would come from
branches/main rather than trunk.
What I'd like people to tell me is:
1. Does this seem to scale better than the standard recommendations?
2. Is it overly complex, and if so, is there something simpler we could
do without sacrificing scalability? Mind you, I don't care whether SVN
can handle thousands of tag folders--it is visually tough to wade
through them in any kind of UI, and I think the feeling of "clutter"
would discourage developers from creating branches when they should.
3. Also, are there tools that integrate with SVN which are hard-coded
to expect certain paths, which we could not use with this scheme?
Also note: I'm aware that by inverting the product version and
branches/tags folders and removing the projects folder, you might end up
with an equally scalable system that seems to fit the best practices
(you would just be nesting product versions under both branches and
tags). What I don't like here is that you replicate the product version
in both the branches and tags folders, and should you eventually want to
move it somewhere out-of-sight, it's two operations.
-----Original Message-----
From: Les Mikesell [mailto:lesmikesell@gmail.com]
Sent: Thursday, May 29, 2008 9:19 AM
To: Chris Gilliam
Cc: users@subversion.tigris.org
Subject: Re: Multiple Projects that make up a Product
Chris Gilliam wrote:
> 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?
One approach is to make a product-level entry that has your
build/packaging scripts and a set of external references to pull in all
of the components. During development you may want to let these
reference the head of the projects trunk or branch work, but for
releases you would point them to tag copies of each component. This
level can also have its own trunk/branch/tag structure for simultaneous
versions, and it doesn't really matter if the components live in the
same repository or not.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Multiple Projects that make up a Product
Posted by Les Mikesell <le...@gmail.com>.
Chris Gilliam wrote:
> 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?
One approach is to make a product-level entry that has your
build/packaging scripts and a set of external references to pull in all
of the components. During development you may want to let these
reference the head of the projects trunk or branch work, but for
releases you would point them to tag copies of each component. This
level can also have its own trunk/branch/tag structure for simultaneous
versions, and it doesn't really matter if the components live in the
same repository or not.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Multiple Projects that make up a Product
Posted by Jorge Medina <jm...@e-dialog.com>.
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@gsicommerce.com]
Sent: Thursday, May 29, 2008 12:34 PM
To: Jorge Medina; users@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@gsicommerce.com
-----Original Message-----
From: Jorge Medina [mailto:jmedina@e-dialog.com]
Sent: Thursday, May 29, 2008 11:56 AM
To: users@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@gmail.com]
Sent: Thursday, May 29, 2008 10:49 AM
To: users@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Multiple Projects that make up a Product
Posted by Florian Seydoux <fl...@gmail.com>.
Anderson, Aaron wrote:
> [...]
> Some people split up into components because they want to release the different components at varying velocities.
> [...]
> Using SVN externals or directory structuring won't work so well for this.
Hi Aaron,
Can ask you why? (which drawback has the SVN externals)
=> I more or less in the same situation than Chris, but I don't really
have the choice of the build software
(well, we always have the choice, but it imply to convince a lot of
people to do additional works, "just for that"),
we are in the process of moving for multiple repositories in a single
one, and some of my co-workers push to use the organization proposed by
Jorge... (but a build is rarely made on the different trunk, especially
the external releases - that you call 'varying velocities').
Thanks,
Florian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Multiple Projects that make up a Product
Posted by "Anderson, Aaron" <An...@gsicommerce.com>.
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@gsicommerce.com
-----Original Message-----
From: Jorge Medina [mailto:jmedina@e-dialog.com]
Sent: Thursday, May 29, 2008 11:56 AM
To: users@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@gmail.com]
Sent: Thursday, May 29, 2008 10:49 AM
To: users@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Multiple Projects that make up a Product
Posted by Jorge Medina <jm...@e-dialog.com>.
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@gmail.com]
Sent: Thursday, May 29, 2008 10:49 AM
To: users@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org