Introduction

If you are building software and want to release that software at regular intervals then why not tag each release in Mercurial? That way you can very easily rollback to that version of the software at any time. Whats more is that you can use your own tags rather than trying to remember the mercurial revision number that was current at the time of release.

There are many approaches to software versioning which will not be covered here. Check out this wikipedia article on software versioning for more details on the different approaches. The purpose of this article is to apply the versioning as a tag in your mercurial repository.

Apply a tag in mercurial

When using mercurial, you must always tag after a commit. So if you know that you want to tag your current working directory, you must commit it first and then tag it. Given this it obviously makes it very easy to tag a commit that you might have made a long time ago in the past. Bear this in mind when using the tag command in mercurial and you will understand clearly how this feature can be used.

This is how you would tag a revision in a mercurial repository, first decide what revision you want to tag and then run the following command. In this example it will tag revision number 45 with “2.0.5″

hg tag -r 45 2.0.5

This command automatically commits this tag, so if you run “hg tip” in your terminal, you will see something like the following:

changeset:   51:209937087918
tag:         tip
user:        Darren Jensen
date:        Sun Nov 22 13:10:47 2009
summary:     Added tag 2.0.5 for changeset b50b86512aac

Note that the changeset for “tip” is 51:209937087918 and the comment is “Added tag 2.0.5 for changeset b50b86512aac” (this comment is also added automatically by mercurial by the way). Given that I asked mercurial to apply the tag to revision 45, you can easily see that it is a commit made a while ago. The changeset indicated in the comment (“b50b86512aac”) does indeed refer to revision 45.

Use a tag in mercurial

So how to use this tag going forward? Here are a couple of ideas.

Use it to see the commit info at that time using the log command as follows:

hg log -r 2.0.5

This will return the log entry that is associated with that tag, so in our example it would return the entry for changeset 45:b50b86512aac, as follows:

changeset:   45:b50b86512aac
tag:         2.0.5
user:        A Developer
date:        Tue Jul 21 14:27:50 2009
summary:     Made some serious changes to the application and deployed it to production

Use it to clone the repository to the tag point (note that the tag itself would not be included since that is added after this point). So if you do a “hg tip” on this cloned repository, then your would see the log entry for changeset 45 but the tag and the changeset that commit the tag will not be there (changeset 45 will have the tag “tip” in this case!).

hg clone -r 2.0.5 somerepo

Check out the Mercurial wiki for more details regarding tagging in mercurial, including how to deal with tagging conflicts, local tags (as opposed to “regular” tags which is covered in this article), removing tags and more.

Jag målade in mig lite i ett hörn när jag började med den här serien med inlägg. Ingen dag har känts helt rätt för att skriva det sista inlägget – det i sin tur har hindrat mig från att släng in smånotiser i bloggen med. Trist.

Nu är det så dags att avsluta, storstilat avsluta till och med. Detta inlägg kommer att behandla och vara en historieskrivning för Blekinge studentkårs aktiva arbete med öppen källkod. Studentkåren har länge varit en förkämpe och stor nyttjare av öppen källkod men man har inte precist levt som man lär. Vi är väl inte hela vägen fram i något som andra kan ta del av men ambitionen finns där.

Vårterminen 2005 började jag engagera mig i studentkårens sektion för kårpuben i Ronneby. Som nyvald informationsansvarig blev jag involverad i driften av informationssystemet som en ensam stackare utvecklat för sektionens vinst. När jag var en del av driften av de fysiska maskinerna blev jag snart en del av utvecklingen av koden också. Det var inte precis något kontrollerat och snyggt uppstyrt bygge vi hade att göra med här. Men det funkade och folk var nöjda med hur det blev. Åren gick och när jag lämnat sektionen satt jag kvar med inloggningar och hjälpte till med lagningar. Efter mig på informationsposten hamnade Lars/Läffe/Laeffe – även han hängde kvar och i sin tur drog han in Jonas/DrLaban i det hela. Det var bara underhåll och i någon yttepytte mån kunde det hamna en ny funktion på sidan. Undantagsfall. Tills sommaren 2008.

