This is a series of blogposts that consists of three parts:

(1) Part I: History of Bookmarks
(2) Part II: Daily Bookmarking
(3) Part III: Pushable Bookmarks

I stumbled over Mercurial in August 2007. Back then I had already
used Git for 6 months, but wanted
to try out different distributed version control systems (DVCS).
I soon began to like Mercurial’s approach because of its simple and
intuitive interface and its clean codebase. While playing around
with Mercurial for a few weeks I was content with its concepts.
There was one feature missing
that I really like in Git: git-like branches.

Unlike in Mercurial or in any other version control system, branches in
Git are simply lightweight markers pointing to a commit. Every ancestor of
the commit is considered part of the branch. Back then, this sounded odd to me. Later I realized it was a really good tool to create small local branches. You can create a small branch
for a feature, merge it into your mainline, and remove the branch
without anyone knowing you ever had a branch called
‘stupid-little-feature‘. To make a long story short: It’s a good
idea to have a similar concept in Mercurial, but none existed back in 2008.

In June 2008 I started developing Mercurial References providing lightweight branches similar to those available in Git. Although the initial work was appreciated by the community, it was rejected
in favor of a concept more natural to Mercurial. Matt Mackall, the author of
Mercurial proposed Mercurial Bookmarks.

Bookmarks

The concept of bookmarks is easy:
You can bookmark a commit with a unique name. So it’s similar to
a tag, with one exception, a bookmark advanced when you commit.
(Like real bookmarks when you go to the next page).

I wrote an initial version of Mercurial Bookmarks in August, that
was finally accepted in October. This improved git like workflows
in Mercurial but still the implementation was far away from what I
wanted. By adding the notion of a so called “current bookmark”, it
got better. Still bookmarks had one major drawback in comparison
to git style branches. They were local only. There was no way to
push or pull bookmarks.

Pushable bookmarks

This was the status for the past two years. I tried to make bookmarks
pushable during this time. A proposal by me how extensions in general
can exchange arbitrary information over the wire was rejected in
early 2009 because it was too unrestrictive for the protocol. A new
concept, so called ‘pushkey concept’ was developed in 2009. This
was discussed and accepted during the Mercurial Sprint in Paris,
January 2010.

Matt Mackall, who now gets sponsored to work on Mercurial,
worked on the initial implementationof pushkey and
pushable bookmarks. And finally after two years of ongoing complains
by people about local-only bookmarks, Mercurial 1.6 will have
pushable bookmarks and introduces a great new concept to exchange
metadata information between repositories.

The next blogpost will show you how to use bookmarks.

To use the php-trunk portsfile. Just extract the tarball into a directory and…

$ tar xzvf php-trunk-port.tar.gz
$ cd php-trunk-port
$ echo "file://`pwd`" > /opt/local/etc/macports/sources.conf
$ echo "file://`pwd`" >> /opt/local/etc/macports/sources.conf
$ port install php-trunk


And the best thing about the port: It compiles PHP with dtrace support :).

Please note the Portfile is very simple and is not tested with the additional modules provided by macports. So use it at your own risk and enhance it.

DOWNLOAD

UPDATE: as philip noted, it should be >> instead of >.

To compile PHP with DTrace, on Solaris or Mac OS do:

  $ svn co http://svn.php.net/repository/php/php-src/trunk php
  $ cd php
  $ ./buildconf --force
  $ ./configure --enable-dtrace
  $ make

To check if your PHP has DTraces probes enabled, you can check the phpinfo() using

 $ php -i | grep DTrace

or use DTrace directly>

 $ sudo dtrace -ln 'php*:::' -c 'php -m'

