user-avatar
Today is Saturday
February 4, 2012

Tag: mercurial

November 14, 2011

New lightweight admin-oriented linux kernel mercurial mirror

by Thomas Capricelli — Categories: Admin, Gentoo, Linux kernel — Tags: Leave a comment

On most servers I’m responsible for, I use to compile my own kernels. Instead of downloading/applying patches, which is cumbersome, I was using the (now broken) mercurial mirror http://www.kernel.org/hg/linux-2.6
It was great as i just had to do something like “hg pull -u; hg up -r v2.6.xx” to update my tree.

Though, this has several drawbacks, and among them some very important:
* the minor versions are not there, such as 2.6.xx.y
* the repository cloning is worth 2.1G, not including the checkout
* you need to specify the tag to get a stable kernel
* the repository contains all intermediate versions, which slows down updating both from network and local checkout.

The first point is the one what bothers me the more. For example at some given date, say the 2.6.39 is not yet released, the last version available in the hg mirror is 2.6.38, although 2.6.38.6 is available. So I  still need to manually patch my checkout because I think 6 minor stable versions are worth having.

My solution to this is a script that I’ve called by the pretty name of eudyptula (this is a very small penguin..). Eudyptula automatically (using cron) updates a mercurial repository to the latest ‘stable’ version of the linux kernel, according to what is found on the official ftp server. The result is here:

https://bitbucket.org/orzel/linux-kernel-stable

The repository clone weights only 220M (excluding the checkout, on my ext4 partition), and contains only one changeset for each update from a stable version to the next. ‘hg pull -u’ is enough to get the latest stable source. Hence the name.

A typical history will look like

* 2.6.38

* 2.6.38.1

* 2.6.38.2

* 2.6.38.3

* 2.6.38.4

* 2.6.38.5

* 2.6.38.6

* 2.6.39

* 2.6.39.1

and will drop any 2.6.38.x release that could appear after 2.6.39 is released.

As a convenience, I’m also tagging versions the same way they are tagged in the official git/mercurial repositories (‘v2.6.38.4″ for example).

Of course, it does NOT makes sense to use this repository if you intend to do kernel development. It is supposed to be used  readonly.

This is a long term project. As of today (november 14th, 2011), I’ve been using this for updating ~10 servers for the last 9 months. I intend to maintain this clone for long, checking and fixing problems if they ever occur.

If there’s enough interest, I could do another mirror for the long-term support versions. Though those versions, officially created and maintained by kernel developers, are not as formally described, and this is more difficult to do from a cron job.

September 18, 2011

A small step forward for the mercurial activity plugin, releasing version 2.0

by Thomas Capricelli — Categories: Admin, Gentoo, KDE — Tags: , , Leave a comment

As time goes, my mercurial ‘activity’ plugin has got more and more options. Useful and requested options of course, but still it kinda clobber the –help output and it is more and more cumbersome to play with. This is why I have introduced a new frontend, based on Qt, to play/decide about those options.

First, let me issue a very strong statement: this is optional and it is still possible to use the extension in an desktop-less environment (aka a server). This is an important point as many people, including myself, use the extension to provide activity information on some html page, maybe even integrating with the mercurial web interface.

So how does it work ? The extension now has a new option –mode. There are currently three possible values:

  • file: this is the previous behaviour, and is the default value. A image file is created and it exits.
  • display: this opens a window with the activity graph, using matplotlib, you can not change anything.
  • gui: this opens a full-fledge window, where you can change options and see ‘in real time’ how the graph changes.

This looks like this:

You’ll notice that the bottom of the window contains the corresponding command line, that you can copy/paste.

Last thing: the extension is now a python module, and as such, the way you configure the extension in your ~/.hgrc has slightly changed. Instead of having

activity=/home/orzel/hg/hgactivity/activity.py

you should now have

activity=/home/orzel/hg/hgactivity/activity

April 7, 2011

Mercurial mirror for Django stable branch 1.3

by Thomas Capricelli — Categories: Admin, Django — Tags: , , 4 Comments

Django recently released the 1.3 version, and as such a new ‘stable’ branch was created in subversion. As I did for the 1.2 branch, there’s now a mercurial mirror, following the 1.3 branch. It is updated every (european) night.

The 1.2 mirror is not removed, it is still running and maintained.

The url for this new mirror is http://bitbucket.freehackers.org/django-1.3-mirror

September 9, 2010

New mercurial mirror for Django stable branch 1.2

by Thomas Capricelli — Categories: Admin, Django — Tags: , , Leave a comment

I have tried for the last few years to use one of the mercurial mirrors on bitbucket.org to follow Django. Since far before Django 1.0 was released, I was following trunk, but I have switched to the stable branch around Django 1.1.

