Best way to manage Source Control for slightly different versions of the same codebase

I've seen this question asked several different ways and each time, the answers are workarounds or ways to not have to maintain 2 or more different versions. However, I don't think there are any workarounds given my environment (Visual Foxpro). Currently I maintain 2 different repositories:

• Live - code in production
• Proof - occasionally identical to Live but usually it is a testing ground for any of a number of new features as well as a staging area for changes to Live

I just don't see a way to handle the situation with branches because Proof spends most (if not all) of it's time looking more like a fork. For example, there is currently a large section of code that is drastically different from Live that we've been toying around with for almost a year now. There's also currently about 10 minor features that are different from Live that are in various stages of approval.

There are lots of days when I'm diff'ing and merging between the two repositories that I ask myself, why can't this be branches of the same c开发者_C百科odebase. But I just don't see how that's possible. Proof is a living breathing thing of it's own that I need to be able to compile and maintain separately from Live (though I realize there's nothing in that last statement that precludes a single codebase, which is my dilemma).

Am I right that Proof is really more of a fork and therefore has to be maintained in a separate repository?

BTW, not that it matters so much to the question, but my VCS of choice is Mercurial.

---

The way that we do it in my shop is to use default and stable branches to keep code that is actually released (live) separate from stuff that is being worked on.

In addition to the named branches, we have a clone for each new feature/addition that is substantial. We're just a bit more comfortable with that than having multiple heads on the default branch.

Keeping the state of code that has been released to production in its own named branch helps eliminate accidents. Instead of being able to mess up the Live repo by simply pushing something that isn't ready, you have to explicitly merge those changes over to the Live branch.

---

I don't know how well this applies to your exact situation, but can you keep each of the running changes as a separate branch, and have Proof be the current Live with all of those extra branches merged in? Then it will serve as a very forward-looking integration check, and you'll also know that each branch should be mergeable to Live (assuming it doesn't depend on stuff that hasn't been merged yet).