Re: upgrading source code in local repository

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 svn_load_dirs.pl
>> 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, svn_load_dirs.pl does not preserve your local changes. That's not its job. You never run svn_load_dirs.pl on directories or parts of the repository that contain any changes. You only run them on pristine copies of the vendor software.

Example:

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 path:

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 svn_load_dirs.pl to update $URL/vendor/foo/current to version 1.2. svn_load_dirs.pl 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/svn_load_dirs.pl: /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 svn_load_dirs.pl 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.
Received on 2011-08-03 06:11:12 CEST