88836    php4614               php               dtrace_compile_file compile-file-entry
88837    php4614               php               dtrace_compile_file compile-file-return
88838    php4614               php                        zend_error error
88839    php4614               php  ZEND_CATCH_SPEC_CONST_CV_HANDLER exception-caught
88840    php4614               php     zend_throw_exception_internal exception-thrown
88841    php4614               php           dtrace_execute_internal execute-entry
88842    php4614               php                    dtrace_execute execute-entry
88843    php4614               php           dtrace_execute_internal execute-return
88844    php4614               php                    dtrace_execute execute-return
88845    php4614               php                    dtrace_execute function-entry
88846    php4614               php                    dtrace_execute function-return
88847    php4614               php              php_request_shutdown request-shutdown
88848    php4614               php               php_request_startup request-startup

Have fun with DTrace in PHP.

A few examples will follow in the next days.

In the following post I’ll show a brief example on how to create a login page with Compojure 0.3.2 running on Clojure 1.1.0.

What is Clojure?

Clojure is a Lisp dialect. So it’s a programming language based on the principles of Lisp. The interesting part about Clojure is that it runs on the Java Virtual Machine. As a developer you can therefore use the bright variety of Java written libraries in your code without touching one line of Java. Use the power of Java libraries together with the power of Lisp.

What is Compojure?

Compojure is a web framework for Clojure. It handles incoming request, offers an easy way to create servlets and provides basic functionality for HTML templates. The current stable version 0.3.2. Compojure is a young project and things change fast there, so be aware that a 0.3.2 application might not run on 0.4.

What is a session?

Basically it’s a per-user store managed by the server. For example a server backend can store the credentials of a user that it received in a request in this store making it possible to identify the user again when he or she does a second request. Usually this functionality is achieved by a library or by the interpreter itself (for example in PHP) and is implemented by storing the session data either in memory or on disk together with a unique identifier that is then stored in a cookie at the users computer. So when the user comes back, the cookie is read and the identifier is used to find the data for the user.

The application

A basic example

Before we work with a session, let’s create a simple webpage that displays hello world for us.

