Entries tagged mercurial

I'm still in the middle of a quandry with regards to revision control.

90% of my open code is hosted via CVS at a central site.

I wish to migrate away from CVS in the very near future, and having ummed and ahhed for a while I've picked murcurial as my system of choice. There is extensive documentation, and it does everything I believe I need.

The close-runner was git, but on balance I've decided to choose mercurial as it wins in a few respects.

Now the plan. I have two options:

• Leave each project in one central site.
• Migrate project $foo to its own location.

e.g. My xen-tools could be hosted at mercurial.xen-tools.org, my blog compiler could live at mercurial.steve.org.uk.

Alternatively I could just leave the one site in place, ignoring the fact that the domain name is now inappropriate.

The problem? I can't decide which approach to go for. Both have plusses and minuses.

Suggestions or rationales welcome - but no holy wars on why any particular revision control system is best...

I guess ultimately it matters little, and short of mass-editing links its 50/50.

Tags: chronicle, cvs, cvsrepository, git, lazyweb, mercurial, todo | No comments

Thanks for the comments/mails on my previous post.

I've now started the migration properly.

All code currently held upon cvsrepository.org will be moved to http://repository.steve.org.uk/ - a nice system-agnostic name.

So far I've only setup the pages for two project (my dotfiles and ~/bin) but I'm happy with the process, and the naming scheme appears sane to me now.

Using sub-domains I need only install one CGI which is a big win, and using a simple set of templates + mod_rewrite all projects get the same look and feel.

I've still got to tweak the stylesheet a little, but otherwise I'm happy with things. I can host both public and private repositories, and that all works magically.

Of course the huge win is no longer needing to run a pserver for CVS! All future checkouts will be via HTTP, and the rare few people with commit access will be able to do so over SSH.

Once things have been migrated I'll cause the cvsrepository names to redirect to the new locations, and keep that up until the domain expires as a transition period. (I think +1 year :))

The other job for the weekend is releasing a fixed security update for Samba, to fix the regressions.... That is in hand, but the buildds are being slow. If they're not all done I'll release it anyway today/tomorrow. I'm annoyed that I handled the timing so badly, but I hope that people don't hate me for it.

Tags: cvs, mercurial, migration | No comments

If you have a (public) revision controlled ~/bin/, or bash/shell scripts I'd love to see them. Feel free to post links to your repositories as comments.

I'm certain there are some great tools and utilities out there with I could be using. Right now the only external thing I'm using is Martin Krafft's pub script. I don't use it often, but it is very neat and handy when I do want it. (Something that I'd never have considered writing myself, which suggests there are many more gems I'm missing!)

In other news my migration to mercurial is going extremely well. With only minimal downtime. Downtime for services really comes about because I have several websites which are powered entirely with a CVS checkout of remote repositories, so the process looks a little like this:

• Convert CVS repository to hg.
• Archive "live" CVS checkout from the server.
• Move the local CVS checkout somewhere temporary.
• Checkout from the new mercurial repository.
• Fix any broken symlinks.
• Do a recursive diff to make sure there are no unexpected changes.
• Remove the previously archived local CVS checkout
• Done!

Tags: cvs, lazyweb, mercurial, migrations | No comments

My migration to mercurial is now complete. I've completed the last step, which was the migration of all the $foo-commits mailing lists.

It is at times like this that I remember two things:

• All mailing list software sucks. (here we go again.)
• All the mailing-list-archive-makers suck.

Right now I'm using ecartis for my mailing lists, primarily because it isn't mailman. (Long story).

For making archives of mbox files I'm using hypermail.

The latter I intend to change as soon as I can find something else to use. It isn't attractive, but it is in the Debian archive and seems reliable.

Since I was changing things around already I've centralised the list-archive making, and started using the haschanged tool to avoid rebuilding the archives i there are no new posts. That works nicely.

Tags: cvs, ecartis, hypermail, lists, mailman, mercurial, migration | No comments

OK so I've knocked up a simple blacklist:

• http://blacklist.steve.org.uk/

The source code behind it all is open.

Currently it is setup to import IPs which denyhosts has downloaded every hour, and it will also receive updates from several systems under my direct control.

If you wish to begin submitting your own reports you may get in touch, or read the documentation in the source repository. I'll document that on the site itself publically in a couple of days.

So far I see several people have rsync'd my zonefile a few times. I guess the domain name was a bit predictable.

ObFilm: The Great Muppet Caper

Tags: blacklist, mercurial | 6 comments

If you've been following new releases you'll see there is a new Firefox browser out, version 5.0.

This will almost certainly make its way into Debian's experimental tree soon, but that doesn't help users of the Debian Stable release. The only sane option for those users (such as myself), without a backport, is to install locally.

So I did the obvious thing, I made /opt/firefox then installed the binary release into it. Then I found that it was good, lovely and fast.

Unfortunately the system firefox and the local firefox are not really compatible. Run the local one, then click on a link in the gnome terminal and it wants to open the system one. Ho hum.

The solution:

• Remove your local firefox & iceweasel packages.
• Create the shell scripts /usr/bin/firefox & /usr/bin/iceweasel to exec the one stored beneath /opt.
• Rejoice.

Of course this being Debian we don't want to do that. So instead here is a package that will let you do that:

• http://firefox.repository.steve.org.uk/file

Download. Build. Install. If you install your local package to a location different than /opt/firefox update the configuration file /etc/firefox/firefox.conf to point to it.

Possibly useful?

ObQuote: "I could help you cross your yard." - Up

Tags: firefox, iceweasel, mercurial | 15 comments

Once upon a time a company started using distributed version control, and setup several project repositories using darcs.

Over time people became more sane and new projects were created in mercurial.

Later still Git became available, and was used by a few of the brave.

Sadly each of these projects is hosted on the same host, and in the home directory of the same user. This means these two commands work:

hg clone ssh://projects@dev.host/foo

git clone ssh://projects@dev.host/bar

I'm now wanting to setup per-repository ACLs and have hit a problem...

There are several git-wrappers such as gitolite and gitosis. There is also the excellent hg-gateway and mercurial-server for dealing with mercurial.

However I've yet to find a wrapper which will handle both git & mercurial repositories, under the same UID. (+ Darcs too, of course).

So my question - is there such a beast out there, or do we need to write it? I expect such a thing would be useful for many people, so I'm surprised I've not yet found it.

Tags: git, lazyweb, mercurial | 12 comments