I’ve always had problems with the mirrors on bitbucket, they seem mostly unmaintained. There are several of them, mostly because they create a new one when one fails… so you have to guess which one is the ‘current’ one. As of today, the one I’m using has not been updated for one month,… and I would like to merge the recent important security fix to my own Django branch (that I use for my Consulting jobs).

So I decided to create, and maintain, a mercurial mirror of Django stable, which is 1.2 currently. I publish it on

http://bitbucket.freehackers.org/django-1.2-mirror

and it is updated nightly.

The history/log only starts at the 1.2 branching in svn, which allows to keep the mirror size very small. For comparison, the “.hg” directory was worth 130Mb using the mirror provided by bitbucket staff, and this one is 17M.

June 15, 2009

tags displayed in hg activity extension

by Thomas Capricelli — Categories: Admin, Gentoo — Tags: , 2 Comments

Today i have added a feature to my hg activity extension. I have wanted to have this for long : the tags are now displayed on the graph. Here are two examples, one of the project itself, and another one on the mercurial repository, but only  for the last months.

The first one was generated by:

hg activity --splitauthors --maxauthors 5 --width 1500 --height 900

hgactivity

And the second one by:

 hg activity --datemin 2008-01-01 --splitauthors --maxauthors 5 --width 1500 --height 900

mercurial

May 18, 2009

feedback about converting eigen2 to mercurial

by Thomas Capricelli — Categories: Admin, KDE — Tags: , , 6 Comments

This week-end we did the final conversion of the eigen2 source code repository. I shall describe here the few problems we had, as a feedback to the community.

Eigen original purpose was to help provide linear algebra for several KDE parts. As such, it was until now developed inside the KDE repository, which (still) uses subversion. Let it be clear that KDE did a wonderful job at hosting eigen repository, even though several accounts needed to be created for people who only contribute to eigen and not KDE as a whole. Eigen is getting big enough to live and release its own way , but eigen keeps very strong relationships with KDE.
Here is the script that was used for the conversion. The version of mercurial (and of the mercurial convert extension) was 1.2.1.

hg convert https://orzel@svn.kde.org/home/kde \
    --authors eigen.authors \
    --config convert.svn.tags=tags/eigen \
    --config convert.svn.branches=branches/eigen \
    --config convert.svn.trunk=trunk/kdesupport/eigen2\
    eigen.hg

We faced several problems. Fortunately all but one could be resolved patching python code. That would have been a lot more difficult using, for example, git. Speaking of git, we have found no easy way to make such a conversion, mainly because KDE repository is so huge and it seems git needs to parse the whole history of the whole repository just to convert this part. Eigen is quite small. It took mercurial two hours to convert it, almost all of which was due to network latency between my computer and KDE repository.

Bad default branch name

In mercurial, the default branch name is ‘default’ (same as ‘trunk’ on svn). If you browse a mercurial repository (using the wonderful tck/tk frontend or the web browser), each changeset is tagged with the branch name (and with every tag name is there is any). There is an exception to this, if the branch is ‘default’, nothing is displayed, as a convenience for clarity. Which is great. Using the script I present here, the convert extension would create a branch according to the name of the branches/ subdirectory, which is fine. Though the name for the main branch, the one called ‘trunk’ in svn and usually called ‘default’ in mercurial, was named ‘eigen2′ here, probably because the main directory was named this way.

I have found no way to prevent this using command line arguments. I have tried to play with the –filemap option, but failed. The final solution I used was to locally patch my mercurial (yes, I know, this is ugly):

--- /usr/lib/python2.6/site-packages/hgext/convert/subversion.py
+++ hgext/convert/subversion.py
@@ -777,6 +777,8 @@
                 branch = self.module.split("/")[-1]
                 if branch == 'trunk':
                     branch = ''
+                if branch == 'eigen2':
+                    branch = ''
             except IndexError:
                 branch = None

Bad branch used to save the tags file

In mercurial, tags are created by updating a file called ‘.hgtags’ which maps changesets (identified by their md5 sum) to a string. At the end of the conversion process, ‘hg convert’ will create such a file and check it in the mercurial repository. Unfortunately in our case, the file was not created on the right branch neither, so I also had to patch mercurial for this :

--- /usr/lib/python2.6/site-packages/hgext/convert/hg.py
+++ hgext/convert/hg.py
@@ -178,7 +178,8 @@                                                                                                   

          self.ui.status(_("updating tags\n"))                                                                       
          date = "%s 0" % int(time.mktime(time.gmtime()))                                                            
-         extra = {'branch': self.tagsbranch}                                                                        
+#         extra = {'branch': self.tagsbranch}                                                                       
+         extra = {'branch': 'default'}                                                                              
          ctx = context.memctx(self.repo, (tagparent, None), "update tags",                                          
                               [".hgtags"], getfilectx, "convert-repo", date,                                        
                               extra)

