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