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

Re: Help with Subversion semantics.

From: Hari Kodungallur <hkodungallur_at_gmail.com>
Date: 2007-09-12 21:02:20 CEST

On 9/12/07, Marc.Farrow <marc.farrow@gmail.com> wrote:

> I have a few questions. They deal with the correct way to invoke SVN
> commands. I will set up a scenario and that scenario will be used in both
> situations and questions.
> Let's say I have two copies of a project in a Subversion repository. One
> is
> the trunk and the other is branch1. Branch1 is a copy of trunk at a
> certain
> revision; let's say revision A. I make lots and lots of changes to
> working
> copy that is pointing to Branch1 and I commit all those changes to
> Branch1.
> I delete the working copy. Let's say while I am working on the changes in
> Branch1, someone else comes along and checks out the trunk and makes some
> changes in one or more files that I have changed in Branch1 and commits
> them. These changes "should" cause a conflict when merged. I come
> along
> a few days later and check out Branch1 again.
> 1) I want to merge the changes with the trunk into my "new" working copy
> of
> Branch1. I expect a conflict. Here is the command I want to use. Would
> this be the correct command? (I am in my current working directory in my
> shell).
> svn merge -r HEAD http://repository/repos/project/trunk .

I believe you should be using "svn merge -r <FROM_REV>:HEAD
http://repository/repos/project/trunk ."
The FROM_REV here is the the revision from which you want to merge the
changes. In this case looks like it is the revision where you created

If I don't specify the FROM_REV, it gives me the following error:
  svn: Second revision required

I have not used SVNKit to know how it works without the second revision. But
using svn command line client, it should fail.

> p.s. I know that the above command does seem to work as I expect using
> command line, but using SVNKit it does not. I have already posted a
> message
> on their board about it, but I feel the problem may not be SVNKit, but my
> understanding of the merge paramters.
> 2) Pertaining to merging.. How do I know when I need to specify a specific
> revision number (as I will not always know it) and when I can use BASE or
> HEAD? What exactly does HEAD and BASE mean in relation to both remote
> URLs
> and local working copies? In every case that we currently use, I always
> want to merge the latest "fully committed" changes from one copy to the
> latest "fully committed" changes to a remote copy (i.e. URL). Is HEAD the
> correct keyword? Should I be merging from HEAD of the remote copy (URL)
> to
> the HEAD of the working copy?

Typically, if you want to merge all changes, then you would merge from the
time the branch was created to the HEAD. Say you created the branch at
revision 100. And the latest committed revision on trunk is 200. If you want
to merge all changes in the trunk to the branch, you would do:

svn merge -r 100:200 <trunk-url> <branch-working-copy-path>

Note that as time goes by, you will want to do more merges, say between
revisions 201 and 300. Currently there is no merge tracking in Subversion --
that is it does not remeber the fact that you already merged 100:200. And
so, to avoid merging the same changesets, you will have to remember that you
merged 100:200 and consequently specify the revisions 201:300 in the command
line. For this to happen, when you do the original merge (100:200), you will
want to document that fact in the commit log message.

Or to avoid some of these, you might want to take advantage of the
svnmerge.py script that comes along with the subversion distribution. This
script automates some of the above.

Merge tracking itself is a work in progress in subversion --
Some of the svnmerge.py functionality will be available in version 1.5. And
a full functionality expected in a subsequent version.

-Hari Kodungallur
Received on Wed Sep 12 23:54:41 2007

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.