Spurious file from old history

Once the conversion was done, we noticed a file called src/Core, which should not be here. A diff with a svn checkout would confirm that this is the only difference. I have traced back the problem to a bug in svn which would allow a ‘svn copy’ to be done even if the destination name would already exist.

In our case, a directory called ‘Core’ was copied on top of the file ‘Core’. As such, the underlying file was never deleted, and mercurial kept it. Mercurial did quite well dealing with this actually.

See this wonderful commit

http://websvn.kde.org/?view=rev&revision=72256

And this is how the repository looked like just before this commit:

http://websvn.kde.org/branches/work/eigen2/src/?pathrev=72254

We could not manage to fix this problem, and we just removed the file after the conversion. Having this file would anyway not prevent using eigen2 in compilation.

It seems the bug is fixed in svn 1.6.2:  I can not reproduce this on a small test svn repository. A bug was filled for mercurial with all details, but as we cannot reproduce this behaviour on a test svn repository, this will be very difficult to solve. We for sure can not use KDE repository to test, it is far too huge for this.

Conclusion

We now have eigen2 repository on https://bitbucket.org/eigen/eigen2/ and so far everything seems ok. The repository is worth 7.3 Mb, which is perfectly honest. We can now grant or revoke write access very quickly and easily without disturbing KDE admins. And of course we also have all the wonderful advantages of DVCS.

May 7, 2009

mercurial and ipv6

by Thomas Capricelli — Categories: Admin, Gentoo — Tags: , Leave a comment

Today I needed to use mercurial over IPv6 in order to share a repository which is on a computer behind an (ipv4) firewall, but that can be reached over ipv6.

The naive

  • hg clone ssh://orzel@ipv6computername/hg/dir
  • hg clone ssh://orzel@[ipv6::address]/hg/dir

miserably failed. But i was hinted on IRC (thanks ‘Ry4an’ !) on how to do this, and thought I should share this knowledge until mercurial get better ipv6 support.

First for the clone call, do

hg --config ui.ssh='ssh -6' clone ssh://orzel@ipv6computername

then you will not be able to push/pull until you add to the repository .hg/hgrc the lines:

[ui]
ssh=ssh -6

Enjoy mercurial on IPv6 :-)

November 14, 2008

Mercurial bulk update

by Thomas Capricelli — Categories: Admin, Gentoo, KDE — Tags: 6 Comments

I don’t know about you, but I have on a lot of different places a directory called ‘hg’ with lot of different mercurial clones inside. Whether on the home of my several computers for my own projects, or inside other directories for external projects, and so on.

Now, remember one important aspect of distributed source control : your clone is actually both a repository and a working directory. This is why you usually (git and others do the same) have two different commands : one to synchronize the  repository (pull) and one to update the working directory (update).

Updating comes with a risk : you can have conflicts. This is why I never update a svn repository without thinking first (do I have local modifications ?). But pulling is a lot less problematic. And, especially on my laptop, I often want to ‘sync them all’ as soon as I have some internet connection. Until now i had a script syncall with the path of all (svn,unison and) mercurial repositories hardcoded. This does not scale, and I now need that in at least 5 different places. I dont feel like maintaining such scripts.

And now comes the magic alias that made my day. I’m usually lame at shell scripting, so I’m sure there are better ways. But it works, now, on my computer. And this is so useful.

alias hgbulk '\ls */.hg -d | cut -d\/ -f1 | xargs -i bash -c  "(cd {}; hg pull )"'

(yes, I use tcsh, but i’ve tested that in bash too. Don’t ask why I use tcsh.)

November 2, 2008

Activities gallery

by Thomas Capricelli — Categories: Admin, Django, Gentoo, KDE, Linux kernel — Tags: , , , , , , , 3 Comments

While developing my recently released activity mercurial extension (and here too), I did a lot of tests on some quite famous/big projects. I’ve found the results to be quite interesting and decided to put up this gallery. Are you interested in the history of commits for kde, linux, django, portage(software), and others?

warning : this is just for fun (copyright Linus Torvalds), I’m perfectly aware that the number of commits is a very bad indicator for development.

The gallery : http://labs.freehackers.org/projects/hgactivity/wiki/Gallery

October 31, 2008

Splitted activity for mercurial

by Thomas Capricelli — Categories: Admin, Gentoo — Tags: , Leave a comment

Today I have added new options to the mercurial activity extension and  most importantly, it is now possible to have a different curve for each author. It looks like this :

© 2012 Thomas Capricelli All rights reserved - Wallow theme v0.46.5 by ([][]) TwoBeers - Powered by WordPress - Have fun!