You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mark <mm...@gmail.com> on 2006/02/04 02:39:00 UTC
suggestions on layout
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
Re: suggestions on layout
Posted by Lieven Govaerts <lg...@mobsol.be>.
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
Re: suggestions on layout
Posted by Mark <mm...@gmail.com>.
Thank you guys for the heads up. I didn't realize there were so many
factors to take into consideration in SCM. This is a project in itself
already (and a very interesting one too!).
I guess my team and I will have to discuss this thoroughly. We're
going to use scenarios to analyze the various layout's suggested in
this thread. The following scenario, which I hope is realistic enough,
will be used:
-------- begin scenario ------
1) Development in version 1.00 begins. the-erp only contains 3
modules: cmnwidgets, security, and inventory. cmnwidgets and security
will be used in all other modules in the future. inventory at the
moment is a stand-alone module
2) 1.00rc1 is released
3) 1.00 is released
4) 1.00 hotfix #1 is released to correct certain security issues
5) Development in version 2.00 begins. the-erp will contain an
additional module: sales. The sales and inventory module will be
tightly integrated in this planned release.
6) 1.00 hotfix #2 is released to improve the UI of a couple common widgets
7) 2.00rc1 is released
8) 1.00 hotfix #3 is released to correct security issues
9) 2.00 is released and now contains the following modules: security,
cmnwidgets, inventory, and sales. inventory is now integrated with
sales.
10) an organization shows interest on our erp and wants to purchase
just the inventory module. We then release v2.00 to that organization
but with only the 3 modules: security, cmnwidgets, and inventory.
(For step #10 I'll heed Evert's advice and depend on Ant to build a
v2.00 sans the sales module. Also, the inventory module, while
integrated with sales shall also be smart enough to stand by itself if
sales module is not present.)
11) 2.00 hotfix #1 is released to correct a security problem in the sales module
12) 1.00 hotfix #4 is released to correct a portion of the database structure
13) Another organization wants to purchase the sales module. However,
they also want certain changes to the UI and part of the process flow.
These changes are so highly customized that they will only apply to
their organization.
-------- end scenario ------
Best regards,
Mark
On 2/5/06, Evert | Collab <ev...@collab.nl> wrote:
> Mark wrote:
>
> [snip]
> > We will set up a policy that the trunk sub-directories should only
> > contain the latest stable code.
> >
> I think the trunk should always contain the latest unstable code..
> For example:
>
> You are working on v1.0 on your project. The second one of your
> developers starts working on features that are going to be in v2.0, but
> its out of the scope of v1 a v1.0 branch will be made, and all new
> features go into the trunk. From that point on changes or bugfixes that
> have to be done in both the v1 branch and the trunk, they would have to
> get merged.
>
> [snip]
> > 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>)
> >
> >
> This doesn't seem like the best solution to me, it feels like a hack and
> its not what the commit message is intended for. [at least thats what i
> think]
> I would really suggest just write a script that does this.
>
> ./deployto [branchname/url] [server]
>
> I personally prefer to do this with a build engine like 'ant'. If you
> are using PHP i can really suggest phing.
> > (Question, is copying from 1.00rc2 to trunk/ also considered a commit by svn?)
> >
> >
> Any change is a commit
> > 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.
> >
> >
> Yea thats an issue, I agree ;)
> > 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
> >
> >
> This is definitely what I would do.
> > 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?
> >
> >
> Yes it would, if you are using a build-script such as make, ant, or
> phing. If you won't, you will likely run into a lot of issues. Simply
> because you can't depend on the fact that you can retain all your
> module-code in that one subdirectory. I bet some modules sometimes
> depend on each other and other modules need to make global configuration
> changes..
>
> My advice: Use the right tool for the job, subversion isn't for this
> problem.
>
> Evert
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: suggestions on layout
Posted by Evert | Collab <ev...@collab.nl>.
Mark wrote:
[snip]
> We will set up a policy that the trunk sub-directories should only
> contain the latest stable code.
>
I think the trunk should always contain the latest unstable code..
For example:
You are working on v1.0 on your project. The second one of your
developers starts working on features that are going to be in v2.0, but
its out of the scope of v1 a v1.0 branch will be made, and all new
features go into the trunk. From that point on changes or bugfixes that
have to be done in both the v1 branch and the trunk, they would have to
get merged.
[snip]
> 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>)
>
>
This doesn't seem like the best solution to me, it feels like a hack and
its not what the commit message is intended for. [at least thats what i
think]
I would really suggest just write a script that does this.
./deployto [branchname/url] [server]
I personally prefer to do this with a build engine like 'ant'. If you
are using PHP i can really suggest phing.
> (Question, is copying from 1.00rc2 to trunk/ also considered a commit by svn?)
>
>
Any change is a commit
> 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.
>
>
Yea thats an issue, I agree ;)
> 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
>
>
This is definitely what I would do.
> 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?
>
>
Yes it would, if you are using a build-script such as make, ant, or
phing. If you won't, you will likely run into a lot of issues. Simply
because you can't depend on the fact that you can retain all your
module-code in that one subdirectory. I bet some modules sometimes
depend on each other and other modules need to make global configuration
changes..
My advice: Use the right tool for the job, subversion isn't for this
problem.
Evert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org