[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

suggestions on layout

From: Mark <mmaglana_at_gmail.com>
Date: 2006-02-04 03:39:00 CET

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.