/!\ This page is primarily intended for Mercurial's developers.

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:

- Distributed system:

- Tracking/Target:

- Clearly defined set of changes:

- Anonymous branching:

- name conflict handling:

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

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


CategoryDeveloper and CategoryNewFeatures