managing svn branches between multiple developers and b/w dev and production servers

[Cory Forsyth <co...@gmail.com>]

Hi,

I was encouraged to post this question to the SVN mailing list.  If
anyone on this list has suggestions for me I'd be very happy to hear
them. Thanks.

I'm using SVN for a website I'm in charge of developing. I have 4
developers who are working on the project. I want them to be able to
test their code before releasing it live (obviously), so I created a
test server.  My idea was that I would create a branch of the code off
the main trunk and this is where the developers would make their
edits, then they would push to the dev server where I could have
someone do some QA on it, and then if it looks good I could merge it
up to the main trunk and push it to the live server.

The problem I'm running into, though, is that I don't think SVN is
really meant to keep two side-by-side branches going. I have been
doing this on my own (making changes to the dev branch before pushing
it to the dev server, and then merging those changes to the live
server if they work), and I have already had a lot of duplication of
effort just by myself.

The problem I run into is that the dev branch tends to be pretty
unstable because I have done a little work on a couple different ends,
and then I can't remember which files are actually ready for
production and which ones I am trying out to see if my edits work.

And I know if I have four developers banging away at the dev branch no
one will ever know when it is ready to be pushed to the live server
and which files aren't ready because they are still being tested.

Does anyone have any suggestions? Does it make sense to have a separate
branch for every developer (I doubt it)?  I want to be able to allow
the developers to make changes on the dev site very often, but then I
want the control and confidence pushing changes to the live server
that the files that are going live are the right ones that have been
QA-tested on the dev server.

thanks,
Cory

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

Re: managing svn branches between multiple developers and b/w dev and production servers

[Ryan Schmidt <su...@ryandesign.com>]

On Jan 18, 2007, at 09:54, Cory Forsyth wrote:

> I'm using SVN for a website I'm in charge of developing. I have 4
> developers who are working on the project. I want them to be able to
> test their code before releasing it live (obviously), so I created a
> test server.  My idea was that I would create a branch of the code off
> the main trunk and this is where the developers would make their
> edits, then they would push to the dev server where I could have
> someone do some QA on it, and then if it looks good I could merge it
> up to the main trunk and push it to the live server.
>
> The problem I'm running into, though, is that I don't think SVN is
> really meant to keep two side-by-side branches going.

Sure it is.

> I have been
> doing this on my own (making changes to the dev branch before pushing
> it to the dev server, and then merging those changes to the live
> server if they work), and I have already had a lot of duplication of
> effort just by myself.

Yes, you must merge your change from one place to the other if you  
want it to appear in both places.

> The problem I run into is that the dev branch tends to be pretty
> unstable because I have done a little work on a couple different ends,
> and then I can't remember which files are actually ready for
> production and which ones I am trying out to see if my edits work.

Do not think in terms of *files* which are ready to go live -- think  
in terms of *revisions* a.k.a. changesets. Consider: say I have a  
page that displays some data, and now I want to add an Edit button to  
allow someone to edit that data on a different page. To implement  
this, I need to change some HTML on the display page, maybe add an  
Edit button graphic, and add an edit page and maybe a process data  
page. All of this will be committed in, say, revision 42. Consider  
that someone else makes a different change to the display page,  
something completely unrelated: say, to add a Delete button, and this  
is done in revision 43. For whatever reason, the Edit feature is  
tested and done and ready to go to production, but the Delete feature  
is buggy and can't be released yet. If you think in terms of files,  
you have a problem, because the display page contains both changes,  
one of which you want, and the other which you don't want. Think in  
terms of revisions: the change in revision 42 has been tested, the  
one in 43 hasn't been. So you have your unstable trunk (as someone  
else suggested), and your stable production branch, and so you merge  
the tested revision 42 from the trunk to the production branch, and  
you don't merge revision 43 because it's not ready yet.

