Here’s a quick SVN trick I use for managing my svn:ignore and svn:externals properties for my projects.
One of the first things I do for newly checked out projects is to add a externals.txt and ignore.txt files. Then I just populate these with the property values I require for the project.
I know, it’s a no brainer when you think about it right?
The thing is, I didn’t think of doing it until the past few projects and actually had to rely on ide integrated / gui tools to do it prior to this year. I came across a couple of examples and did it a couple of times in a rush without noting it down, but thought I’d make a post about it on my blog so that I have somehwere easy to find.
Here’s a quick example:
example contents of externals.txt
library/Zend http://framework.zend.com/svn/framework/standard/tags/release-1.10.4/library/Zend
library/ZendX http://framework.zend.com/svn/framework/standard/tags/release-1.10.4/extras/library/ZendX/
library/Doctrine http://svn.doctrine-project.org/tags/1.2.2/lib/Doctrine
externals/dojo http://svn.dojotoolkit.org/src/branches/1.4
nbproject
example contents of ignore.txt
public/webalizer
public/analog
Then I use the -F arguement to specify that I want to use the contents of a file to specify the value or values of the property.
$ svn propset svn:ignore -F ignore.txt . to set my svn:ignore property values.
or
$ svn propset svn:externals -F externals.txt . to set my svn:externals property values.
It’s all about convenience baby!
This makes svn properties management very convenient. It’s one of the things that make it easier for me to set things up. What’s more, when I need to add or remove to/from svn:externals or svn:ignore, I can do so easily – managing my svn properties this way, I also have a good reference as to what my property values are without having to run a number of svn propgets via command line.
No related posts.


Committing the *.txt unfortunately only provides the illusion that you know the actual property values…classical violation of ‘don’t repeat yourself’/'store in one place’.
For keeping a reference setting, I’ve come to find gist.github.com rather practical.
wow, I gotta be honest, I’ve not drilled down and thought about it to the point where I am suggesting storing and maintaining two records of the same data.
Good point though.
It works for me as I work on a single dev team, but I can see this approach being a pain when you have to work with others who don’t care for the txt file property storage approach.
Thanks for Sharing rvdavid! Nothing place that i could write a comment bfore i read it first.. eventhough i’m not really understand bout programing..I enjoyed being here:)
Glad you enjoyed the post – if you ever need to learn, I’m always happy to teach
(although some of the lessons may not be as great as I had first thought
)