Jan Hegner wrote:
> you can easily do the complete development on the "release-branch" if
> your company works on one BIG product. The company I work for has
> several products which share a large amount of code, organized in
> libraries. The different products have different release cycles.
>
> Before we were branching for releases the development took a little bit
> place like the following scenario:
>
> Product A was about to released, so the complete code of the product A
> (including the libraries) was frozen and only bug fixes were allowed.
> Developers of Product B always had to make sure that their changes would
> not affect product A.
>
> So, nowadays we're developing our products in the trunk, as mainline of
> development. Releases that need feature freeze must be branched.
>
> If we would only develop in release branches for different product,
> there would be a lot of merge operations necessary between different
> release branches for the libraries (aka. shared code). With a trunk any
> changes made to a release branch can be easily merged back.
>
> That's why we need a trunk.
Another option for this type of situation is to treat the common
lib as it's own project with its own releases. The separate projects,
A, B, etc treat the common lib as if it was from a 3rd party source.
In SVN you could either do a vendor drop tactic or an svn:externals
to link in a given release of the common lib. The vendor drop
allows you to change things as a particular project needs while
you really consider if the code should be in the common lib or in
the project. If it should be in common you merge it back to the
real common project, and if not you merge it out of your vendor
drop and into your project's code base. Using an external
would force the devs to think more before they place code
in one place or the other, which may not be a bad thing.
Still has nothing really do to with using branches or trunk or
whatever, as those tactics would be layered on top of the treatment
of the common lib.
-Byron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jan 13 00:23:10 2007