Branching scenario

["Adam T. Gautier" <ad...@yahoo.com>]

I am somewhat new to version control systems and I need to solve a
problem.  I have searched the srchives and I still believe that my
answer is in there but I have been unable to find it.

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. 
This way pre-release code can sit side by side with the current
production code.  Again this is only for new directories on the website
that are under development.

example directory tree

---root
 |---index.jsp
 |---customer1 (release)
 | |---index.jsp
 | |---other.jsp
 |---customer2 (pre-release)
 | |---index.jsp
 | |---other.jsp

First, I thought I could use a release property but I cannot figure out
how to checkout based on a property and I cannot figure out how to move
the property on a single version(i.e version 123) to the same file
later(i.e. version 567).  So I don't think this is going to work.

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.

Third I think that I can provide access to the sandbox for loading test
directories that are not in source control.  This does not make me very
happy in that I will lose the version while in development.

I believe that I am just not thinking about this correctly...

All help would be great!

-- 
Adam T. Gautier
adam_gautier@yahoo.com
(617) 557-9699

Re: Branching scenario

[Paul Lussier <pl...@lanminds.com>]

In a message dated: 12 Mar 2003 14:00:25 EST
"Adam T. Gautier" said:

>I am somewhat new to version control systems and I need to solve a
>problem.  I have searched the srchives and I still believe that my
>answer is in there but I have been unable to find it.

[...snip...]

>I need a flag of some sort that all developers can set on the sandbox
>version that upgrades that code to production.
>This way pre-release code can sit side by side with the current
>production code.  Again this is only for new directories on the website
>that are under development.

I'm a little confused about what you're asking here.  Are you looking 
for some mechanism by which, when present, automatically promotes the 
sandbox code to production?

I think the way I would structure your repository would be something 
more along the lines of this:

---root
 |-sandboxes/ 
    |---index.jsp
    |---customer1
    | |---index.jsp
    | |---other.jsp
    |---customer2
    | |---index.jsp
    | |---other.jsp
 |-production
    |---index.jsp
    |---customer1
    | |---index.jsp
    | |---other.jsp
    |---customer2
    | |---index.jsp
    | |---other.jsp

Where the sandboxes/ area is all developmental code, and production/ 
is all released working code.  Basically what you have here are 
branches or copies.  Then, when a certain sandbox rev becomes 
"releaseable", you merge it into the production track.

Now, if you're looking for a way to automate this, then you'd have to 
establish some sort of policy around what your 'release' criteria is, 
and what determines that code is ready to be 'released'.  Once this 
policy is established, you can probably code that into a chekin
-trigger script to live on the svn server.

Does that help?

Also, I'd recommend reading the subversion handbook at:

	http://svnbook.red-bean.com/

Available in HTML or PDF :)
-- 

Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE

	It may look like I'm just sitting here doing nothing,
   but I'm really actively waiting for all my problems to go away.

	 If you're not having fun, you're not doing it right!



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Branching scenario

[Philipp <pi...@users.sourceforge.net>]

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