subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Schmidt <>
Subject Re: upgrading source code in local repository
Date Wed, 03 Aug 2011 04:10:08 GMT

On Aug 1, 2011, at 05:31, Ulrich Eckhardt wrote:

> On Friday 29 July 2011, Brecht Ameije wrote:
>> I read the referred page in the book, indeed: the script
>> is exactly what I need. It implements the steps that I did by hand.
> There is one thing that took me a while to understand when starting to use 
> that: This doesn't preserve your local changes. Instead, after uploading a new 
> upstream version, you have to apply your local changes again. Merging helps 
> though.

I think perhaps you still misunderstand. Correct, does not preserve your
local changes. That's not its job. You never run on directories or parts
of the repository that contain any changes. You only run them on pristine copies of the vendor


svn mkdir $URL/vendor

/vendor in the repository will contain copies of all the third-party software you want to
keep track of. You will never make your own changes to that code in this part of the repository.
These will always represent exact copies of the upstream source.

Let's say you want to keep track of a third-party software called foo. It's currently at version
1.1. You download the tarball of version 1.1 and you import it into the repository at this

svn mkdir $URL/vendor/foo
svn import /path/to/foo-1.1 $URL/vendor/foo/current

"current" is analogous to the "trunk" of a project that you're developing, but it's not called
"trunk" here because "trunk" is a place where you make changes, and you're not going to be
making any changes here.

Now you make a copy of current and call it 1.1:

svn cp $URL/vendor/foo/current $URL/vendor/foo/1.1

This is like a "tag" in a project that you're developing.

Finally, you copy version 1.1 into another location in the repository where you want to use
it. Let's say that foo will be used inside a project you're developing called bar, so perhaps
you run:

svn cp $URL/vendor/foo/1.1 $URL/bar/trunk/libs/foo

Now you have a copy of foo 1.1 in the libs directory in the trunk of your bar project. You
can edit that copy of foo to your heart's content.

Next, imagine a new version 1.2 of foo is released and you want to upgrade the foo in the
bar project to that verison.

So you download the tarball of foo 1.2 and use to update $URL/vendor/foo/current
to version 1.2. will also copy that to $URL/vendor/foo/1.2 for you if you
ask it to.

Now you can go into your working copy of bar/trunk/libs/foo and run:

svn merge $URL/vendor/foo/1.1 $URL/vendor/foo/1.2 .

That is: You ask subversion to apply changes that occurred between foo 1.1 and 1.2 to your
existing (and possibly modified) copy of foo 1.1. You commit it, stating in the message that
you updated it to 1.2. Done.

>> Running /usr/bin/svn add -N --targets
>> /tmp/svn_load_dirs_W1GIx88wmF/targets.00001
>> /usr/bin/ /usr/bin/svn add -N --targets
>> /tmp/svn_load_dirs_W1GIx88wmF/targets.00001 failed with this output:
>> svn: warning: 'TODO_unicode@' not found
>> svn: warning: 'include/ar.h@' not found
> The at sign has a special meaning in SVN URL, it is used for peg revisions. 
> Question is, are there files with a trailing at sign in the tree that you want 
> to import? If yes, they are not handled correctly. If not, wrong filenames 
> have been generated at some point. It is probably a bug either in the import 
> script or SVN itself.
>> The 'not found' files, are actually the files that are added in the new
>> vendor version.
> Those with the trailing "@"?

Correct, the @ sign has special meaning in subversion. If a filename has an @ in it, subversion
will think you are asking for that special meaning and will probably not do what you meant.
To work around that, you append an @ to the end of the filename. That is what the script is
probably doing here and why you are seeing "@" at the end of each filename. It is not a bug;
it is a feature of subversion, and a feature of that it is trying to handle
all filenames correctly for you, even those containing an @.

This does not explain why it failed for you though. 

View raw message