Mercurial topology in three stage implementation

Question

A few years ago, now, we had a chap working with us who introduced the following topology for Mercurial...

The main repository server obviously holds the primary repositories, as you'd expect, but the the required repo is cloned to a local repository, and from there into one or more working folders.

I've never seen this method before or since. Most of my colleagues tend to use a simple approach of cloning from the server directly to the working folder.

Are there any pros or cons (besides potential unnecessary complexity) to this approach, or why it should be implemented in such a way? I did attempt to look for this approach online but found nothing.

Answer 1

I can see the value of having multiple local working copies for various reasons, but I don't see what the point of the middle "tier" is if everything pictured is a true clone.

Having multiple working folders is useful because it allows you to segregate tasks from each other - each of the "work" repos could be a different branch, or could be for a different task even in the same branch. For instance, you might be using one to track down a defect while other work is in progress elsewhere. I do this sort of thing all the time.

The reason the middle tier seems needless is because each of the "work" repos could push/pull directly back to "server". But doing it through the middle tier requires extra push/pull steps.

---

Now, another interpretation depends on how strictly a clone is a clone in the diagram. Mercurial also has a "share" command (extension) which behaves similarly to clone but does not actually duplicate the entire repo history, but instead utilizes one copy of it for multiple working folders. These "shares" push/pull just as if they were cloned normally. So if the "work" repos were created by using hg share then indeed there are benefits - they will be quicker to create, and use far less disk space.

In other words, it would be hg clone from "server" to "local", and then hg share from local to "work".

This is the only good reason I can think of specifically for the arrangement in the diagram.

---

Personally what I do is a little simpler:

I just designate one of my local working copies as the actual clone of the server, and then share that to as many other copies I need. I think this is as lightweight as you can get, without sacrificing any flexibility.