Differences between revisions 9 and 10
Revision 9 as of 2015-06-03 04:33:26
Size: 4584
Comment:
Revision 10 as of 2015-06-03 04:58:08
Size: 6005
Comment:
Deletions are marked like this. Additions are marked like this.
Line 51: Line 51:
'''Life cycle''' of bookmark are problematic because we still have not figured out a proper way to handle deletion and renaming. So once they are in the wild, it is very hard to get ride of a feature related bookmark. Not sure if remote-bookmarks improve that a bit.

'''distributed''' is okay-ish for the in-core bookmark. The current behavior on pull work in a distributed ways as it will exchange any bookmark alongside their changeset. However behavior on push is more problematic as local bookmark may not be pushed, and Mercurial may warn about it or not depending unrelated condition. The 'remote-boomarks' change is more problematic in this aspect as remote name are not propagated so changesets can get exchanged without there topic information.

'''tracking''' is not covered at all by current core version. It is introduced with 'remote-bookmark' but only cover rebase, the UI to setup and observe tracking is unclear to me yet.

'''defined set''' bookmark can implicitly define a set of revision since everything 'only' under that bookmark it can be considered in the topic. This have issue with:

 - Requires the use of bookmarks for the main branches too.
 - Misbehave if a some part of the topic is shared with another bookmark (or anon heads)
 - Bad handling of extra anonymous heads on the same topic.
 - ill defined behavior when push only half of a topic (who does not hold the bookmark)

Note:

This page is primarily intended for developers of Mercurial.

A plan for light weight branching/categorization what would work with other Mercurial principle and actual DVCS idea.

Still a very early prototype stage.

Background

Mercurial have been struggling for year to define a nice way to handle 'topic' branch (also called 'feature' branch) especially when it come to exchange them with other people (eg: for pull request).

1. Constraint

The main challenges to get such feature right are:

- Life cycle:

  • grouping/naming the topic branch is usually only relevant while working to get the feature done. We need a natural/efficient way for the topic to fade away when feature are complete.

- Distributed system:

  • Mercurial let arbitrary number of changesets to interact with each other the way they want, include pulling changesets through a chain or repository. A good solution for topic branch should work well in such distributed environment. So topic information must be exchanged at the same time as the commit they are attached to.

- Tracking/Target:

  • People make changes with the goal to get them integrated into a main line of development (default, stable, version 4.2, stagging, etc). This "target" should be the default destination for merge, rebase, update (and any other command it make sense?). This aspect can probably use (or maybe need) integration with the life cycle.

- Clearly defined set of changes:

  • A topic is usually composed of multiple changesets, being able to easily define what is in the set is important for commands that handle topic as a whole (eg histedit, prev, next) and probably a very important point to design UI around evolve. Having a defined set of changesets is also needed when only part of the topic is exchanged (pushed or pulled). Topic cannot cannot just be defined from topological branch because rebasing a topic on the main branch makes such topological branch disappear (and also, topic may be multi headed or some topic share some common part of a branch).

- Anonymous branching:

  • Anonymous branch (and others graph property) is a useful feature of mercurial that adds flexibility and improve productivity. We should keep this strength available within each topic.

- name conflict handling:

  • Fixing a bad name (or people fighting over a name) should not result in too complicated situation.

2. Current short coming of bookmarks

This section (and page) is not meant as "bookmark are doomed, lets do something else. The idea here is "we have long standing issue with bookmark, lets think again from scratch a see what emerge. We'll see what to do with the other idea after.

There is currently an experimentation around the idea of "remote bookmarks" and wider work flow changes, it will be "evaluated" independently. (its a wiki Feel free to update content of this section)

requirements

in-core

remote

Life cycle

poor

poor

distributed

okay

bad

tracking

good

defined set

poor

poor

partial push

bad

poor

branching

bad

bad

conflict

okay

good

Life cycle of bookmark are problematic because we still have not figured out a proper way to handle deletion and renaming. So once they are in the wild, it is very hard to get ride of a feature related bookmark. Not sure if remote-bookmarks improve that a bit.

distributed is okay-ish for the in-core bookmark. The current behavior on pull work in a distributed ways as it will exchange any bookmark alongside their changeset. However behavior on push is more problematic as local bookmark may not be pushed, and Mercurial may warn about it or not depending unrelated condition. The 'remote-boomarks' change is more problematic in this aspect as remote name are not propagated so changesets can get exchanged without there topic information.

tracking is not covered at all by current core version. It is introduced with 'remote-bookmark' but only cover rebase, the UI to setup and observe tracking is unclear to me yet.

defined set bookmark can implicitly define a set of revision since everything 'only' under that bookmark it can be considered in the topic. This have issue with:

  • - Requires the use of bookmarks for the main branches too. - Misbehave if a some part of the topic is shared with another bookmark (or anon heads) - Bad handling of extra anonymous heads on the same topic. - ill defined behavior when push only half of a topic (who does not hold the bookmark)

Principle

Assign topics to non-public changesets. A topic is like a named branch, in that it is a label on a changeset (the initial prototype even stores the topic in the extra area in the changeset), but that topics just disappear when the change moves to public phase.

Problem solved

1. What Topic solves

Bookmarks are a clone of git's refs, which seems to work more poorly in Mercurial than they do in Git, in part because the synchronization parts of bookmarks aren't really done. Adding the remaining functionality to bookmarks has been challenging, and seems to be adding a lot of conceptual complexity around configuration of the synchronization mechanism that AugieFackler finds frustrating.

The current implementation also makes it possible to say "what patches did I do while working on topic issue1234", which might be nice.

2. What Topic may solve

(Use case that exists but it is not clear if Topic should try to solve them)

3. What Topic do not solve

(Use case we know belong to other feature)

Open Question

  • Right now we use changeset extra for storing the topic. That might lead to bonus divergence problems.
  • Should changesets be allowed multiple topics?
  • How permissive should we be on topic names?


CategoryDeveloper and CategoryNewFeatures

TopicPlan (last edited 2021-10-08 14:11:59 by GeorgesRacinet)