The example is straight forward. We define a set of routes. In our example the route is “/*”, so it matches everything. The route then takes a function as a second argument. In our case we use the templating mechanism of Compojure and create a simple HTML response with the (html) macro.

We then start the server using the (run-server) macro and binding our routes to a specified mountpoint. I won’t go into details about servlets but usually it is sufficient if you have a servlet running on the mountpoint “/*” and then a set of routes.

To run the server you can use a small script like this one:

#!/bin/sh
CLASSPATH=.:~/dev/clojure/compojure.jar:~/dev/clojure/clojure.jar
java -cp $CLASSPATH clojure.lang.Script net/experimentalworks/clojure/serve.clj


Adding sessions

Before we can start adding sessions we have to be aware that Compojure has a mechanism called decorating. So you can decorate a set or routes with what Compojure calls a middleware. We will think of it as a way to enable advanced mechanism. To add the session mechanism to a set of routes use the (decorate) macro as shown in the following code:

Note the that we define a session decoration. At the moment sessions only support in-memory storage (which by the way should be usually the way you want to manage sessions). The :memory keyword here is to tell Compojure to store it’s sessions in memory. Although you can omit the keyword, I prefer writing it down so people can easily figure out how our session is stored.

Creating a login

Let’s create a login. We will first add a new route called /login/:user. This will tell Compojure that the last part of the query string is a parameter and it should extract it. We can then access the value using (:user params). We use the (session-assoc) function to associate our username with the session-key :loggedin. Here is what the code looks like:

You can then “login” to your site using http://localhost:8080/login/test and you Compojure will recognize you again if you go back to http://localhost:8080/

Logout

To logout, we clear the key itself. Let’s a have a look directly into the code. We use the (session-dissoc) function to drop the key (it seems that clear-session is broken in my Compojure checkout for whatever reasons..need to debug *debug*).

Use http://localhost:8080/logout to get rid of your session.

Conclusion

The basic idea behind Compojure sessions is simple and I hope you were able to grasp the idea a little bit. What can be annoying and what I didn’t show you is that you might run into problems within the actual implementation, although the basic stuff should work fine. Once you figured out the basics you can read and write sessions withing seconds and the code becomes clean and beautiful. Feel free to comment on this article if you like the post, it’s the only measurement for me that I can use to make sure I’m not writing stupid stuff.

• Dutch PHP Conference 2010
• Interntational PHP Conference

The talk will give a very brief overview how Git works, and will then give a more detailed insight in how Git handles commits, files, etc so that people get a very good understanding about the concepts that are needed to fully understand tools like git rebase, git reflog and git svn. The aim is to provide them will all necessary information and a few examples to get lost commits back, rebase their branches and design more complex git workflows in the future without needing to search the web or ask a guru.

A second talk will be more focused on beginners and developers coming from subversion. This talk will be part of a series of talks the german telekom is organizing. I’ll also give an extended version of this as an in-house workshop at a Munich based company.

So for me it seems that after five years, DVCS is mature enough to get into companies and that we can expect a bright variety of companies to adopt new tools and workflows. Let’s see what’s coming…

For sure I still offer Git and Mercurial trainings, so feel free to contact me (dsp ~at~ php ~dot~ net)

probably shameless self promotion

As I wanted to have nice a build system for my PHP subversion checkout, I used this need as a project to start coding Scala. So what do I exactly need? I want to build multiple versions of PHP from the same branch without checking out the code twice. I also want to configure these builds somewhere without always typing in the parameter list or so. For further versions I want to be able to configure these in a file that can easily be distributed to other machines.

I set down and wrote a parser for a configuration file that can configured build targets which is then build by
the program. The configuration file I used is specialized for this purpose, which is why I didn’t used something like ant or so. The result is called bauaffe-3.0.0a1.jar.

I’ll just show a few things done in the project, but mainly focus on what the nice script can do. Further blog posts will be about the actual implementation.

The configuration looks like this

$ cat ~/.buildmaker
begin default configuration
    define source "/Users/dsp/dev/c/php-src"
    define build "/Users/dsp/dev/c/php-src/build"
    define defaults as
        with "iconv=/opt/local"
    build trunk as
        "php60" using defaults
        "php60-debug" using defaults
            enable "debug"
    build branch "PHP_5_3" as
        "php53" using defaults
            environment PHP_AUTOCONF="autoconf213"
        "php53-debug" using defaults
            enable "debug"
            environment PHP_AUTOCONF="autoconf213"

.
Proper indention is not necessary (as e.g in python).

Did I mention that the actual parser is 170 lines of code with usual indention and formatting?

Configuration
The configuration file is searched in ~/.buildmaker, or if ~/.builmaker doesn’t exists, buildmaker.conf in the current directory. How do you configure the tool? First of all you can specify a configuration. It is usually called “default”. It is not yet supported to name it differently, although the parser is able to parse it. In further versions multiple configurations per file are allowed.

Variables
Variables are set using the define syntax. At the moment you can set the build and source variable as well the defaults variable, which is usually a block of statements that can be used in the branch configurations.

Branches
A branch is configured using the build syntax. You first have to specify which branch to build. Every branch can then configured to have build target with a given set of options. Branch options are:

• with string: Builds the target with the given extension
• enable string: Builds the target with the given extension
• environment string=string: Builds the target with environment variable

. You can specify using defaults which will cause the runner to use the options specified in the defaults define.

At the moment the parser will not do a good job in notifying you what you are allowed to do and what not, although pure parse error will be emitted. You can also not set any other variable than the described once.

Building
Calling

$ java -jar bauaffe-3.0.0a1.jar list
TARGET                         LAST BUILD
php60                          None
php60-debug                    None
php53                          Sat Jan 09 16:55:12 CET 2010
php53-debug                    Sat Jan 09 16:59:37 CET 2010

gives you a list of parsed targets and their last build date. You can build a target using

$ java -jar bauaffe-3.0.0a1.jar 

or build all using

$ java -jar bauaffe-3.0.0a1.jar all

Please notice that the current version requires that you now what you are doing. You might miss some error messages or find them not useful. I’ll change this before the first release, if I’ll do a final version of it. I hope you like the little tool.

Download It!

Scala (pronounced /ˈskɑːlə, ˈskeɪlə/) is a multi-paradigm programming language designed to integrate features of object-oriented programming and functional programming.[1] The name Scala stands for “scalable language”, signifying that it is designed to grow with the demands of its users.

In your .zshrc add the following line

RPROMPT='[%?]'

This will give you the last exit status on the right site of your shell.

My zsh now looks like this (with the additional stuff)

buenosaires:~/dev/c/git.git/>                                         (next)[1]


The following article will outline the current limitations of bi-directional dvcs to subversion bridges and shows a simple approach to implement a solution for a certain instance of the problem.

The bi-directional bridge
The idea of finding a way to interchange commits back and forth between a DVCS and subversion was born early in the development of tools like Git and Mercurial. The basic idea is easy to grasp. To initialize a repository the DVCS requests all changes between revision 0 and the current HEAD from the subversion server and imports every change as a regular changeset into the local repository of the DVCS. In addition it maintains a mapping between the local, DVCS specific, changeset IDs and the revision numbers in the subversion repository. If a developer wants to push his newly created changesets from it’s local repository back to subversion, the bridge determines the latest pushed changeset and then iterates over the unpushed changes, committing them bit by bit to the subversion server.

Depending on the DVCS you use it will then delete the local changeset and reimport the comitted changesets from the subversion server to ensure that the changeset contains the right date and comitter information as well as the right mapping to the subversion revisionnumber.

Example
To clarify what we just discussed. Assume that we are using git-svn. We are importing a subversion repository with just one commit using the command (I won’t get into detail how to use the command):

$ git svn clone svn://example.com/repo

This command results in a repository which in our example contains the following commit.

commit 7a730e9187becbe1979059cd9752fdea38e3cd9e
Author: david >david @cffdd316-8dd2-4046-8f43-d0df91842a18<
Date: Thu Jul 12 19:39:51 2007 +0000

Crescas in mille millia

Let’s asusme that we create a new commit on top:

commit 129e0e4239ac4d375f2a2132dee042a27f2fd70c
Author: David S. P. >dsp at php.ent<
Date: Fri Jul 13 12:23:42 2007 +0000

First Draft

If we push it using git svn dcommit, it’ll be committed into subversion and
reimported as:

commit 8200f32f61432004b488d063564ac9dae7bf6827
Author: david >david @cffdd316-8dd2-4046-8f43-d0df91842a18<
Date: Fri Jul 13 12:23:42 2007 +0000

First Draft


Limitations
Tools like git-svn or hgsubversion are working perfectly fine as long as you use them just as a subversion client. There is a serious limitation in what you can push and pull from and to a subversion server. Particularly, problems arise if you are using the usual DVCS push and pull method to exchange changesets. Why so? If you push and pull from other DVCS repositories you might have to create a merge. Modern DVCS like Git, Mercurial or Bazaar represent history as a directed acyclic graph (DAG). Therefore a merge is a commit which has two (or more) parents, which means that a merge is the resulting connection of two parallel strands of history. Now this is a very comfortable and powerful way to describe history in parallel development. Sadly subversion doesn’t handles history and hence merges the same way (at least not priort svn 1.5). As a result, it is not possible to represent the Merge from a DVCS in subversion.

Different bi-directional bridges have different approaches to this problems. Git-svn will commit the Merge but not the commits which are part of the seconds strand of history, while hgsubversion will abort if it has to push a merge. The fact that hgsubversion aborts in case of a merge is our actual problem. We want to use Mercurial and therefore need to find a way to push a merge to subversion.

A usecase
You shouldn’t care much about these limitations. Usually, people are using the bi-directional bridge locally to be able to do offline commits or bisect a bug. In that case, everything will work fine.

But why do I write a complete blog post about a hg to svn bridge if the problem is already solved? The answer is pretty simple.

1. Imagine you are working in a small team. Everybody in the team knows Mercurial and everybody likes to use it. Moreover you are working offline from time to time, and the members of the team sometimes have to exchange unfinished features with other members. In that case you will probably use Mercurial as your version control system. The problem here is the customer. He dictates the VCS and it has to be Subversion. Now subversion at all is not that bad, but in your particular case, it’s a huge drawback. You have to find a way to mirror your Mercurial repository to the Subversion server.
2. A second use case is that you are working on an OpenSource project which uses github or bitbucket to host it’s repositories. As you are using the OpenSource framework also at work. You have to use Subversion and you want to use svn:externals to integrate your fancy framework into the existing Subversion repository

As you see, there is a use case for DVSC to Subversion mirror. As no such tool exists at the moment, we’ll try to implement a (frankly, very stupid) mirroring mechanism.

The idea and it’s limitations
We see that we need to mirror a existing Mercurial repository to Subversion.
We also know that we cannot use the existing tools. Our requirements are the following.

1. Mirror a Mercurial repository into a Subversion repository
2. Track latest synchronized changeset
3. Handle merges

Note that we would have been able to do this with git-svn, while it’s not possible to do it with hgsubversion.

A few assumptions about the environment where we want to use our mirroring mechanism helps us to simplify the requirements.

1. We do not need to preserve the author information
2. We have a central Mercurial repository called Gate
3. No commit will be done into the repository other than our mirroring (and believe me, things get ulgy for you if you try to…)
4. We do not need to preserve all commits

So what is the end result? We just need to find a way to push all changesets and just ignore all merged changes, but commit the merge itself. This should be sufficient.

In our particular environment everyone has his own repository, but one person integrates all changes into one repository called the Gate. Commits reaching the gate are committed to Subversion.

The implementation
To make a long story short (it’s getting late). We are using Mercurials log command and it’s option to obtain a linear history that can be pushed. To get the the history, we use

hg log --follow-first

This will return the history omitting all merged changesets but including the merges itself. We silently drop the changesets that were merged, but retain the result. As we need to get just the SHA-1, we use the –template option to get the node. We then iterate over the history, updating our working copy to each changeset in the history, adding all newly created files and deleting all removed files and then comitting the current state of the working directory. So here is our final script

#!/bin/sh

lc=0
cont=0
if test -f "LAST_COMMIT"
then
	lc=`cat LAST_COMMIT`
	cont=1
fi

for hash in `hg log --follow-first --template "{node}\n" -r $lc:tip`
	do
		if test $cont -eq 1
		then
			cont=0
			continue
		fi

		echo "update to $hash"
		if ! hg log --template "{desc}\n"  -r $hash > COMMIT_MSG
		then
			echo "Canno get log" >&2
			exit 127;
		fi
		cat COMMIT_MSG

		hg up -C -r $hash
		for file in `hg log --template "{file_adds}\n" -r $hash`
			do
				echo "add $file"
				svn add --parents $file
			done
		for file in `hg log --template "{file_dels}\n" -r $hash`
			do
				echo "del $file"
				svn rm $file
			done
		svn commit -F COMMIT_MSG
		echo $hash > LAST_COMMIT
	done

It looks scary, and yes it is scary. But for the moment it works. Our simple hg to subversion bridge is finished.

The happening will take place at Waldwirtschaft (http://www.waldwirtschaft.de)
beer garden, at any weather. We will meet at 19:00 o’clock – open end.

Catering will be provided and as a special delicacy you may enjoy a suckling pig!…hopefully vegetarian food. If you like to join the event please register at PHPUG-Munich Wiki (http://phpugmunich.org/dokuwiki/php_release_party) and follow it for updates. Alternatively you may register at Facebook
(http://www.facebook.com/event.php?eid=115203467104) as well and follow
this for updates.

For any questions please visit IRC channel: #phprp on irc.uni-erlangen.de.

The PHP 5.3. BBQ release party is sponsored by:
– Microsoft
– Mayflower GmbH
– Swoodoo AG
– Zend Technologies GmbH

Supporters for the PHP 5.3 BBQ release party are:
– Sun Microsystems
- PHPUG.de