backing up my repositories, anything special needed?

[Giorgos Keramidas]

On 2007-08-10 16:22, Jens Alfke <jens at mooseyard.com> wrote:
>On 10 Aug '07, at 3:45 PM, Dustin Sallings wrote:
>> Your development style seems very aligned with mq, though.  I'll
>> add complete garbage to mq, and do so often.  mq itself can be
>> revision controlled, and *that* can be backed up using regular hg
>> tools.
> 
> I still haven't gotten my head around mq. I've read the chapter in the  
> big book, and followed threads here, and it still seems quite complex.  
> I haven't had a chance to try it out, though; that might help me make  
> sense of it.

Try it out.  It's a lot easier than it sounds, and the ability to have
'mutable changesets' as another poster mentioned is absolutely and
mind-boggingly marvellous.

These days, I can't really stand working without something like MQ any
more.  Even at ${realjob} -- where I have to use Perforce -- I regularly
pull changesets from Perforce and import them in a Mercurial workspace.
Then I use MQ to stack a bunch of personal patches on top of the latest
import from Perforce, refine these patches, work on them until they get
into a shape which I like, and then use something like:

	cd /home/keramida/hg/project

	hg export patchname > /tmp/patch.keramida

	cd /home/keramida/p4/project

	gpatch -p1 < /tmp/patch.keramida

	[ commit into Perforce ]

Then the committed patch will "loop back" when I re-import from
Perforce.

I simply can't help refusing to spend the inordinate amount of time
every-day operations take with Perforce over a slow WAN link, when
there's something as neat, elegant and fast as a local Mercurial-based
patch queue :-)

- Giorgos