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
Received on Thu Jan 18 21:56:56 2007