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

RE: Re: Making a branch the new trunk

From: Gale, David <David.Gale_at_Hypertherm.com>
Date: 2006-06-09 17:49:52 CEST

urs@isnogud.escape.de wrote:
> "Gale, David" <David.Gale@Hypertherm.com> writes:
>> That said, a better option is to use merge:
>> # svn co trunk
>> # cd trunk
>> # svn merge trunk branch .
>> # svn ci -m "Replaced trunk with branch"
> But I did check out the whole repository, and tried
> $ rm -rf TEST/
> $ svn co -q file://$HOME/SVN/TEST
> $ cd TEST
> $ ls
> branches tags trunk
> $ svn merge trunk branches/ut trunk
> svn: A working copy merge source needs an explicit revision

This makes sense, and points out how I wasn't clear in my original post.
My intent was that you would not checkout the entire repository, but
just the trunk, so it would be:

$ svn co -q file://$HOME/SVN/TEST/trunk
$ cd trunk
$ svn merge file://$HOME/SVN/TEST/trunk
file://$HOME/SVN/TEST/branches/ut .

(Apologies if my mail system wraps that third line.) The merge command
is intended to apply the difference between revisions on a branch to the
trunk (or vice-versa), but can also be used to replace one with another.
The intent (I believe) is that, if you're working on a branch/trunk
merge, you would specify at least one path to the repository; if you're
merging entirely within a working copy, you probably want specific
revision numbers (other than BASE), such as for a reverse merge; the
client requires you to be explicit in order to protect you from

> Also, the reason I wanted to avoid merge and instead use remove and
> move, is that I thought the log message would state more clearly what
> has been done. No I get
> $ svn log -v -r6
> r6 | urs | 2006-06-09 15:13:01 +0200 (Fri, 09 Jun 2006) | 2 lines
> Changed paths: M /trunk/a M /trunk/b D /trunk/c A /trunk/d (from
> /branches/ut/d:5)
> replace trunk with branch ut.
> instead of something similar like
> D /trunk
> A /trunk (from: /branches/ut:5)
> D /branches/ut
> which I would prefer.

With the merge, you're explicitly *not* deleting the trunk and re-adding
it; you're modifying the contained files, by applying the difference
between the two sources of the merge. So the first log message is
correct. (It's also more accurate, since there may well be files that
don't need to be changed, etc.)

Incidentally, I tried checking out the entire repository, deleting
trunk, and replacing it with a branch. It turns out that you have to do
this in two commits (one to rm, one to mv); if you try to do them both
at the same time, you get "svn: Cannot copy to 'trunk' as it is
scheduled for deletion". However, existing working copies of trunk will
update to the new trunk after the second commit, so that worry
disappears. So, both options work; I still think the merge is safer,
since there's no window where you don't have a trunk.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 9 17:51:15 2006

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.