In my free time, which seems to be dwindling lately, I have been working on a cross platform dream journal application to aid people with lucid dreaming. If you don't know what lucid dreaming is, head over to ld4all or dreamviews and get yourself caught up. You'll be glad you did. This post is not about the application specifically, as only the core is finished and the user interface is just starting to shape up. The details are for another time.
I'm going to talk about the general structure of the application in case anyone is interested.
I have taken a route that most, if not all software design classes (at least the ones I am familiar with) stress, similar to many other projects. The core functionality of the application is built as a library, and is as coupled as loosely as possible to the user interface. This is of course, partially because I am as of yet undecided of which toolkit to use to implement the interface. However let's pretend that it is all for the sake of good software design ;). I've narrowed it down to the FOX Toolkit, or Ultimate++. Both are well established, free and open source. If anyone has any thoughts of why one is preferable, feel free to share your thoughts.
Sunday, February 24, 2008
Wednesday, February 20, 2008
Distributed Code Management with Mercurial
I've been pretty busy the last few weeks and it will probably remain that way for the foreseeable future. Unfortunately that means my more detailed reviews of different revision control systems will have to be delayed. In the meantime for those interested I'll explain the basics of a workflow I've adopted on a few projects using Mercurial. Please keep in mind that you can use this method with most, if not all, of the current distributed revision control tools.
Since I have more experience with revision control tools than others in my team ("more" being "some"), I decided to set up a repository to help us manage our code and documentation. However, I'm not a fan of leaving my computer on all the time due to little details such as...the electric bill. The workflow we have been using is pretty simple. There is a master repository on my desktop, which is turned on in the evenings. When people make a change to the repository, they create a "bundle" file, and e-mail it to me with a certain subject.
The command in Mercurial is:
hg bundle --base [base revision] -r [end revision] [bundle file]
The desktop monitors the e-mail account for messages with the appropriate subject from a list of approved senders, and checks for the attached bundle file. If it exists, it is downloaded and applied to the repository. Merge conflicts are handled manually as usual. Once the new changes are successfully merged, a new bundle file is created and e-mailed to everyone so they have an up-to-date version of the repository.
While this may sound overly complicated, from a usage standpoint it is pretty simple and works well in practice for small groups of people. There is also the added bonus of enabling people to exchange changes with each other directly without going through the main repository, thus improving the quality of the main code. I agree that giving everyone SSH access to push/pull changes would simplify the process, however that is not an option for us, plus it would be boring ;).
Since I have more experience with revision control tools than others in my team ("more" being "some"), I decided to set up a repository to help us manage our code and documentation. However, I'm not a fan of leaving my computer on all the time due to little details such as...the electric bill. The workflow we have been using is pretty simple. There is a master repository on my desktop, which is turned on in the evenings. When people make a change to the repository, they create a "bundle" file, and e-mail it to me with a certain subject.
The command in Mercurial is:
hg bundle --base [base revision] -r [end revision] [bundle file]
The desktop monitors the e-mail account for messages with the appropriate subject from a list of approved senders, and checks for the attached bundle file. If it exists, it is downloaded and applied to the repository. Merge conflicts are handled manually as usual. Once the new changes are successfully merged, a new bundle file is created and e-mailed to everyone so they have an up-to-date version of the repository.
While this may sound overly complicated, from a usage standpoint it is pretty simple and works well in practice for small groups of people. There is also the added bonus of enabling people to exchange changes with each other directly without going through the main repository, thus improving the quality of the main code. I agree that giving everyone SSH access to push/pull changes would simplify the process, however that is not an option for us, plus it would be boring ;).
Subscribe to:
Posts (Atom)
