Posts Tagged ‘SVN’

SvnBot 1.1 Released

Friday, February 25th, 2011

The SvnBot is a simple single purpose IRC robot that monitors one or more SVN repositories. When changes are committed to a source repository the robot makes an announcement in an IRC channel. The purpose of the tool is to allow a team of developers to keep up to date on changes that other team members are making. Here at TDL we have a geographically distributed team of software developers some in Austin and Lubbock along with my self in College Station. This is one tool that helps the team keep in sync with each other.

There are already many tools available that do this task [1][2][3], however they all require the use of SVN commit-hooks. Commit-hooks are run on the repository’s server allowing external tools to be notified when specific events occur. Using commit-hooks can work reasonably well if you have access to the server’s configuration, but that is not always the case. Instead of relying on commit-hooks; the SvnBot runs independently, periodically polling the repository for any updates. When an update in found a message will be announced in IRC.

Below is an example IRC message. The message includes the author and their commit message along with some brief statistics about the number of files affected and a URL. If multiple files were affected by a single commit then the url reported is to the common path, i.e. the closest directory that contains all the affected files.

Scott: “SAND-30, reviewed the pom file: removing unneeded dependencies, declaring output to be UTF-8 and added a few comments.(Rev 666: 1 file modified) https://texasdl.jira.com/svn/SAND/svnbot/trunk/pom.xml

Special thanks to the Texas Digital Library, my employer, for allowing me to release this as an open source project.
(more…)

In-place SVN Import

Monday, September 6th, 2010

I discovered an SVN trick today: how to do an in-place import into SVN. Normally when you run “svn import” it will leave the file system alone creating a copy on the repository. Then you have to do an “svn checkout” to pull the files back down under version control.

The import/checkout process normally this is a pain. However there are a few instances where it’s a really big pain such as Unix’s etc/ directory. You can’t just delete etc/ and recheck it out from version control or lots of stuff will break.  The other place I’ve found this usefull is for Xcode when starting new projects. Use the in-place import instead of Apple’s suggestion of creating two projects.

The process is quite simple. First create an empty directory is the repository, then checkout the empty directory into your existing location. Finally, run add the new files and then commit them into the repository.

svn mkdir https://your-svn-repo.com/new/directory/

svn checkout https//your-svn-repo.com/new/directory/  .

svn add *

svn commit –m “Initial in-place import of directory”

HOWTO: Layout Django Apps

Wednesday, July 1st, 2009

The Texas Digital Library has been using the Django framework for a growing number of our smaller projects. Typically, if there’s not already a well established open source solution for the task at hand then the default answer is to write it in Django. Our faculty directory and request systems are already implemented in Django and we are currently refreshing our account management system into the framework. As our use of Django has grown, our practice of storing these projects in the version control repository as one unit has shown its weakness. Within the version control repository, we have passwords, database connections, and file locations stored; in general different settings between production vs development. This makes it hard to keep track of the settings for production vs pre-production and the development instances. This post is my attempt at describe a set of best practices for how to store Django projects in a code repository and deploy them between production and development environments.

Django Applications vs Projects

Django provides tools and concepts to break up your websites into very small components that can be re-used between sites. The first and most basic distinction that needs to be understood is Django’s difference between applications and projects.

A Django Application is a single self-contained set of related features that depends upon the Django framework. By convention, a Django application typically will contain: admin.py, models.py, urls.py, views.py, and other files. These applications should contain no configuration that needs to be changed between installations.

A Django Project is a collection of applications that share a single database configuration, work together in a URL space, and share a common set of application configurations. Projects may contain multiple applications or just one. Django requires that projects have at least three files: manage.py, settings.py, and urls.py. I believe it is best to consider Django Projects like Apache’s httpd.conf.

(more…)