(share extension) Am I about to shoot myself in the foot?

[Jensen, Aaron]

> Just discovered the "share" extension.  This *looks* like exactly what I want:  different working directory states, but only one DAG.  I 
> don't use strip, rebase, or any of the other "revisionist history"
> commands (sorry, couldn't resist).  Tagging and branching should be okay... what about bookmarking?  What happens if I am in a 
> "shared clone" and push to an offsite repo?  

All commits made in all your working copies get pushed. If you don't want this, you can specify a specific revision to push and it and all its ancestors will get pushed. If it's important that certain changes stay local and not get pushed inadvertently, I would say not to use the share extension or use phases to mark changesets private that aren't ready yet (see `hg help phase`).

We use the share extension on each developer workstation to share a large (7GB, 100,000 files) repository across three working copies, which represent three major releases we do a year. We have hooks in place that enforce merging forward from old release branch to newer release branch. Essentially, all changes get pushed all the time. Using the share extension saves each dev 14GB of disk space, and makes merging forward much faster. Instead of updating between branches (which takes minutes ), developers `cd` into the working copy representing the newer release, and merge forward. We love the share extension.


> What happens if I want to do a regular clone operation from a shared repo, is that even 
> supported?

I believe so, yes. Since the shared repo points to a real repo, it would just clone the real repo and all the changes in it. Should be easy to confirm with some hg init/add/commit/share/clone commands.