I maj 2008 tog DrLaban initiativet till att vi skulle göra något mer med det som kallas “kårsajten“. Laga fel, lägga till funktioner och helt enkelt ta hand om den. Jag skulle börja min sista termin på BTH och hade inget särskilt för mig utöver studier. Det är dessutom roligare om man kan snacka med nån om det man gör än att bara sitta hemma och hitta på egna ideer och se om de funkar. Jag hoppade på tåget. Med följde dessutom både DrLaban och Laeffe. Snart hörde Emma/Soya och Thomas/Tomten av sig och även de hakade på. Tomten mer åt drift, säkerhet och kringsystem medan Soya grävde ner sig rejält i koden tillsammans med oss andra tre. Vi jobbade på bra, DrLaban och Laeffe drev på i utvecklingsmetodikspåret som de vana PT-studenter de är och en metod närliggande Scrum började nyttjas. Allt gick inte tokbra men det blev ganska snyggt. Vi strukturerade upp källkoden i ett kodförråd i Subversion, kopplade det till projektverktyget Trac och det skapades en massa dokumentation och ideer på nya funktioner och koncept föddes. Vi drog lite åt olika håll och vi gör väl det fortfarande men arbetet löper på så jädra snyggt månad efter månad. Det har nu gått ett och ett halvt år i arbetet med kårsajten, vi har numera börjat jobba med att ta in åsikter och ideer från kårhussektionerna som en naturlig del i processen. Ytterligare en källa till inspiration och irritation. Det ser ut att gå riktigt bra.

Men det är inte änden på historien, det är snarare historien i sin linda. För ungefär ett år sedan började kårstyrelsen intressera sig för vad vi sysslade med. Jag hade aviserat att jag skulle nog flytta från Blekinge halvsnart så det stöd jag var i att ta hand om mailsystem och annat behövde omvärderas.

För att vi fem skulle kunna utveckla kårsajten på ett bra sätt framöver och för att kunna skänka lite struktur för vem som äger vad och hur saker förhåller sig till studentpopulationen så diskuterade vi organisationsform. Att sträva efter att bli en del av studentkårens paraply var vi helt ense om från början. Hur det skulle genomföras var mer svårdefinierat. Vi skrev en Verksamhetsförordning (typ stadga) som reglerade hur arbetet sköttes och leddes och hur vårt förhållande till organisationen såg ut. Den antogs av Kårstyrelsen i december 2008. När vi väl hade blivit Sektionen för Internetbaserad Socialisering så hörde Kårstyrelsen av sig och undrade om vi inte kunde ha tid för övriga delar av verksamheten, typ 15-20 servrar och klientdatorer, skrivare, nätverk, kassaapparater och sånt. Det var inte riktigt vad vi planerat och kanske var det inte vad vi skulle gjort men glada och trevliga och vänliga som vi är så sa vi ja och bad att få återkomma med ett förslag på hur.

SIS skulle omformas men grundtanken och processerna skulle kvarstå. Hur i hela friden då? Vi lyckades skapa en organisation i studentkårens sektionsramverk med två nivåer. En visionär övergripande styrelse(Äldsterådet) och autonoma undergrupper (basgrupper). Basgrupperna sätter sina ramar själva om hur de jobbar med vilka verktyg och vilka som är en del av dem. De enda kraven i organisationen är att basgrupperna leds av någon i Äldsterådet, att allting ska göras så öppet det bara går för att leva med den öppna källkodens natur och att sektionen inte ska vara ekonomiskt beroende av någon.

Funkar det då? Det har snart gått ett halvår med den nya organisationen. På papperet fungerar det utmärkt. Fysiskt vet jag inte riktigt. Kårsajtsgruppen jobbar på som sagt. Driftgruppen som tar hand om fysiska maskiner och nätverk och sånt ser ut att funka men det är mycket personberoende och mycket adhoc snarare än strukturerat och tydligt. Väldokumenterat är det dock i driften. För övriga delar är arbetet inte särskilt tydligt eller ens särskilt påtagligt alls. En av grupperna är den jag själv leder, leder och leder förresten. Det har inte hänt så mycket men bot och bättring hoppas jag på =)

Jag tror att konceptet med SIS är bra. Grundstommen i hur gruppen funkar är jättebra. Vi har en del berg kvar att bestiga, ett av dem är att skaffa fler som kan hjälpa till. Vi har alldeles för lite resurser för den kostym vi tagit in i provrummet just nu. Därmed inte sagt att vi inte kan leverera för det kan vi, alla som är med sliter så sjukt hårt och är hjälpsamma och glada och trevliga. Det är nästa steg som saknas och det är ett jädra hästakliv att ta.

