Archive for the ‘Subversion’ Category

SVN status on branch

May 4th, 2009 No comments

I was trying to figure out what had changed since I branched. You can diff changes between versions, but you cannot run status on the difference between changes.

A simple workaround to get something that works like status is to run diff and then just print out those lines that start with “Index”. You need two things to do this:

1) The branch revision number: You need the revision number of the revision that created the branch. You can find this by using “svn log –stop-on-copy” from within the branch.
2) The URL of the branch. If you run “svn info” on the branch you can get this address.

svn diff -r <branch num>:HEAD http://<repo_url>/branches/<name of branch> | grep "^Index"

By the way, the most natural way to do this within subversion, is to first merge and then run status. Run the following code from within trunk:
svn merge -r <branch num>:HEAD http://<repo_url>/branches/<name of branch>"
svn st

Which is a bit much if you don’t want to merge yet.

Categories: Subversion Tags:

SVN branching

April 29th, 2009 1 comment

I’ll preface this post by mentioning that the steps for branching are already out there on the web. I’m more concerned here with the complexities in setting up a branch in SVN, and then move onto showing how to do the same thing in git. Branching discussed on other sites:
- svn book
- stackoverflow “How do I create a branch in SVN”

The actual command looks as such:
svn copy

As you’ll notice if you look at the subversion command above, the action of branching is not really a staple of subversion. Essentially you’re taking the codebase as of a certain version, copying the entire trunk and placing it in a new home to work with. This process can be quite aggravating, and unless necessary I really try avoiding it.

At a TechTalk on git, Linus Torvalds actually talks at length about this:

If you do brave the current in SVN, just keep in mind that the longer you’re branch is disconnected from trunk, the more merging fun you will have to deal with.

Another thing I’d recommend is removing any branches as soon as you work the changes back into trunk. There’s really no reason for branches to just sit around.

As a tool though, the only time I’d really use a branch in SVN world, is when I’m touching lots of different parts of a system and I just need further testing before bringing my changes to trunk. For the casual change, I’d rather just not deal with that. A better idea is to setup a local repo of some sort and just work off that.


I was curious to see what git was all about. Being an avid Linux user, I can’t say that Linus has led me astray in the past… Also, to see if the branching really did make more sense in that world. I must say that it’s unbelievable. And as Linus said, git really does get you to interact differently with your repository. Because branching is done so well and you switch contexts so easily, I can see myself making branches A LOT more often. How it works is you create a branch and that branch kind of happens in the background. To actually view the branch you have to switch contexts, by calling the git checkout command. Once in that context there’s no drilling down to different branch directories. When you checkout the branch, you’re already in the branch and any changes stay in the branch. Then merging and deleting the branch are also very easy to do. It’s really quite impressive in a, yes that’s how it should be kind of way.

Right now, with subversion, I resist branching unless absolutely necessary. In SVN, it costs a lot (space) to branch, it’s very slow, it’s a pain to setup, and it’s tough to merge back.

And here is what it looks like in git (main tutorial)

Initializing a project (run these command within directory of project)
$ git init
$ git add .
$ git commit -m "Initial test"

Editing a file
$ vi modify_some_file
$ git add modify_some_file
$ git commit -m "Test"

Ok, now back to the topic of merging.
Create the branch and check it out. (‘git branch’ shows you which branch is the active branch)
$ git branch
$ git branch new_branch
$ git branch
$ git checkout new_branch
$ git branch

Edit a file
$ vi perl.txt
$ git commit -a -m "Expermintal test"

Change context to main branch (master)
$ git checkout master
$ less perl.txt

Merge new branch
$ git merge new_branch
$ less perl.txt

Delete the branch
$ git branch -d new_branch

Categories: git, Subversion Tags:

Ignore Python bytecode files in svn

April 27th, 2009 No comments

When loading up subversion’s status command it is quite annoying to get a list of files with the extension “pyc” in the list of files to look through. What you can do is setup rules within subversion to ignore these files. Subversion calls these settings “properties” and you can add them to different levels of your files (which actually can be confusing). What happened in my situation is that one of the folders I was working on did not have this value set, so that folder’s bytecode files were showing up but not any of the others.

The command is pretty simple:
svn propset svn:ignore "*.pyc" folder_name/

To view those properties that are set to a folder simply do:
svn proplist folder_name/

To delete the “svn:ignore” property do:
svn propdel svn:ignore folder_name/

Categories: Python, Subversion Tags:

SVN import

August 5th, 2008 1 comment

Every once in a while I end up starting a project, and since it happens so infrequently I always forget the steps to set things up in subversion.

I won’t go through all the steps you need to start from scratch with subversion, but here’s the important part about adding a project to your repo.

svn import <path to project> file:///<path to svn root>/<project folder> -m "Initial import"

svn import /home/PROJ file:///home/svn/PROJ -m "Initial import"

import: This adds a directory tree to your

path to project: Actual path to directory tree where code sits

path to svn root: Path to repo

project folder: Name for project folder in svn

The one thing I’m not sure how to do right now is after I import the project. The folder with the code is not a subversion checkout. So what I usually end up doing is checking out the project and replacing the checked out version over my original code. Not sure if there’s a better way to do that…

Categories: Subversion Tags:

Subversion – ‘No repository found’ error

March 20th, 2008 2 comments

I was getting a “No repository found in” error which was a result of starting up subversion wrong. Even if you’re in the directory where svn resides you need to call the “-r” option on “svnserve”

svnserve -d -r svn

Another problem I ran into was that my user needed permission to change the files from Ubuntu. To aleviate that run:

sudo chown -R user home-directory/

Categories: Subversion, Ubuntu Tags: