Category: SVN

Circuit Maker

Circuit Maker is about to become an active project again, instead of a mere passing reference. What is Circuit Maker? It makes Fusebox circuits automatically. Given some simple settings, it creates Model, View, and Controller for a given entity in your Fusebox program. The concept is similar to Ruby’s scaffolding, except for two things. First, it wasn’t developed by Ruby developers so it’s not the same. Second, it doesn’t (yet!) model itself based on the contents of the database. One of the great things about it, though, is that it abides by a very organized structure and set of best practices which help application developers develop faster and better.

So tonight, I loaded up the svn dump to a new repository. It wasn’t easy though, because Circuit Maker used to be in a repository along with a bunch of other projects. As I found out, SVN does not have a feature which allows the user to split, or separate, a repository into more than one repository. Instead, the SVN dump file has to be run through svndumpfilter to remove irrelevant paths, and then it must be hand-edited to correct unwanted paths or changes in path structure (moves or renames to the directory containing the code). It turned out to be easier than I expected, but that was partly because CircuitMaker does not yet contain any octet-encoded files. This guy had worse luck.

Now that we have a workable repository, it is on! Roy and I are pretty excited to finally get this thing out there in the Fusebox community where it belongs. In a way, we’ll hopefully beat Fusebox to the punch when it comes to this kind of thing. There has never been a free/open source tool which is as sexy as this, and all Fusebox has is an inactive Trac page and some ColdFusion code. But if they do get something together, it might lead to some interesting fusion of concepts between Circuit Maker and it.

That’s all. Have a good weekend.

SVN – maintaining code history through reorganization

The following is some advice I’ve given to my student programmers from time to time:

Occasionally, you may need to split up a file in one of your projects into more than one file. Or, you may need to combine two pieces of similar code into one reuseable piece of code. This kind of code refactoring happens all the time, but unless you are careful you may be losing valuable revision history behind those lines of code.

For example, if you split a file into two files you may cut the code from an existing file, and then paste it into a new file. You would then add the new file to your working copy and commit it. In doing so, you would have lost the revision history of those cut & pasted lines.

To get around this issue, instead use SVN to make a copy of the versioned file you wish to split up. If you are using Tortoise SVN, this would be a right-click drag and a “SVN copy and rename versioned files here…” Then, you can remove the appropriate lines from both files and commit. The revision history of all of your lines will still remain!

Unfortunately, the act of merging near-duplicate code into a single file is not as graceful. Instead, you must pick the file closest to the generic end-result (or the file with the biggest history) and modify it to be generic. To avoid losing some of the history, you should note in the commit log what files you are consolidating.