Current viability of share

[Angel Ezquerra]

On Thu, Jun 26, 2014 at 12:00 AM, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> It is common at Mozilla for people to juggle multiple clones of the Firefox
> repo(s) so that they may maintain multiple source
> directories/checkouts/working copies for different lines of work. For
> example, people will have one checkout building feature X while actively
> developing feature Y in another checkout.
>
> This introduces a synchronization problem and the overhead associated with
> it. A lot of people complain about it. The scenario seems to be screaming
> for the utilization of the "share" extension.
>
> However, share is not viable for people doing history rewriting, which is
> anyone using mq, rebase, histedit, etc.
>
> In theory, changeset evolution + obsolescence markers could lead to stores
> being append only a thus compatible with share, even in the face of history
> rewriting.
>
> What scenarios, if any, will cause an evolution user to strip store data,
> causing incompatibilities with share? Also, I'd appreciate clarification on
> whether using share locally for active development scenarios (as opposed to
> pull only "headless" scenarios) is a goal.
>
> Gregory

In my experience the share extension is not _that_ fragile when you
rewrite data. The worst case is when you edit or strip an ancestor of
the working directory of one of your shares. In that case a simple
update --clean will usually "fix" the shared repo state. Usually you
don't even need to do that. A call to hg debugsetparents can also do
the trick.

Cheers,

Angel