Another self reminder (memo!) for the Subversion. Let’s say that you got two different code bases that are dependent to each other. What you need is to version them differently but you also want to development to work as smooth as possible using the cutting edge version (saying trunk).
What you need is to define an svn externals property to your current base:
svn propset svn:externals 'XXX https://svn.roysimkes.net/my-dependent-prj/path/to/dependency/folder/XXX' .
The trick is to use the single quotes and the dot in the end. As you are setting a property, any space you will put will break the setting. You have to put a dot at the end to indicate that you are changing the properties of the current folder.
This way you are adding a folder named XXX which is linked to the code repository’s XXX folder. Every time you use “svn up” both the code bases will be updated. Every time you commit, only the current repository will be committed. And if you need to commit to the external library, go to that folder, and when you commit external’s library will be committed too!
I’m sure that I will be forgetting the command again, so this way I know where to look.
Yet another self reminder to myself about subversion commands.
It’s possible that the location of your svn repository has changed. And you were not aware of it and when you have checked in you encountered an:
svn: PROPFIND request failed on '/codebase/trunk'
svn: PROPFIND of '/codebase/trunk': Could not resolve hostname `svn.oldcodebaseurl.com': Host not found (https://svn.oldcodebaseurl.com)
Remember that you don’t have to manually check out again and do your changes to it. It’s a painful experience if you have lots of repository you are working on or if the repo you have checkout has has pretty big on size.
All you have to do is to relocate your svn url with this command:
svn sw --relocate https://svn.oldcodebaseurl.com/codebase https://svn.newcodebaseurl.com/codebase
As a self reminder, you can count on that I have encountered it, felt the pain and found the painkiller :)
Yet another self reminder about subversion tricks. If you are using subversion, this means you need to keep track of the changes you have done to a text file and this changes are important to you and you may want to get back to the revision you want anytime you want and you may easily commit it as a new revision. But actually you can’t.
At least not that easily. The thing you should is to merge the current revision with the revision you want to get back. And by this I mean, you are applying the patches done till that revision from backwards. If you have add something, the patch automatically removes the thing that is added. It does the thing you are doing manually automatically.
Here is the shell script:
svn merge http://my.svn.com/mycodebase/trunk/myfile.php@HEAD http://my.svn.com/mycodebase/trunk/myfile.php@51 .myfile.php
51 here means the revision you want to get back. Remember that changes are done on your working copy and they are not committed to the repository. Instead of a file you may use a folder too.
Or You may want to try something like this too:
svn diff -r HEAD:51 myfile.php > backwards.patch
patch -p0 < backwards.patch --dry-run
patch -p0 < backwards.patch
Bacisally that's what the merge operation does. Second command is not necessary but you might want to try out how the changes will affect your files without damaging your working copy.
This part is a self reminder more than an actual blog :)
First you got to understand that svn does not have an ignore command. so you can’t use something like:
svn ignore tmp/*
It does not actually suit subversion anyway. If you add it to the repository you have to want to check it’s changes, else don’t add them to the repository.
But there are cases which is important. If you have a tmp/ folder in your repo and you don’t have any files in it. But as this is a tmp folder and you could add caches and other things there will lots of ‘?’ with an svn status command.
To solve this issue you can set an ignore property to the files like this:
svn propset svn:ignore * tmp/*
the above command means this: second argument tmp/* means every file or folder under the tmp folder. so you will include everything under your folder. But this is not simply enough. and the first argument “*” comes in here. This one works as a wildcard (like always) and means everything! So the statement tells to ignore all the files and folder under tmp folder.
That’s it. As I said, as my previous subversion entry this is again a self reminder :)
That’s some of the things I started to encounter a lot about this thing. A diff without whitespaces. It creates a big confusion to understand and review the patch. So I searched a bit. I had used it once a time, but was forgeting a lot. That’s a post a to remember it anyway :)
By using an external diff tool you can take a whitespace ignored diff by using:
svn diff --diff-cmd diff -x -uwBEb
There is a double “-” before diff-cmd but it looks like as a one I don’t know why.
This command will use the unix system’s diff command with arguments -uwBeb which has something to do white ignoring all type of white spaces.
Well during my research I have found out even the external diff programs were available to use, in the Subversion‘s core libraries this option was available. This enhancement had been checked in some time ago and was intended to be added to 1.4.6 or something like that. 1.5 had came anyway but it seems that it doesn’t quite really works. At least I was not able to find something useful the -w was still ignored! But somehow I was able to take a whitespace ignored diff via TortoiseSVN. I’m not yet sure if this is an external ability it does use an svn diff’s core ability or not. I assume that it had something to do with merge and blame commands. Perhaps there is a trick I don’t know that by using these commands you can take a white space ignored diff