Thanks Bill.
I like suggestion #1. I read the SVN merge docs that warn against merging
the HEAD of the trunk into the HEAD of a branch because it will capture the
removal of changes that never happened in the branch.
That's a valid argument, except that it also doesn't remove changes that
*should* have happened. In other words, maybe some of those trunk removals
DO belong in your branch. Since you can't know without human intervention,
it makes a good case for never doing an automated merge. I can see a need to
selectively merge changes between branches to catch incompatible changes to
dependencies.
Don't get me wrong; I like merging, I'm just not sure how I feel about
automated merging. I'm coming from the checkout-edit-checkin world. The
consensus in the edit-merge-commit world seems to be that automated merging
is more reliable than it sounds, but this is usually said in the context of
file merges, not entire branch merges. Would you agree that it still holds
true for branch merges?
If one doesn't like automated merging, or if developers can't be bothered to
track revision numbers for merge deltas, then the best practice is #4:
4) At the beginning of each session, developers pull the HEAD snapshot of
the trunk and run a visual merge into the HEAD of their branch. During QA,
the opposite happens: the QA manager runs a visual merge between the HEAD of
the branch into the HEAD of the trunk.
Does anyone know of an SVN client with a manual branch merge feature?
Ben
-----Original Message-----
From: William Nagel [mailto:bill@stagelogic.com]
Sent: Tuesday, February 01, 2005 10:28 AM
To: Benjamin C. Allfree
Cc: users@subversion.tigris.org
Subject: Re: Howto: using SVN for QA?
> I would like my developers to commit to private sandboxes so I can
> review changes before committing them back into the trunk. Does anyone
> know of a good way to do this?
Sure. Give each developer their own branch of the project. Once their
changes have been reviewed, use "svn merge" to merge them into the
trunk.
If you do that, though, you need some policy for keeping each branch
up-to-date with changes from other developers. I can think of a couple
of ways for you to go about that:
1) Have each developer periodically merge changes from the trunk into
the branch themselves. The upside to this is a low burden on you.
Also, the people doing the merges are the people most familiar with the
branch they are working on and any local changes they've made. The
downside here is that developers forget to do repetitive things like
this.
2) Perform the merges yourself at the same time you merge from the
private branches into the trunk. The upside to this is that it's less
prone to getting forgotten. The downside is that it will be labor
intensive/time consuming for you. (You may be able to automate some of
the process, though)
3) Give each developer a fresh branch of the trunk periodically. You
could do this after every time you merge their changes into the trunk,
or on a timetable. The upside to this is that it's much less labor
intensive than the merge (and more easily automated), while still
allowing you to do it yourself to guard against forgetful programmers
working on outdated code. The downside is that unmerged local changes
on the branch won't carry over from one branch to the other, so you'll
need to make sure that any local changes on the old branch are merged
into the trunk first (you won't lose those changes, but they'll be on a
different branch than the one the developer should be working on). Of
course, you could leave it up to the developer to merge any local
changes from their old branch to the new branch. When the branch
change occurs, the developers would have to use "svn switch" to change
their working copies, unless you delete the old branch and add the new
branch under the same name.
-Bill Nagel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 2 14:54:45 2005