With Tailor you can:

1. Create a local repository using your favorite source control system of a project managed by another source control system.
2. Do your work.
3. Export your changes back to the original repository.

Here’s an example of using Tailor to import a branch of Axiom (uses Subversion) into a local darcs repository:

First of all, we create a configuration file for the project

$ tailor –verbose –source-kind svn –target-kind darcs \
–source-repository https://svn.sourceforge.net/svnroot/axiom \
–source-module branches/build-improvements \
–start-revision INITIAL \
–target-repository file:///home/rwx/lab/math/axiom/axiom-darcs/ \
–target-module axiom-build-improvements axiom-build-improvements \
> axiom-build-improvements.tailor

Now that we have the config file stored in axiom-build-improvements.tailor, we can launch the tool to do the initial import

$ tailor –configfile=axiom-build-improvements.tailor

After a while, we have a local darcs repository for that branch and we can write:

$ darcs get ~/lab/math/axiom/axiom-darcs

to get a working copy in which to do your modifications.

Today, there are a myriad of SCM tools available and projects like Tailor will become increasingly important because they let you stick to your tools of choice. In this way, instead of learning the details of other source control systems, you can focus on what you do best: writing code.

Halberd has been tested in real world scenarios for quite some time and it seems to be solid. I hope the wider audience it is gaining now will uncover some bugs and after fixing those I’ll think of it as stable software. Future work could happen in the following areas:

• Clustering algorithm
• The module Halberd.clues.analysis currently implements an ad-hoc hierarchical clustering algorithm to isolate possible real servers. I would like halberd to report to the user the degree of trust he should place in its conclusions.
• I think the way to go would be to test some algorithms in R (fuzzy clustering comes to mind) using real world data and see what works best before implementing anything.
• SSL session reuse
• When an SSL/TLS session begins, the server issues an SSL session ID to the client. This ID will be used to resume transactions between client and server (remember the stateless nature of HTTP).
• Some load balancers can keep track of which real server dealt with which SSL session and direct the client to the right server (the one having the client’s session ID in its cache). This could be used by halberd as an extra technique to enumerate real servers.
• Test suite improvements
• The test harness is tied to my own development environment. This should change.
• More tests never hurt.

You can be use halberd as a stand-alone command or as a Python module to be imported by other software.

Here it is for your enjoyment.

Even with unit testing, it’s really hard to track dependencies like this. We would need code coverage tools and exhaustive tests, neither of which we had.

I also find it hard to track dependencies in Python code and I’m aware of, at least, one code coverage tool for Python useful for improving test suites (but try to avoid some common pitfalls).

Aside from the point of view of the webmaster who wants to make sure his website is well-formed this package is also useful for web client developers who want to sanitize invalid HTML before feeding it to their parsers.

There’s even a Python interface called uTidyLib.