Allowing Aliases in the Baz Inventory
Created: 21/04/05 by MarkShuttleworth
This specification describes how we intend to support multiple inventory "id's" for the same file in Bazaar and BazaarNg. Currently, Baz supports two types of inventory id, the arch-tag type and the .arch-ids type, and these are mutually exclusive. Bazaar-NG has a single id type but still needs to 'unify' ids that appear.
There are two problems with the current status of file id's in Baz.
First, it is not possible to move easily from an arch-tag id to a .arch-id file id. This causes problems, for example, where a repository has mixed uses of the different types of id, and wants to shift to one type exclusively without losing history. Currently, it's possible to change a file from the one to the other type, but that will appear as a delete and an add in history, and prior changes will be lost. The Launchpad team, for example, feel that arch-tag file ids are evil and would like to eliminate them from their codebase altogether.
Second, when the same file is created in a repository by two different people in their own branches, and the branches are then merged, baz will currently create an unnecessary for every person doing the merge, because each of those files has a distinct id and the resolution shows up as a delete and add.
Scope and Use Cases
The following use cases should be addressed:
James has a file in his archive that has an arch-tag. However, the project has decided to use .arch-id tagging exclusively, because it is more consistent. He should be able to run a single command that gives the file a .arch-id id, and then delete the arch-tag line inside the file, and not lose any history.
- Penelope receives a patch from a mailing list for a project she's working on and applies it to her branch. It creates a file, she uses
"baz add" to add the file to the repository and it is given a unique file id. Jack applies the same patch to his own branch, and also uses baz add to add the file, giving it a unique id that is of course different to that in Penelope's tree. Both change the file in different ways. Then Jack tries to merge from Penelope's tree, and will receive a conflict because Baz considers these to be two totally unrelated files. When this spec is implemented we would expect Jack to be able to tell Baz that the two files are in fact the same, and have that information then recorded so that other people merging from either Jack or Penelope automatically recognise the two files as being the same.
UDU Brain Dump
Data Preservation and Migration
User Interface Requirements