On 09/23/2016 02:30 AM, Jun Wu wrote:
Excerpts from Pierre-Yves David's message of 2016-09-23 02:01:11 +0200:

On 09/22/2016 10:09 PM, Jun Wu wrote:
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.

One could definitely consider it. I've never been thrilled with having
the topic as part of the hash. I agree if makes it more heavy weight
that I would like to create and rename them. Not having them part of the
hash with part of my initial criteria for a lightweight solution.

However, when Matt, Augie and I were discussing topic somewhere in
Minneapolis last year, Augie made a good case for storing them in the
changesets at least until someone come with something better. Having
them part of extra is solving many of hard problems right away:

* We already how to discover and exchange them (just reuse changeset and
named branch discovery)

* We already can track history of changes (just reuse evolution related
data)

* We can handle rename, cyclic rename and and divergent rename (just
reuse evolution related feature set).

I think the following is the major disagreement. (this also applies to other
emails)

Is the exchange thing the desired behavior? Or, should topic be global or
local? I'd prefer the later, because 1. this is *D*VCS and people should
have freedom to name things whatever they want. 2. topic names do not affect
the actual content.

The exchanged is not only a desired behavior, it is a -required- behavior. The main motivation being solving the feature branch struggle and topic as a solution is to offer a way for people to identify feature branches they exchange. This is central and extremely important. Solution that does not fill this needs fully are not solution :-)

Consider the following example:

1. Alice makes 3 commits under the "smartfixup" topic.
2. Bob pulls from Alice, got those 3 commits.
3. Bob dislikes the "smartfixup" name, and renamed the topic to "tidy".
4. Bob adds a typo fix commit. Of course, it has the topic name "tidy".
5. Alice pulls the typo fix from Bob. Suddenly all commits get rewritten
   to use the "tidy" name.
6. Alice dislike the "tidy" name, and thinks wtf you renamed *my* topics...
7. Alice dislike the behavior.

I would clarify this as a "human and workflow issue" This does not only apply to topic. Bob could be pull Alice and rename all the variables. (Or even worse, rewrite the whole project in Ruby!).

People should not mess around with other people Changesets without prior consent (or explicit workflow) and it is likely that we implement some (friendly) barrier to have people think twice about it. But this is something human being need to sort out between themself.

In the same way large organisation will probably want to define and enforce naming scheme for topics. But they already need to do so today for named-branch of git-branch. So nothing specific to topic here.

Cheers,

--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to