Mercurial bulk update
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.)
Post details
- Categories: Admin Gentoo KDE
- Published: November 14, 2008
Why do you use tcsh? :-]
dude, just use the forest extensoin. your command line is then replaced by this:
hg fpull
done.
illogica-al: because
kevin: to use this extension you need to 1)configure hgrc 2)create yet another global repository, and this on all computers and such, this is too heavy.
Moreover the extension is not as stable as I want, it’s more or less being rewritten…
ah, ok, I don’t agree with 1 or 2, but that’s ok. 🙂 (1: add one line? ‘hgext.forest=’ do you not use any other extensions at all? it’s pretty easy. 2: so what? the global repo has no commits. just run hg init in the top of your tree where all your repos are, and you’re ready to run hg fpull)
the more interesting part though is that the forest extension is being rewritten. I was actually getting concerned because there have been no new commits to forest in like 9 months or something. do you have any pointers to where the new activity is happening? thanks
oh, I found it. it appears to be not a rewriting of forest, but fixes to make it work with the newer 1.0+ versions of hg; there are only two commits past the ‘old’ forest development. but it does work fine with the newest mercurial. I’ve been using forest forever, both the way you want to use it, and also for working trees containing about 5 shared repos.
http://bitbucket.org/pmezard/hgforest-crew
Hello
I’ve used a simple, coherent setup since the very first days I began using Mercurial: all of my clones are in a directory, conveniently exported as $hg in my shell, and for each project I want to track I create $hg/project with this layout:
clean: pristine clone (without working directory)
*: clones for doing stuff
build: where I pull everything, update and revert as needed, and run setup.py or make
This way, a simple shell function can walk $hg and run hg pull -R $item/clean. I’ll have to factor out the bits that execute a hg command on multiple repositories.
However, I’m going to break this shortly because I have too many projects and I want to distinguish stuff I just want to have and stuff I want to code on. Still, this won’t clutter my whole filesystem.