11 Nov 2007
Branching and merging has always been one of the development gotchas regardless of the particular source control system.
Take a typical scenario where you’ve found yourself working on a private branch that has forked off of a release branch which was forked off of the trunk. In an ideal world, the private branch can rather easily pull up any changes made in the release branch and push down after work has been completed. Further to that, it’d be great if the push from release branch to trunk was also a relatively painless operation (the painful part being any real conflicts which no tool can fully automate away from you).
With most SCMs this isn’t that difficult of a problem to solve (I’ve been using subversion for the past couple of years and it’s certainly doable). Complications do arise when you begin having to worry about pulling and pushing certain revisions and tracking change logs between them (ie. what has and has not been merged).
What you don’t want to see happen is an avoidance of branching because of a fear of merges.
If you happen to be using subversion, there’s a nifty python script that makes merge operations (both push and pull) quite painless. It’s called svnmerge.py and it has excellent documentation!
svnmerge.py is a tool for automatic branch management. It allows branch maintainers to merge changes from and to their branch very easily, and automatically records which changes were already merged. This allows displaying an always updated list of changes yet to be merged, and totally prevents merge mistakes (such as merging the same change twice).
A few of us having been experimenting with it over the past couple of weeks with a lot of success. We’ll be rolling it out across our development team in the coming week and early indications are that it’s going to make everyone’s lives a bit easier. The ultimate test will be how developers that may have shied away from merging in the past respond to the tool.
Thanks to Shea for the original pointer to svnmerge.py.
05 Nov 2007
More for personal interest than anything else but I’ve decided to re-write and open-source part of what I worked on for the last hack day.
I’ve called it JDBCSpy and it’s available over on Google Code. It’s worth noting that there are a couple of other projects that also aim to accomplish more or less similar things, notably P6Spy and JAMon. Unfortunately it doesn’t look like P6Spy has had any active development done on it in the past 3 or 4 years. The last time I checked it also had a rather cryptic set of dependencies (that had to be downloaded separately and put on the compilation classpath) and an overly complicated build. Essentially, JDBCSpy aims to provide similar functionality but in an easily packaged driver that exposes information via JMX. There will also be a standalone viewer that can visualize the information as it’s being gathered.
Objective
JDBCSpy aims to provide a lightweight means to obtain statistics at the JDBC driver level.
*Status
*
It currently provides minimal statistics around JDBC Statements and PreparedStatements but functionality is expected to improve over time.
JDBCSpy has been tested using PostgreSQL and hsqldb but should more or less work with any configurable JDBC data source.
*Dependencies
*
There are no run-time dependencies. JDBCSpy has test-time dependencies on TestNG and hsqldb.
*Future Plans
*
* Support for more Statement/PreparedStatement? methods (currently only tracks executeQuery())
* Provide a nice UI for statistics visualization (Currently in progress, a Queries per Second chart has now been committed)
All in all, pretty basic stuff but it’s given me an opportunity to play a bit more with Maven and learn more about JDBC internals. It’s far from production right now but should provide useful foundation for future enhancements.
Note to self: Maven makes life so much simplier. There’s nothing better than: mvn idea:idea
05 Nov 2007
Over the past 4 and a half years I’ve been part of many moves and office re-organizations. From my rather brief experience over the past few years, these activities are done with the goal of creating more available space for desks. It’s rare that they’re done with the goal of improving team efficiencies and reducing barriers to communication.
Until now.
This past weekend the development team went through our second (or fourth depending on who’s counting) office change in the past couple years. We’ve moved away from the typical rows of cubicles and are now in fairly spacious pods of 4 or 5 people. There was even space left over to create a developer lounge with couches, bean bag chairs and a fridge. They’re team-centric so you’ll be sitting with the people that you’re actively on a project with. Hopefully less running across the office trying to track down your QA resource.
I must commend the individuals that planned all of this out and actually made it happen. Today was one of the more productive days I’ve had in awhile and that’s after half of it was spent unpacking. Needless to say it’s amazing what you can get done when you’re in a (quiet) environment conducive to coding.
Even better, now that all the developers are more or less in the same area we’re able to set lighting levels the way we like… which tend to be a bit darker than your typical non-naturally lit offices.
I should also mention that we’re hiring.