Would an additional "push -f"/backup-only Mercurial repo work?

Question

We've set up our own Mercurial workflow which works great for us. However I'm wondering about something: is it possible to create some "junk" repository that would basically be a place where every user could always "push -f" their changesets and where we'd never do anything besides "push -f"?

That is: the goal of that repository would not be to integrate/merge/pull. Actually it would not be part of our workflow. It would really just be a "place to backup all the changesets".

The only moment we'd retrieve a changeset from it is if a user got a hard disk crash or a theft and had changesets that he "pushed -f" to this hypotethic "changeset backup" repo but not to the repository(ies) part of our real workflow (there'd be plenty of reason why this would happen: one of them being that keeping an always accessible "unverified" junk repository always available would be very easy).

I just did a test with three users doing "push -f" and now it looks like the following (note that the parent of the working directory stays at the very bottom, at changeset 0, and would forever stays there):

$ hg glo | grep -v user: | grep -v date
o  changeset:   3:4337a665659f
|  tag:         tip
|  parent:      0:ab3e3171d569
|  summary:     1st change by user B
|
| o  changeset:   2:2349e3eed60d
|/   parent:      0:ab3e3171d569
|    summary:     1st change by user C
|
| o  changeset:   1:10405f5e0994
|/   summary:     1st change by user A
|
@  changeset:   0:ab3e3171d569
   summary:     Init

Would this keep working once users starts pulling from other repositories, merging their work, etc.?

In other words it would be a repositories where resolving merging issues wouldn't be a concern and where "push -f" and creating new heads would be very welcome and where the working directory's parent would always stays at "changeset 0". It's only goal would be to serve as "changesets backup" folder (for example to backup changesets that haven't been integrated yet in our real workflow).

Would this work and does this make any sense?

(note that should this not make any sense wouldn't make the question less interesting, other people may want to do exactly this and then may want to find why it wouldn't make sense)

Answer 1

Yes, it would work just fine. Your 'junk' repository would just end up with a ton of heads.

You can use hg pull -r to retrieve a particular changeset (and all of its ancestors) from the junk repository, so you won't have to worry about ever having to merge together all that cruft.

Now, keeping track of which changeset is which, and which one you want to pull in order to restore something you've lost is a harder question. You can look at the tree, but that tree is going to get complicated and bushy with lots of heads. It can still be done of course, it's just not necessarily trivial.

If you use some of the hooks to keep a log of when changesets were pushed and where they were pushed from, that should help you find the one you want when it comes time to recover things.

Answer 2

The usefulness of any backup method can only be measured by the ability to restore. In this case, I don't think you'd have an efficient restore route.

Apologies if this isn't the answer you're after since you've already a workflow in place, but another way to handle backups is by having each developer clone the 'main' repository on the (presumably backed-up) server and then pulling from that clone. They then push back to 'their' clone on the server as often as they want and only promote the changesets to the main repository as required.

This will get the changesets on a central server somewhere and make the restore more straightforward as each developer's changesets are isolated.

The other option I'm sure you've considered is a separate backup process for local developer's PCs. Perhaps something automated and in the background like Carbonite?

Hope this helps.