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
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>)
(Question, is copying from 1.00rc2 to trunk/ also considered a commit by svn?)
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.
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
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 4 03:39:44 2006