Hobu proposed motion to migrate libLAS source code repository from Subversion to Mercurial. The motion has been approved and Hobu completed the mgration.
In order to check out libLAS source code from the new repository, issue the clone command:
hg clone http://hg.liblas.org/
The libLAS Trac has been re-configured to make the new repository browsable. Alternative Web-based interface is available at http://hg.liblas.org/.
After diversity of operating systems, diversity of versions of diversity of compilers and forks of forks of favourite…forks of projects, contributors to the world of Free and Open Source Software got Yet Another Nail in Their Asses (YANTA with tm by myself). It is the variety of revision control systems and their clients developers need to install to be able to do their job. In the past the choice was clear CVS and later Subversion.
Today, DVCS is posh. So, an average developer who wants to contribute his cheap liberty to number of Open Source projects, will likely have to juggle clients to three or four kinds of the posh revision control systems.
For Windows systems, we have the whole population of turtles on the land: TortoiseSVN, TortoiseGit, TortoiseBZR and TortoiseHg (hopefully, none of them are listed as endangered species). The stack of these turtles causes the context menu large enough to make it hard to use on small screens. Combinations of authorization systems, configuration files and mess with Putty and MinGW/MSYS dependencies…make participation in this whole libertinism ridiculously complex.
I’m really surprised no one of the Tortoises hackers have come to the conclusion that it would be not a bad idea to merge their efforts and develop single client capable to work access repositories of all the four types of systems. Of course, with single installer and one submenu in the Windows Explorer’s context menu. Ah, and please don’t forget about including command line clients too :-)
When working in a team and maintaining large source code repositories, it’s easy to forget to set svn:keywords property for newly added file or update the property when adding new keywords to files.
The first solution that may come to once mind is to involve cron job or define post-commit hook. The former is easier to setup but may be unsafe if commits are allowed by authenticated users. The second option seems appealing as we can avoid authentication problems, but it’s generally not recommended to set properties from a hook. See warning in red frame in the Hook Scripts chapter of the SVN book.
After short discussion with folks on #gdal IRC channel, we have came to the conclusion that the easiest and safest option will be to periodically run a script fixing the svn:keywords where needed. Such script will be executed by team members on their local machines and against working copy of GDAL sources. This way we assure that the commit process is well authenticated and under human control :-)
So, here is the script – svnkeywords.sh (backed up here here):
$ ./svnkeywords $HOME/dev/gdal/_svn/trunk Entering '/home/mloskot/dev/gdal/_svn/trunk' Setting svn:keywords property........done.
It is quite generic and can run against any sources tree maintained by Subversion. The only requirement is Unix OS with toolset like /bin/sh, find and grep. Happy using!