news from the topic experiment
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Thu Sep 22 20:18:48 EDT 2016
On 09/22/2016 11:12 PM, Jun Wu wrote:
> Excerpts from Sean Farley's message of 2016-09-22 13:54:22 -0700:
>> Jun Wu <quark at fb.com> writes:
>>
>>> Could we consider storing the topic of a changeset elsewhere so it's not
>>> part of the changeset metadata? This will make it more lightweight and
>>> help preserve hashes with remote peers.
>>
>> I assume this is along the spirit of your 'hg undo' for evolve (that
>> preserves the hash)?
>
> No. We are thinking about using topic to replace bookmark as the recommended
> workflow at fb. People can get confused if local bookmarks point to public
> changesets.
I would be happy to discuss that ;-)
> Having topic in commit metadata makes it hard to rename them, and they are
> not fundamentally different from branches imo - i.e. we can probably also
> make branches work like the current topics implementation with a some tweaks
> - does not seem to need a fresh new concept.
No, we want both named branch and topics. They are and important
difference in life-cycle and therefor semantic. One of the main issue
with bookmark is their life-cycle. Having life cycle expectation
(mutable life only) built in the topic design is important here. And
then we still need named-branches for more long-lived target.
> Conceptually, I think (I may be wrong) this is a lightweight way to specify
> a set of changesets, like the common "tag" concept to changesets. And it
> should be easy to add / remove a "tag" to / from a changeset easily.
(I know I'm repeating myself from the previous email, but better safe
than sorry).
Defining the set locally is not too hard. But all the exchange part is
much harder. You have to handle the distributed aspect of DVCS with all
the possible renames (possibly divergent renames) and other related
cases. And that is the very hard problem that we can just make vanish by
reusing all our solution regarding changesets.
Cheers,
--
Pierre-Yves David
More information about the Mercurial-devel
mailing list