On Friday 18 February 2005 03:59 am, Butlin, Jason (UK - Epsom) wrote:
> We've got a product suite that contains a number of individual programs,
> which can be released individually. Obviously, as with most projects,
> there are a number of shared files used by all the products. My problem
> is that I'm struggling to determine the best way to organize the
> repository in such as way that the branching of the projects is least
> painful.
>
> We'd need to cater for the ability to branch some components for an
> individual release, and allow developers to easily go back to a previous
> version of a specific component for bug fixes. This is made more
> complicated by the shared code, which would obviously have to be
> branched every time a component was branched.
For several years, I worked at a medium sized company that produced retail,
shrink-wrap software. When I left, we had 9 separate products, two of them
had a two dozen customized OEM versions and everything used a common shared
library. We generally released at least one major version of each product
every year and followed the major release with minor updates for bug fixes.
While we used Perforce at the time, the same principles still apply.
Our technique was to utilize something like the second structure you
mentioned:
/repos
/main
/releases
/branches
/repos/main
.../projectA
.../projectB
.../shared
/repos/releases
.../projectA/
.../projectB
/repos/releases/projectA
.../1.0
.../1.0a
.../2.0
Let's say projectA is approaching code-freeze and we want to isolate it from
any other changes on the main dev line. Rather than branching ALL of main,
which is the natural inclination with cheap-copies, we ONLY branched the
shared code and project-specific code. In Perfoce, you could do this easily
in one atomic commit. In Subversion you can do this either of two ways:
1) Create the branch in multiple commits:
$ svn mkdir http://server/svn/repos/releases/projectA/1.0 -m ""
$ svn mkdir http://server/svn/repos/releases/projectA/1.0/projectA -m ""
$ svn mkdir http://server/svn/repos/releases/projectA/1.0/shared -m ""
$ svn cp -r XXX projectA
http://server/svn/repos/releases/projectA/1.0/projectA -m ""
$ svn cp -r XXX shared http://server/svn/repos/releases/projectA/1.0/shared -m
""
2) Create the branch locally and then commit:
$ svn mkdir releases/projectA/1.0
$ svn mkdir releases/projectA/1.0/
$ svn update -r XXX main
$ svn cp main/projectA releases/projectA/1.0
$ svn cp main/shared releases/projectA/1.0
$ svn commit releases/projectA/1.0 -m ""
We went with this approach for several reasons:
A) The bulk of the development work occurs in the main dev line.
B) Most of our developers worked on multiple projects in the main dev line.
This arrangement made it easy to perform the initial checkout.
C) Many of developers made small changes to the shared code. By keeping the
projects and shared code together, it was easy to build all products and
quickly test the impact of changes to the shared code.
D) Only a handful of developers worked on release branches regularly. These
people would keep full local copies of their releases branches, while
everyone else could blow away their local copies after the release date.
Given the four items I just mentioned, it seemed to make logical sense to
group "things" together. Since the bulk of development occurred in multiple
projects simultaneously on the trunk, we wanted to make it easy to build and
test the current code base.
Although this approach increased the amount of work necessary to create a
branch, that was outweighed by the positive benefits of easy access to
projects and shared code. Hopefully this provides you with some food for
thought.
-Sean
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 18 18:03:00 2005