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 Sat Feb 4 22:35:50 2006