CREATE TABLE "SOME_TABLE" (
    ...
    "TIMESTAMP" TIMESTAMP WITH TIME ZONE
);

Oracle is rather picky on identifier names, but since it accepted “TIMESTAMP”, I was assuming everything is fine. Later I needed to create a trigger for this table and that’s where the fun starts.

CREATE OR REPLACE TRIGGER "SOME_TABLE_TR"
BEFORE INSERT ON "SOME_TABLE"
FOR EACH ROW
BEGIN
    ...
END;

This was failing for some reason though. The only thing I got was this “nice” error message, pointing to the table name in the CREATE TRIGGER statement:

ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-320: the declaration of the type of this expression is incomplete or malformed

What type? Do I have a typo somewhere? Did the table somehow get corrupted? You can’t imaging how long did it take for me to figure out that it doesn’t like the column name, which was not mentioned anywhere in the PL/SQL block. I would have no problem if it told me that I can’t use the name. There are too many restrictions on identifiers anyway. What I don’t understand is why does it allow me to create something that’s going to break other core functionality.

Cheap Branches

One of the main reason people use DVCS is cheap branching. The most surprising thing for me was that Mercurial doesn’t offer many choices. It doesn’t have the concept of branches, like Bazaar or Git. All you have is an immutable repository that can contain multiple head revisions. By default, you are expected to clone the whole repository. As I mentioned earlier, I tend to work with many feature branches, so I prefer to have just one working tree.

One way to partially solve this problem is the bookmarks extension. It basically allows you to have dynamic tags that move to new revisions as you commit. The initial configuration looks like this:

[extensions]
bookmarks =
[bookmarks]
track.current = True

The next step is to go to your clone and set the main/trunk/master/etc. bookmark:

hg bookmark main

This is necessary, so that you easily know which revisions represents the project’s “mainline”. With the configuration I mentioned, the extension will track your current bookmark and update only that one. To set the current bookmark, you can use update:

hg up -r main

It’s important to always have the current bookmark set to main whenever you are fetching changes from the mainline. Otherwise you will have to manually fix the bookmark’s revision.

Creating new “feature branches” is easy then:

hg bookmark -r main my-feature
hg up -r my-feature

One important thing to remember is that after you use this, the repository will contain multiple heads. This means you can’t use plain hg push to push changes to remote repositories. You always have to specify the revision, for example:

hg push -r main https://hg.example.com/projects/trunk

Merging

When it comes to merging, Mercurial doesn’t make your life easier at all. The default assumption is that visual merging is the preferred way to go. Maybe I’m just too stupid, but I don’t get visual merge tools. I just don’t know how to use them. I prefer merging changes manually in my text editor, after I see the changes for the whole project. Mercurial would start up the merge tool for each file linearly, which means you don’t have a global picture of impact on the project, when you are supposed to resolve a merge. I just can’t work that way.

Fortunately, Mercurial does have an internal three-way merge algorithm, that can leave conflict markers in the merged files and let me do my job. You can configure it this way:

[ui]
merge = internal:merge

This actually uses the merge code from Bazaar, so I expected I’ll be done quickly. There is one problem though. Instead of using patience diff, like Bazaar, it uses its own diff algorithm. The result is that in Bazaar the algorithm works just fine, in Mercurial it produces horrible results. That’s actually pretty funny, considering the fact that I used ideas from Mercurial’s diff code to implement the C version of patience diff in Bazaar.

Next step, the Mercurial wiki suggests diff3 as a possible non-interactive merge tool. There are no examples how to configure it, but something like this technically works:

[ui]
merge = diff3
[merge-tools]
diff3.args = -m $local $base $other > $output

In my experience, this produces even worse results than internal:merge, so there is no reason to use it.

The last idea was to use the merge program from RCS (yes, that’s right, using an ancient VCS to fix issues in a “modern” VCS). I must say that installing RCS in 2010 feels weird, but as long as I can get my job done… Once it was installed, I used this configuration:

[ui]
merge = merge

I was surprised that the results were acceptably good. Not perfect, but I knew I can’t expect more from a three-way merge. Ideally I’d like Bazaar’s merge algorithm with patience diff, but I probably won’t find time to port it, so merge will stay as my default merge tool for some time.

That’s only the first part of the problem though. Now you have files with conflict markers and you need to resolve them. Based on my experience with other version control systems, I assumed conflicts would be listed in hg status, but I was wrong. They are nicely hidden here:

hg resolve -l | grep '^U'

After manually resolving the conflicts, you can use the following command to mark the files as resolved:

hg resolve -m path/to/file

To be continued…

Somebody asked a question about a Perl module a few days ago and based on reading the source code of the module, I gave them one possible way to solve the problem. Today, an author of multiple Perl books came in and very confidently claimed that my solution will never work. I explained him why he is wrong, but it didn’t help. The problem was that he failed to read the source code correctly and made incorrect assumptions based on that. I pointed him to specific parts of the code, still nothing. At that point I wanted to gave up, but later he came up with a broken example, which didn’t work for different reasons, that should show me why I’m wrong. Soon after that he realized what is wrong about the example, changed his answer and deleted all his old comments, as if they never happened.

The problem I see is not this specific case (I’ve seen far more of them, either on Stack Overflow or some IRC channels), but the fact that even average programmers write popular programming books. And people learn from these books. I guess the saying about teachers who failed to apply their knowledge in practice, which I can’t remember right now, applies even for book authors. What a wonderful world.

(I just needed to get this out of myself.)