Låt oss titta lite mer på det här med tekniken i gruppen. Jag nämnde att kårsajten kör en utvecklingsmetod närliggaden Scrum. Processen för den finns ganska väl dokumenterat i wikin vi använder men i korta drag har vi anpassat saker för att fungera distribuerat på nätet och utan att alla involverade har projektet som huvudsyssla. Istället för dagliga möten har vi avstämningar tisdagar, torsdag och söndagar – kort och koncist för att fånga besvären i projektet. Dessutom håller alla till på Trac, IRC och mail så det går att få hjälp relativt omgående. Kårsajten är ett stort PHP-bygge med en MySQL-databas i botten och ett eget ramverk i PHP ovanpå en Debianmaskin som kör Apache.

Som konstrast till strukturerade Kårsajten så har vi då Diariet och 2.0/www, Diariet har haft möten och jag har en intention på hur jag vill jobba med uppdraget men det är inte mycket mer än så idag. Bland annat är det klart och färdigt att vi kommer att skriva den mesta koden i Python och nyttja Django som ramverk – nya impulser och nya intryck för SIS. 2.0/www styrs av Laeffe och ävan han är helt adhoc så vitt jag vet. Jag tror att det kommer en rejäl runda med grejjer inom de närmsta månaderna där – det uppdraget är dock mycket mer löst specat än mitt eget som faktiskt ska producera något färdigt till den siste juni 2010.

Blekinge studentkår är inte öppen källkod än men det finns stor potential i det vi bygger inom studentkåren vad gäller både källkod och kultur för att vi snart ska kunna flytta mer saker till öppenheten.

Läs även andra bloggares åsikter om öppen källkod, open source, php, python, apache, mysql, django, blekinge studentkår, bth, sis

I have been wanting to learn more about Git Submodules and how they work, so I watched the screen cast at the bottom of http://book.git-scm.com/5_submodules.html (would have embedded it, but there were issues doing so). The bottom line is that the Super module contains a reference to a specific version of a Sub module. Git’s submodule command can then determine if you have a different version of the Sub than you should, it can fetch the current version, etc.

The process sort of goes like this, using C1 for Computer 1 and C2 for Computer 2:

1. C1: change Submodule
2. C1: commit Super module, freezing version of Sub used by Super
3. C1: push Super module
4. C2: pull Super module, gets the updated Sub module version SHA
5. C2: submodule update, gets the updated Sub code corresponding to the version in #4.

Some observations:

• Will a user ever do 4 and NOT do 5? Why?
• If 4 and 5 are tied together, why is that not one step (ala git push = git fetch; git merge origin/master)?
• C2 has no idea to update the Sub code unless they are carefully watching the pull output or run git submodule status directly after 4 above to know that a Sub update is needed
• Possible source of issues if C2 has Version x+1 of Super but only version x of Sub

Now, I’m new to Git, but it would seem to me that one could write a hook that would automatically run git submodule update if .gitmodules is present in the directory. It would seem that an appropriate hook to git pull would be to add git submodule update after the pull. Am I missing something here?

I understand that git’s submodule support has been added-on as submodules were not something in the design of Git. I wonder if the lack of these hooks and a better user experience is the direct side effect of that bolt-on?

Mercurial seems to be trying to do this via it’s subrepos support:

Whenever newer Mercurial versions encounter this .hgsubstate file when updating your working directory, they’ll attempt to pull the specified subrepos and update them to the appropriate state.

Enough to make me switch? Not if I can write a hook.

На этот раз команда TortoiseHg сработала оперативнее – TortoiseHg 0.9 c Mercurial 1.4 внутри уже раздаётся, в то время как официальный сайт Mercurial пока молчит.

