Hi Adam,
>I have a sandbox/build machine set up. Edits are made on various
>developer machines and checked in. All are tested on the sandbox and
>some pre-release components are checked in. All of this code is for an
>always evolving website. I need a flag of some sort that all developers
>can set on the sandbox version that upgrades that code to production.
>
If I understand you problem correctly, you want to do development and
testing in one area, and have a release area, which you don't want to
change independently of the development area. Branches are really the
way to go here.
Consider this repository layout:
---repository root
|---trunk
| |---index.jsp
| |---customer1
| | |---index.jsp
| | \---other.jsp
| |
| \---customer2
| |---index.jsp
| \---other.jsp
|
|---branches
\---release
|---index.jsp
|---customer1
| |---index.jsp
| \---other.jsp
|
|---customer2
|---index.jsp
\---other.jsp
Now you do all development under /trunk, for example you change and
commit /trunk/customer2/other.jsp. Now when you're satisfied with what
the development test server (which looks at /trunk) shows you, you just
copy /trunk/customer2/ to /branches/release/customer2. [1]
>Second, I thought of using a production branch but merging files from
>HEAD to the production branch seems too compilicated and I cannot figure
>out how to test the code that is upgraded to production.
>
As long as your developers vow to never commit changes to
/branches/release directly, you don't have to worry about the
complicated task of merging at all. [2] If I understood your workflow
correctly, that should be possible.
Hope that helps,
Philipp
[1] See the book about another typical repository layout, which might
make even make more sense in your situation, depending on if you have
areas of shared code between multiple customers.
[2] Only when you change something directly in the release area, you
must worry about merging, because a simple copy would overwrite these
changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 13 22:12:29 2003