> And I know if I have four developers banging away at the dev branch no
> one will ever know when it is ready to be pushed to the live server
> and which files aren't ready because they are still being tested.
>
> Does anyone have any suggestions? Does it make sense to have a  
> separate
> branch for every developer (I doubt it)?  I want to be able to allow
> the developers to make changes on the dev site very often, but then I
> want the control and confidence pushing changes to the live server
> that the files that are going live are the right ones that have been
> QA-tested on the dev server.

Another way to go is called feature branching. Consider that the  
trunk is always known to be good and stable. Any time you want to fix  
a bug or implement a feature, you make a branch first. The fix-bug-39  
branch, say, or the add-the-edit-button branch. You make as many  
edits on this branch as you need. Q&A team can test this branch. Once  
someone decides the fix is good, it can be merged back to the stable  
trunk. Then the feature branch can be deleted, since it's no longer  
needed. So in this way of working, you always know that your trunk is  
good and can be released to production, while any feature branches  
are work that is currently in progress.


-- 

To reply to the mailing list, please use your mailer's Reply To All  
function


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

Re: managing svn branches between multiple developers and b/w dev and production servers

[Dmitri Colebatch <di...@colebatch.com>]

Hi Cory,

There are many ways to solve these problem and I will explan the way
that I would do it (others will no doubt have different opinions).

I would make trunk the unstable development area.  I would assume that
there are two different types of development you might do - a big
change that won't be released for a little while due to the size of
the change, or a little change that is a relatively small change to
the current production website.

Starting with your trunk, when you release to production, lay a tag,
and release that.  You might name this tag website_20070119a.  When
someone from the business requests a change, branch from that tag.
You then checkout that branch, and do your work on that (note that
you're only putting the work that you want to put on prod here).  When
you want to test your changes tag the branch (website_20070119b) and
release it to test.  If you need to make changes, go back to your
branch, make the changes, tag (website_20070119c) and release to test
again.  Once you're happy with your testing, you can then release that
tag to production.  From there you want to merge your changes back to
trunk (so here you're merging the changes from tags/website_20070119a
and tags/website_20070119c - or the tag you deployed to production).

Note that this approach works with mulitple developers working on the
branch, as the changes are grouped by a change request rather than by
who is working on them.

Does this sound like something that would work for you?

cheers
dim

On 1/19/07, Cory Forsyth <co...@gmail.com> wrote:
> Hi,
>
> I was encouraged to post this question to the SVN mailing list.  If
> anyone on this list has suggestions for me I'd be very happy to hear
> them. Thanks.
>
> I'm using SVN for a website I'm in charge of developing. I have 4
> developers who are working on the project. I want them to be able to
> test their code before releasing it live (obviously), so I created a
> test server.  My idea was that I would create a branch of the code off
> the main trunk and this is where the developers would make their
> edits, then they would push to the dev server where I could have
> someone do some QA on it, and then if it looks good I could merge it
> up to the main trunk and push it to the live server.
>
> The problem I'm running into, though, is that I don't think SVN is
> really meant to keep two side-by-side branches going. I have been
> doing this on my own (making changes to the dev branch before pushing
> it to the dev server, and then merging those changes to the live
> server if they work), and I have already had a lot of duplication of
> effort just by myself.
>
> The problem I run into is that the dev branch tends to be pretty
> unstable because I have done a little work on a couple different ends,
> and then I can't remember which files are actually ready for
> production and which ones I am trying out to see if my edits work.
>
> And I know if I have four developers banging away at the dev branch no
> one will ever know when it is ready to be pushed to the live server
> and which files aren't ready because they are still being tested.
>
> Does anyone have any suggestions? Does it make sense to have a separate
> branch for every developer (I doubt it)?  I want to be able to allow
> the developers to make changes on the dev site very often, but then I
> want the control and confidence pushing changes to the live server
> that the files that are going live are the right ones that have been
> QA-tested on the dev server.
>
> thanks,
> Cory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

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