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 fully. 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. Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
Attachment:
signature.asc
Description: This is a digitally signed message part