Current viability of share

Gregory Szorc gregory.szorc at gmail.com
Wed Jun 25 22:00:48 UTC 2014


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



More information about the Mercurial mailing list