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 <cory.forsyth@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
Received on Thu Jan 18 20:43:20 2007