How best to describe slide trumpeter Steven Bernstein’s singular quartet Sex Mob?
Maybe we should start with mercurial musical magician Bernstein himself, whose exotic career as sideman, musical director, arranger and composer has included ten years with John Lurie’s Lounge Lizards and stints alongside everyone from Bill Frisell to Sam Rivers, the Flying Karamazov Brothers and, oh yes, Bootsy Collins. Or maybe we should look at his career as bandleader, which includes the trumpet-slide guitar-tuba trio Spanish Fly and the boisterous, cataclysmic nine-piece Millennial Territory Orchestra. Or maybe we should just listen to Bernstein’s own summing up of Sex Mob (which began life in residency in 1995 at the Knitting Factory’s “late night hang” as a vehicle for Bernstein’s own compositions and quickly morphed into a band covering everything from film composer John Barry’s James Bond music to Duke Ellington to Prince): “Jazz used to be popular music. People would go out to clubs, listen to the music, go home and get laid. Simple as that. We’re bringing that spirit back.”"That spirit”—one of wailing, riotous abandon mixed with eccentric song choices, high musicianship and healthy doses of funky downtown grit—is on ample display on the group’s first live recording, Meets Medeski, waxed at Switzerland’s Willisau Jazz Festival. Less of a meeting than a reunion—groove god John Medeski is an old cohort of the band and can be found on the group’s first release, 1998’s Din of Inequity—the disc is divided into three seamless “suites,” each of which intersperses a couple of originals with covers of Ellington’s “Black and Tan Fantasy,” Count Basie’s “Blue and Sentimental,” two Prince tunes, four Barry “Bond” cuts and (I kid you not) “Down on the Farm” and “Little Liza Jane.”

It is, in short, an absolute gas. And it works, thanks to Bernstein’s impeccable taste and leadership. For all his mischievous rambunctiousness, Bernstein is both a rigorous designer of musical soundscapes and an exacting conductor; no matter how loose the band seemingly hangs, he keeps it under a watchful eye and the music stays concise and true. (Case in point: the longest tune on the CD clocks in at just over six minutes, a somewhat astonishing achievement for a live jazz disc.) As with any Sex Mob show, the Bond tunes are a highlight: both the calamitous “Oddjob,” with Bernstein’s ragged trumpet soaring atop Medeski’s alternately delicate and bombastic Hammond B3, and Barry’s gorgeous “You Only Live Twice,” done as boozy, woozy, soul-inflected ’60s scream, are sublime. Medeski, as expected, sounds terrific in this context (check out his brusque, rampaging solo over Kenny Wollesen’s tumbling drums on “Down on the Farm”).

Sex Mob at All About Jazz.
Visit Sex Mob on the web.
Track listing: Mob Rule Invocation; Mob Rule 1; Black and Tan Fantasy; Mob Rule 2/Little Liza Jane; Sign O The Times; Down On The Farm; This Never Happened to the Other Guy; Mob Rule 3; This Never Happened Part 2; Blue and Sentimental; Kenny Supreme; Darling Nikki; Odd Job; You Only Live Twice; Mob Rule 4; Artie Shaw.

Personnel: Steven Bernstein: slide trumpet; Briggan Krauss: alto saxophone; John Medeski: organ; Tony Scherr: bass; Kenny Wollesen: drums, percussion.

The Mercurial distributed version control system is used by thousands of developers. NetBeans, OpenJDK, OpenOffice, and Python itself are just a few of the projects that have adopted Mercurial as their version control system. But as much as Mercurial has been making incredible inroads in the open-source community, it has some key deficiencies that make it a poor choice for real-life commercial development.

Here at Fog Creek Software, we’re about to release a brand-new source control management system called Kiln that’s based on Mercurial. As part of that project, we want to fix the problems in Mercurial that currently prevent commercial development shops from adopting it with the same enthusiasm as their open-source counterparts.

That’s where you come in. In UCOSP, you will focus on improving Mercurial’s performance and user. More specifically, you’ll:

• Improve the handling of binary files
• Improve support for very large repositories
• Add support for secure password management
• Improve end-user feedback during lengthy network operations
• Improve history viewing tools

Once you’ve implemented these improvements, we’ll be sending them to the Mercurial project, which has a highly supportive developer community and a predictable release schedule. So you’ll have a really high chance of seeing your code in production soon after the project ends.

Mercurial is written in high-level Python and low-level C, and has relatively complex on-disk formats and network protocols. Because we’ll be touching most of the stack, you’ll feel most comfortable if your past experience runs the gamut from high- to low-level work.

Mentor: Benjamin Pollack (Fog Creek Software)

My mercurial.ini settings found in C:\Documents and Settings\<home dir>:

Working in Sabre Airlines uses a proxy server.

[http_proxy]
host=www-ad-proxy.sabre.com:80
user=<username in proxy>
passwd=<password in proxy>
no=localhost,127.0.0.1,code.openbravo.com

