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_at_gmail.com]
Sent: Thursday, May 29, 2008 9:19 AM
To: Chris Gilliam
Cc: users_at_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_at_gmail.com
---------------------------------------------------------------------
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
Received on 2008-05-29 17:56:31 CEST