Hi Mark,
where I work we have almost exactly the same setup as which you're
describing here. We have to manage some 100 repositories in total, all
but a few structured the same way.
Let me fill in some of the gaps in the setup and show you some of the
disadvantages:
1. You're only talking about the development process, but when you start
releasing your product you'll probably start a maintenance process as
well right? For that purpose, since we always integrate ( = copy-merge )
the last stable code to trunk, we directly create a new Maintenance
branch ( MAINT_V0001.00.00 ) from the trunk HEAD revision as well.
2. If we release a Hot Fix, we integrate take some time, that code to
the trunk as well. The trunk always contains the latest version in
production, be it major/minor or a hot fix release.
3. When a hot fix is released, we can then merge those bugfixes to the
latest development branch as well. We call that a rebase merge.
Advantage is that you can't reintroduce the same solved bugs
(regression) in a new version of your product.
Disadvantages of this setup:
1. Since the trunk is used as a merging branch between maintenance and
development, and serves as the branch containing the latest production
code, this setup does not allow supporting multiple versions of your
product at the same time! If you plan to individually sell modules, you
have to think about how to manage hot fix releases for older versions!
2. In our setup we do all bug fixes on the maintenance branch, and merge
that to trunk when the hot fix is released. Since Subversion does not
have merge tracking, we normally do not merge individual bug fixes
directly to the development branch. Disadvantage: bug fixes are only
merged to the new dev. branch when the hot fix containing the bug fixes
is released.
3. Merging changes on the maintenance branch to the new development
branch can be time-consuming, as your new code can be changed or
refactored a lot. This is not a job that people love to do, as it
involves a lot of manual work, talking to other developers to find out
the best way to merge conflicting changes... Make sure you provide
enough time in your planning for this job, select multiple people
capable of doing it and make a rotating schedule for them.
4. Avoid renaming top folders of your source code. Subversion currently
does not support true renames, so when you rename the top folder of the
development branch you can merge the bug fixes manually.
Since we have to support a few hundred people on 100 applications, we
documented the whole source code management process. Be aware that most
developers are not very interested in scm + while Subversion is not
difficult to use, it has some quirks and can be confusing to new users.
So, if possible support them with tools and definitely provide adequate
training!
The rest of my comments are in between your text:
On Sat, 2006-02-04 at 10:39 +0800, Mark wrote:
> Hello folks, I thought I'd solicit suggestions from you guys since
> we're in a bit of a limbo as to how the repository should be arranged.
>
> Presently we are building a customized ERP software (let's name it
> the-erp) for our company's use. It is a web app with various modules.
> Each module will be treated as one project by the company.
>
> One proposal is that we have one repository named the-erp and under
> its root are sub-directories for each specific module. The rep will
> then look like this:
>
> the-erp
> \---accounting
> \---hr
> \---inventory
> \---purchasing
> \---security
>
> and so on.
>
> Each module sub-directory will then be subdivided into the standard
> trunk, branches, tags layout such that:
>
> the-erp
> \---accounting
> | \---branches
> | \---tags
> | \---trunk
> \---hr
> \---branches
> \---tags
> \---trunk
>
> and so on.
>
> We will set up a policy that the trunk sub-directories should only
> contain the latest stable code. All other codes (e.g. alpha, beta,
> release candidates, patches) shall be located under the appropriate
> branches sub-directory or tagged in the appropriate tags
> sub-directory. For example, in the scenario where we are testing
> inventory v1 rc2, the following would be the contents of the inventory
> sub-directory:
>
> inventory
> \---trunk (empty)
> \---branches
> | \---1.00 (possibly still unstable code)
> \---tags
> \---1.00rc1 (code for RC1)
> \---1.00rc2 (code for RC2)
>
> The trunk is empty because we have not achieved stability in version
> 1.0 Now, let's say RC2 has been fully tested and deemed ready for
> deployment, we then copy the contents of 1.00rc2 to trunk/ AND to
> another tag called 1.00/ and the repository will end up as follows:
>
> inventory
> \---trunk (stable code copied from tags/1.0rc2)
> \---branches
> | \---1.00 (possibly still unstable code)
> \---tags
> \---1.00rc1 (code for RC1)
> \---1.00rc2 (code for RC2)
> \---1.00 (copied from 1.00rc2)
>
> This will be the same for all modules in the-erp
In our setup we have a sublevel of tags, to avoid 100s of folders
directly under tags like this:
\tags
\candidates -> release candidates
\releases -> major/minor + hot fix releases
\builds -> nightly builds
\datafixes -> special type of release, only data changes
\development -> devs can make tags here
> Now, I will also be setting up the repository such that certain
> commits will trigger an update of either of two web servers: the
> production server and/or the tip server.
>
> the production server will be automatically updated when two
> conditions are met: 1) A commit was made in any of the the trunk
> directory of any module AND 2) the commit log message included a
> certain keyword (for example: DEPLOYTO <production server address>)
Hmm, be careful here. When you commit to trunk the release coordinator
has to be sure the code is stable, but don't you want to test that on an
acceptance environment first? Are you sure that if you're relco releases
to the trunk at 10AM, that you then automatically want to update the
production server? Maybe you need to inform and train people first? Or
wait till noon or evening so you're sure you don't interfere with
people's sessions?
>
> (Question, is copying from 1.00rc2 to trunk/ also considered a commit by svn?)
Yes. In fact, you don' t copy that branch, you do a copy-merge instead.
With a copy-merge you compare the 1.00rc2 branch with the trunk branch,
and then merge that delta to a working copy of trunk. So you have the
trunk update to 1.00rc2 local on your disk. Then you can commit that
delta to trunk in the repository.
> The tip server, on the other hand, will be automatically updated when
> a commit is made to any directory in the repository.
>
> Also to avoid slowing down a commit, these server updates will be done
> asynchronously.
>
> Is this a practical way of arranging things? Once concern aired about
> this layout is the laborous way of updating a programmer's local copy.
> Say we already have all the modules coded and a programmer wants to
> get the latest stable copy of the whole erp suite. He will have to
> update each local copy of each module from the appropriate trunk
> folder.
You can write a small script for that, there's only 5 projects, so you
need a script with 5 'svn update' statements.
> An alternative suggested was to put branches, tags, and trunk directly
> under the-erp AND THEN have each module directly under the appropriate
> directory such that:
>
> the-erp
> \---trunk
> | \---accounting
> | \---hr
> | \---inventory
> | \---purchasing
> | \---security
> \---branches
> | \---1.00 (possibly still unstable code)
> | \---accounting
> | \---hr
> | \---inventory
> | \---purchasing
> | \---security
> \---tags
> \---1.00rc1 (code for RC1)
> \---accounting
> \---hr
> \---inventory
> \---purchasing
> \---security
In this setup all your modules will have to follow the same release
schedule!
> Another concern about the above layout involves the scenario where we
> will sell this product to other organizations on a module by module
> basis. Would the above layout support it and would it be easy to
> manage?
>
> Any comments/suggestions would be highly appreciated. Thanks!
>
> Mark
Hope this helps.
Lieven.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 4 14:27:52 2006