svn merge and how to best architect for a live site.

[Daevid Vincent <da...@daevid.com>]

This may be a little lengthy, but we need guidance on the best way to
proceed.

 

.         We are going to provide a LAMP / Symfony project web based service
(as in, we host it, no sharing of code, users login, etc.)

.         We have four developers

.         All developers have a trunk checkout

.         We're currently not using branches (we're not at that stage really
yet)

.         We have a UAT box for testing which SVN UPDATEs from Subversion

.         We have a Production box which also SVN UPDATEs from Subversion
when UAT is blessed

 

Our problem is, what is the best way to set this up. The challenges are:

 

.         Doing a complete checkout (like a branch) and setting up that
environment is tedious and we'd prefer not to do continual branch checkouts
(as is typically the case in software development where the trunk is used
and branched for each release).

.         How do we work on new (major) features/bugs (ie. normally this is
done in trunk), while still being able to update Production with minor but
critical fixes (normally in a branch that would be hand merged back into
trunk at the same time to prevent deviation too far).

.         We wish to release features/updates every two weeks to Production.

.         We wish to release said critical bug fixes to Production as they
arise.

 

We were considering the idea of everyone working in the branch - which would
really just be a single long branch that really never forks or is forked. It
simply parallels trunk (which is where UAT/Prod pull from currently). We'd
put minor changes in trunk. Then use SVN MERGE to put the big branch work
back into trunk when ready. We would then setup another UAT box that updates
from the branch (so now we'd have one of each) so testing can be done on
both branch & trunk simultaneously.

 

Keep in mind, the actual naming of 'branch' and 'trunk' is really arbitrary.
We could simply fork and reconfigure UAT/Prod to UPDATE from 'branch', and
we could do all the work in 'trunk'.

 

The question is how do we get all that magic in between. SVN MERGE seems
like the solution, but having never used it, we are concerned at how
intelligent and painless the merges are for all the developers. Or do we
have to manually make changes to both branch/trunk each step of the way.

 

Is there a better solution? Obviously we're not the first to have a live web
service tied to subversion.

Re: svn merge and how to best architect for a live site.

[Blair Zajac <bl...@orcaware.com>]

Daevid Vincent wrote:
> This may be a little lengthy, but we need guidance on the best way to 
> proceed…
> 
>  
> 
> ·         We are going to provide a LAMP / Symfony project web based 
> service (as in, we host it, no sharing of code, users login, etc.)
> 
> ·         We have four developers
> 
> ·         All developers have a trunk checkout
> 
> ·         We’re currently not using branches (we’re not at that stage 
> really yet)
> 
> ·         We have a UAT box for testing which SVN UPDATEs from Subversion
> 
> ·         We have a Production box which also SVN UPDATEs from 
> Subversion when UAT is blessed
> 
>  
> 
> Our problem is, what is the best way to set this up. The challenges are:
> 
>  
> 
> ·         Doing a complete checkout (like a branch) and setting up that 
> environment is tedious and we’d prefer not to do continual branch 
> checkouts (as is typically the case in software development where the 
> trunk is used and branched for each release).
> 
> ·         How do we work on new (major) features/bugs (ie. normally this 
> is done in trunk), while still being able to update Production with 
> minor but critical fixes (normally in a branch that would be hand merged 
> back into trunk at the same time to prevent deviation too far).
> 
> ·         We wish to release features/updates every two weeks to Production.
> 
> ·         We wish to release said critical bug fixes to Production as 
> they arise.
> 
>  
> 
> We were considering the idea of everyone working in the branch – which 
> would really just be a single long branch that really never forks or is 
> forked. It simply parallels trunk (which is where UAT/Prod pull from 
> currently). We’d put minor changes in trunk. Then use SVN MERGE to put 
> the big branch work back into trunk when ready. We would then setup 
> another UAT box that updates from the branch (so now we’d have one of 
> each) so testing can be done on both branch & trunk simultaneously.
> 
>  
> 
> Keep in mind, the actual naming of ‘branch’ and ‘trunk’ is really 
> arbitrary. We could simply fork and reconfigure UAT/Prod to UPDATE from 
> ‘branch’, and we could do all the work in ‘trunk’.
> 
>  
> 
> The question is how do we get all that magic in between. SVN MERGE seems 
> like the solution, but having never used it, we are concerned at how 
> intelligent and painless the merges are for all the developers. Or do we 
> have to manually make changes to both branch/trunk each step of the way.
> 
>  
> 
> Is there a better solution? Obviously we’re not the first to have a live 
> web service tied to subversion.

Until svn 1.5 comes out with merge tracking support, use svnmerge.py to handle 
all the merging tasks:

http://www.orcaware.com/svn/wiki/Svnmerge.py

When 1.5 comes out, switch over to native merge support:

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html

Regards,
Blair


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