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 <evert@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
Received on Mon Feb 6 04:24:58 2006