At Crowd Favorite we use Subversion for source control and document distribution and management. Last week, we were reminded just how much we rely on it.
We made the move from an outdated server to a more properly equipped one, and also used a more suitable domain and set up SSL and all the stuff we should have had months ago. We also set up Warehouse, which is a nice Rails web front-end for SVN. It also has a very poorly documented installation process and we spent about 12 man hours getting it set up. We still don’t have the permissions working right, but the web interface is very handy and there is more there than you realize at first glance.
In the server move we also lost our SVN commit e-mails for several days, and were having more trouble than we expected getting them set up again (the 4 different server documentation pages we found were wrong or outdated). In the end we just used the mail notifications from Warehouse instead.
SVN is not without its flaws, and I’ve been reading great things about Git and Mercurial recently, and the benefits these systems offer over SVN are compelling. However, SVN has one big benefit over these up and coming systems: existing tools and integrations.
I’ve come to use the SVN integration in Path Finder about half the time now. I also use the SVN integration in BBEdit. Other folks on the team use the integration in TextMate or a standalone tool like SVN X. Still others are waiting for enticing varporware to materialize. The point is, the tools around a system are also important.
I use a desktop computer at home and a laptop at the office and on the road, so SVN is invaluable to me as a synchronization tool as well. Since we have several different SVN repositories, I’ve created some simple scripts to make it easy for me to update all of the repositories and check them all for uncommitted changes. Disclaimer: there’s nothing fancy here, and I’m not a bash guru, so suggestions and improvements are welcome.
Updating
First create a simple script to update all of the repositories (svn-st-all.sh):
#!/bin/sh
svn up ~/src/repo-1
svn up ~/src/repo-2
svn up ~/src/repo-3
Make sure the .sh file has executable file permissions.
Then set up an alias in your .profile so you can call the script with an easy command:
alias svnstall=/path/to/svn-up-all.sh
Checking for Uncommitted Changes
First create a another simple script (svn-st-all.sh):
#!/bin/sh
svn st ~/src/repo-1 > ~/Desktop/svn-status.txt
svn st ~/src/repo-2 >> ~/Desktop/svn-status.txt
svn st ~/src/repo-3 >> ~/Desktop/svn-status.txt
open -a TextMate ~/Desktop/svn-status.txt
This one checks the status of each repository and puts the result in a file, then opens that file in TextMate. Again, make sure the .sh file has executable file permissions.
Now create an alias for this one too:
alias svnupall=/path/to/svn-up-all.sh
Now in your terminal you can type ‘svnupall’ to update all of your repositories, or ‘svnstall’ to check all of your repositories for uncommitted changes.
Hopefully this will help someone else avoid the old “crap, I must have forgotten to check that in from my other machine” situation. 🙂
This post is part of the thread: Version Control – an ongoing story on this site. View the thread timeline for more context on this post.
Thanks for these handy little scripts Alex. As a somewhat reformed GUI-SVN user, I have to say getting a handle on SVN in the terminal makes life much easier. If you’re a designer and you haven’t taken that leap yet, I’d say now’s the time. As part of that process you quickly learn that aliasing in the .profile is a huge help.
I remember the transition myself, glad you’re already seeing the benefits!
You could launch TextMate from the command line just using “mate” instead. So your line: “open -a TextMate ~/Desktop/svn-status.txt” could just be “mate ~/Desktop/svn-status.txt”. If it doesn’t work, then it ln wasn’t made on install of TextMate, and you can fix it with these instructions:
http://macromates.co[...]rom_terminal
Though SVN may not be the most perfect solution, I have definitely come to appreciate it, and version control in general. It saves lives in a very painless way.
Hope its helpful!
[…] SVN Scripts and Tools | alexking.org looks like Crowd Favorite hasn’t gotten the DVCS religion yet (tags: howto svn crowdfavorite subversion dvcs) […]
I have the same functionality to do “svn update” in all repositories, but I’ve made it a little more complex. We create a repository for each project and department in our company and that means more than 20 active repositories. So I find very useful to receive every morning a summary of changes and updates.
Here you have a copy. The idea is just to save the changes in a log file and then mail it to me with a custom format. That way if someone makes a little change in one svn, I can see it next morning.
Interesting, why not just set up SVN e-mail notifications? Perhaps you just want a “digest” of the changes?
Why don’t you set up a local svn repository, which just has a top level root, and put externals in for all of the projects you want to track? One “svn up”, and you’re home.
Ooh, that’s clever.
I would have thought that this would work:
svn st ~/src/repo-[123]
At least, I have been able to run ‘svn status’ with more than one working copy listed on the command line when they were all from the one repository; I don’t know if there is some special rule saying that you can’t do this if they are from different repositories.
Also, given that Alex mentioned e-mail notifications, let’s not forget that Warehouse (and also other web front-ends such as WebSVN) allow you to subscribe using RSS. I haven’t used this myself but one of my co-workers tracks changes this way.
Exactly, Alex, I prefer a digest of all changes than a message per commit. And if I’m on a trip, I just want the digest when I switch on my laptop.
Jose, we also thought in something like the solution you propose. But we have the feeling that something like that would make our repository huge and every day the percentage of relevant information would decrease. And, although I know permissions per directory are possible, we like how simple permissions to developers based on repositories are.
But, anyway, this is just my solution. Not a perfect one at all. 🙂