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

Re: Branching scenario

From: Philipp <pixelpapst_at_users.sourceforge.net>
Date: 2003-03-13 22:07:15 CET

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

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

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