[ANNOUNCE] Example Cogito Addon - cogito-bundle
robertc at robertcollins.net
Sat Oct 21 00:05:12 BST 2006
On Fri, 2006-10-20 at 18:13 -0400, Jeff Licquia wrote:
> All in all, not ideal, but it seems bzr handles this better than bk.
> Certainly, bzr doesn't silently drop anyone's changes, at least. I
> suspect that bzr could improve its handling of this use case, but not,
> I'm sure, to Linus's specifications; some of the fun and games does
> seem to come from the use of file IDs.
We have a few features we're focusing on right now, but coming shortly
after them we hope to address parallel imports [which this is a case of]
better than we do now. I have a number of ideas, and I'm sure other devs
do too, about the right way to solve this. Fundamentally, I think using
1-1 mapped path ids [which can be considered a memo of the origin commit
id + path] of a path is not sufficiently rich a representation of what
happens to paths - there is a dual that you can convert to, which is
identity via ancestry traversal - each path has N <= M parent paths in
each of M parent revisions. Our current path ids can only represent the
case where when you traverse to the start of history this graph has a
single tail (that is, that a single file must start at one and only one
place). The graph however is not intrinsically limited in this way -
files can split and join, and we should be able to represent this more
I'll happily acknowledge that we dont need fileids per se: tracking
renames can be done without a memo of the origin.
However, I'm still convinced that tracking the user intention of renames
leads to a slicker system than renames via inference. My off the cuff
list of corner cases is:
- change file, rename: rename the changed file/change the renamed file.
- change file, remove: conflict on removal/text change
- add path to dir, rename the dir: move the current contents of the
directory/add the new path to the renamed directory.
- move paths out of a directory, rename the directory: leave the paths
moved out where they were moved to/move the paths from wherever their
new location is.
- introduce path A + rename old A to B , change path A: change path
B/rename A to B and introduce the new A.
All these cases work roughly along the form of 'have two branches, do
one action in one, one in the other: merge other to one/merge one to
other'. I haven't yet seen an inference system get all these right.
There are other, more complex cases, but I think they all boil down to
one of those primitives to all intents and purposes.
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061021/ff14cef5/attachment.pgp
More information about the bazaar