[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feature branch merging by trunk replacement question...

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-04-15 20:34:00 CEST

On Apr 15, 2005, at 9:54 AM, K. Richard Pixley wrote:

> Question: If feature branch "A" and the trunk are identical at time
> T=2, including ancestry of all copied files, then why bother? I mean,
> wouldn't it be much, much simply at T=1 to simply remove the trunk and
> replace it with a copy of feature branch "A"? For that matter, the
> only reason for the copy to trunk is to rename it. We could just as
> easily drop the old "trunk" and simply declare feature branch "A" to
> be the new trunk, couldn't we?

Yep, that would work.

But remember that it's often the case that dozens of people have
working copies of the trunk. It's extremely unfriendly to delete trunk
and replace it with a new directory. It means when everyone runs 'svn
up', they'll get errors about how the server is trying to delete the
whole working-copy... which libsvn_wc can't handle.

For reference, though, this is exactly how we did the 5-month long
"locking" branch in subversion for 1.2. Locks were developed on the
branch, and once a week we would diligently merge the latest trunk
changes into the branch. Then at the very end, we compared trunk@HEAD
with branch@HEAD, and merged the resulting patch into a trunk working
copy. I don't think that's really much harder than remotely destroying
the trunk URL and moving the branch URL to trunk.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 15 20:37:14 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.