[ui]
username = Gerard Lee <gerarldlee (at) hotmail {dot} com>

[extensions]
hgext.graphlog =

[diff]
git = 1

Harga Rp. 599.000,- (neg0)

Harga Rp. 649.000,- (nego)

Harga Rp. 599.000,- (nego)

The plug-in to browse Mercurial repositories was updated, it now handles more cases correctly.

The idea behind these plug-ins is that you can thus compare a specific tag or revision in your Mercurial repository with your local hard drive, an FTP site but as well with a Visual Source Safe, a SubVersion or whichever other SCC that ECMerge supports (see SCC Tool Dialog Box).

This new plug-in version is included in the upcoming 2.2.106 version.

Have a good week
Armel

Who likes mercurial? I do. Lately, I even started using mercurial as a client for subversion repositories. Let me describe the hgsubversion installation steps that worked for me; on my laptop that is boldly supplied with The Only Right operation system…

I heavily borrow from excellent entry by Ben Collins-Sussman and from outrageously diligent post by Dave Cameron. I want to focus on the smallest possible installation routine on windows. Also, I want to emphasize that you don’t have to build anything on windows. All the prepackaged installables or binaries are ready, waiting for you to grab them.

Oh right, here are the steps that worked for me:

1. Install svn
2. Install python
3. Install python svn bindings
4. Install mercurial
5. Clone hgsubversion
6. Configure hgsubversion extension
7. Start cloning svn repos!
8. Understand the gotchas
9. Stay happy

1. Install svn command line client and put it on path. I downloaded, unzipped and PATH’ed svn 1.6.5.
Your cmd should react nicely to: svn help

2. Install python. I installed Python 2.6.2. Your cmd should happily execute: python -V

3. Install svn python bindings. I installed svn-python 1.6.5 py2.6. Your cmd should print ‘6′ when you execute:
python -c “import svn.core; print svn.core.SVN_VER_MINOR”

4. Install mercurial. I installed TortoiseHg (mercurial + tortoise). Your cmd should nicely take: hg version

5. Clone hgsubversion:

hg clone http://bitbucket.org/durin42/hgsubversion SomeFantasticFolder

In my case SomeFantasticFolder is c:\projects\open-source\hgsubversion. At the moment I cloned hgsubversion the tip was the changeset 500.

6. Configure hgsubversion extension. Add extensions to your USER_HOME/.hgrc, which on windows is Documents and Settings\SomeFabulousName. In my case SomeFabulousName is sg0897xxx (after years in IT industry I’m still just a number…). Note that hgsubversion is duplicated at the end – that’s fine. Your .hgrc should contain something like:

[extensions]
rebase=
svn=c:\projects\open-source\hgsubversion\hgsubversion

Your cmd should print enabled extensions at the bottom of the screen when you do: hg help extensions

7. Start cloning svn repos! For example:

hg clone http://example-for-hgsubversion.googlecode.com/svn example-for-hgsubversion

8. Understand the gotchas.

• gotcha 1. If svn requires authentication, you may be asked to enter user/password… 3 times. Don’t worry, just enter correct credentials patiently. Three shall be the number thou shalt count, and the number of the counting shall be three. (update) Augie Fackler, the mastermind of hgsubversion points out svn+http or svn+https can be used to work around this gotcha
• gotcha 2: After updating changes from svn (hg pull, hg update) never use ‘hg merge’, instead use ‘hg rebase’. Merges are not yet supported by hgsubversion I heard. If you accidentally do hg merge you probably have to rollback the merge in order to push.
• gotcha 3: (new) From my experience it is better to clone entire repo, not only trunk. Cloning trunk worked for me but I noticed exceptions thrown during unsuccessful rebase. Working with full repo clone was smooth for me so far.
• gotcha 4: I’m not a mercurial expert so feel free to comment & give feedback. Also, newer (different) versions of before mentioned installables should work as well.

9. Stay happy. Are you kidding me? You know what to do =)

Mercurial 1.3 has a nice feature that makes our coding lives easier. You can define your authentication credentials globally, so that it will remember your username, the password, or both in any repository cloned from code.openbravo.com. There’s therefore no need to define the credentials individually in every repository.

Example of the relevant section to be added to $HOME/.hgrc:

[auth]
ob.prefix = code.openbravo.com
ob.username = johndoe
ob.password = supersecret

