Thursday, September 20, 2007

Sharing Xvnc sessions

We're a pretty diverse group at the RDU erlouge even though we haven't reached the point where we actually need a formal venue for our meetups. We're still bumming it out in cafes with free WiFi. Likewise we don't have a projector or anything for presenting our code. The easiest and most cross platform way to achieve pretty much the same result as a projector was to use VNC.

Here's what I do on Fedora 7:
#'s denotes root shell
$ means your normal unprivileged user

# yum install vnc-server vnc
$ vncserver :1 -depth 24 -geometry 1024x768 -AlwaysShared

Most of those arguments do not need any further explanation so I'll be brief. That command starts a server on display :1 (port 5901) and sets all the connections to shared. That's a nice flag to set (read the Xvnc manpage for more options) since we were having problems with people forgetting to specify a shared connection on the client side and thus disconnecting everything.

VNC is not the most efficient remote desktop protocol but it gets the job done. If a large group of people are connecting and bandwidth is limited you may try a few things to reduce the amount of bits that have to fly around. I like to use a lighter weight window manager. You can edit your ~/.vnc/xstartup and put in something like this:

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
fluxbox &

Obviously the first to lines are boilerplate.

If you are ever in a situation where you don't feel like the wireless network you are on is safe I would recommend tunneling your VNC traffic through SSH. I don't think any VNC servers advertise their security and the traffic definitely isn't encrypted. Just give everyone who you want allow access to your machine an account then have them log in as follows:

$ ssh -N -T -L 5901:[VNC server ip address]:5901 &

That creates the tunnel. Then just tell the users to connect to their local point (which forwards to the host)

$ vncviewer -ViewOnly -Shared localhost:5901

NOTE: The '-Shared' option is only really needed if you are connecting to a server that doesn't enforce sharing.

Wednesday, September 19, 2007

Using git to cope with crazed svn repositories

If you ever find yourself working with a gnarly svn repo you may want to give git-svn a try. You will be able to do your collaboration with git and then dump your changes back to svn. The truth is many large projects are not yet ready to ditch svn completely and there may exist tooling already for svn that your team needs (and doesn't have time to rewrite). For this reason exists git-svn.

Initialize your svn aware git repository:
mkdir mywork; cd mywork
git svn init http://workserver.com/path/to/the/code/you/care/about
git svn fetch -r [revision you care about]

The reason I'm encouraging you to only grab the code you care about is because if you are working with a truly crazed svn repository things can get unnecessarily complex. When I did a full svn import of the root on the svn repo where I work it took over 3 days to finish on a good connection. The truth is there was only one branch that I really cared about.

If you are working on a more complex project and having to deal with other groups that are using svn you may have to do a slightly more sophisticated initialization:

git svn init https://workserver.com -T path/to/the/repo/you/want/to/commit/to -b dir/that/has/branches/of/other/teams

The main thing to understand is that git-svn provides two-way communication between git and only one branch in svn. The path you specify for '-T' needs to be that one branch. It doesn't actually need to be the real trunk from svn's point on view--it's just the particular path you care about.

Once you have initialized your repo you will need to do some fetching. Again, you don't want to fetch more than you need. One thing that was not intuitive for me was how the fetch works. I immediately tried to check the latest revision and nothing was getting pulled down. The trick is to pull down revision that actually have commits. Use 'svn info' to find out the last revision where a particular path was changed. You will need to do this for your 'trunk' and any other branch you care about.

Tags

my google reader feed