If you only want it to remember the username, then remove the password line.

And if you still are using an older version (hg version), you can follow these instructions to update to 1.3.1.

For more information about this feature check the hgrc(5) man page.

Screenshot of the original Clonk Rage, clickthrough leads to more screenshots.

A quote from the webpage:

OpenClonk will be the Open source successor of the Clonk gaming series.

In early march 2009, Matthes Bender told the other developers of Clonk Rage that he wouldn’t have any time to work on Clonk anymore. As the Game Designer of Clonk Rage and Directing Manager of RedWolf Design, the company selling the Clonk titles, he left a significant vacancy. The development of Clonk Rage was mostly done as a hobby by the other developers, and although they wanted to continue doing that, they felt that more contributors were needed. Thus it was decided to radically lower the barriers for new contributors by publishing the source code to the engine, allowing everyone to freely modify the source code and game content, and discuss the future directions in an open forum. It was also decided to drop a lot of the “old” game content and drop the backwards compatibility requirement. The goal is to encourage new people to participate, while allowing the Clonk Rage developers to continue working on at least some of the code they produced and are familiar with. There are also plans to continue the clonk.de league for registered players for those who want to play in a supervised league.

Didnt take me long to hunt down the download link in search for the latest source.

~/code/openclonk$ hg clone http://hg.openclonk.org/ openclonk

There was a README.linux.txt in there. I read it and made sure I had all the dependencies installed (I actually missed a few).

Then I could finally run:

~/code/openclonk$ autoreconf -i && ./configure && make

After watching the compiler work for a while I got a:

make: *** [all] Error 2

Bah!
Went to the FAQ … nope, not much development related stuff there. The forums? Hmm… found irc, logging on… stating problem…

Tried ran make again, to get a shorter error message, make gave me this:

~/code/openclonk$ make
make all-am
make[1]: Entering directory `/home/mizipzor/code/openclonk'
make[1]: *** No rule to make target `src/platform/DInputX.cpp', needed by `DInputX.o'. Stop.
make[1]: Leaving directory `/home/mizipzor/code/openclonk'
make: *** [all] Error 2

After some chatting the time came for a:

~/code/openclonk$ hg pull && hg update

Then I charged ahead on with another

~/code/openclonk$ autoreconf -i && ./configure && make

The latest changeset seems to have done the trick, compile successful… now lets find a binary executable!

~/code/openclonk$ ./clonk
[21:09:22] Using XRandR version 1.3
Warning: ForEachFile with * (/home/mizipzor/code/openclonk/./*.c4p)
[21:09:22] No valid key file found.
[21:09:22] Error opening system group file (System.c4g)!

Bah! (again)
Apparently, clonk needs to be executed from within the planet subfolder. One symlink coming up:

~/code/openclonk$ ln -s ../clonk planet/clonk
~/code/openclonk$ planet/clonk

Yay! Game started… in an unsupported monitor mode… which totally foobar’d my desktop… but it starts!

If you followed this… “guide”, if i may, as a linux developer I then urge you to to add NewGfxCfgGL=1024 under the [Graphics] section in ~/.clonk/openclonk/config to start the game in windowed mode.

Happy hacking! The bug tracker is this way.

In fact, here the design looks way better than on the vapor VI which we’ve seen before. But i guess it’s because this disturbing black thing on the inner side of the boot is not visible.

Again, studs have changed. Now there are two of this “twist-studs” which looks really really cheap to me. i think for the Vapor VII/Superfly 3 it will go back to the roots!!!

Here are some pics of the new nike mercurial vapor VI, yes… SIX. Well what can i say about the boot… not very much, because the only thing on the net are these pics, which were taken for an ebay auction. What i can say from the pictures is, that now also the vapor has the lightweight studs with the holes in it AND some sort of “twist-stud” under the toebox. Looks very strange but let’s see, maybe it’s something completely revolutionary.

What else i have to say is, this is the ugliest colour combination i’ve ever seen on football boots. You know, normally I’m always saying “no, thats the first impression” or “well we all know that the boot will grow on us in time” but here it’s only getting worse the more often i look at the pics…

Pato in new colourway, but as you can see in some other pics, he seems to prefer the Vapor with cut-off lacecover

another very flashing superfly colourway is coming up

Again, the US-Player Dempsey gets his own “Superfly-IDs”