A few thoughts on foreign integration...

[Jelmer Vernooij]

Hi John,

On Tue, 2010-10-19 at 09:24 -0400, John Szakmeister wrote:
> On Mon, Oct 18, 2010 at 8:34 PM, Jelmer Vernooij <jelmer at samba.org> wrote:
> [snip]
> > So, this is a problem that we've encountered in some other situations as
> > well (the "parallel imports" problem overlap with this one, for
> > example). Various solutions have been proposed, but they either haven't
> > been worked out in detail (e.g. path tokens) or have other issues (file
> > id aliases).
> 
> I did take a look at the blueprints for path tokens (I believe the
> actual text is here:
> <http://wiki.bazaar.canonical.com/DraftSpecs/PathTokens>), but didn't
> see any implementation ideas--only requirements and the problem it's
> trying to solve.  Can you tell me what a path token is, and the idea
> behind its implementation?  FWIW, it does seem to be along the lines
> of what I want.  Although, I wonder if dropping file ids all together
> wouldn't be more reasonable too.  I like that file ids make rename
> detection (and a few other things) so easy, but they're really getting
> in my way, at the moment. :-)  I know, I know... that's a pretty large
> change.
The draft is indeed quite vague. Rob might have a somewhat clearer idea
what they are, but I don't know if that's written down anywhere. As I
understand it path tokens might also be useful to support file copy
tracking in the future.

I don't think dropping file ids completely makes much sense by itself.
It would mean we'd lose the ability to do proper rename tracking, which
is a very useful feature. Dropping just file ids also doesn't help with
e.g. parallel imports since we would still have different revision ids
for revisions that have (roughtly) the same contents. The issue you're
running into has more to do with lack of cherrypicking support imho.

Perhaps dropping file ids in combination with other model changes might
make sense, though.

> Also, what are file id aliases?  How would that help solve this?
File id aliases are basically a per-repository map of file ids that
should be considered equivalent to each other. This has some performance
implications and code complexity implications - finding out if two file
ids are referring to the same file requires more than just a call to
str.__eq__ but probably a lookup in some sort of index. 

Personally I (now) think we shouldn't try to work around the existing
limitations of file ids by adding file id aliases but rather investigate
the alternatives, such as path tokens. 

Btw, I don't think we'll be able to cope with the situation you're
facing properly (without any conflicts) until cherrypick tracking
support lands in bzr and bzr-svn. We can however make your life a bit
easier by adding an option to allow path-based merges, and to cope with
the fact that two files that have different file ids are actually the
same for subsequent merges.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20101019/7223442e/attachment-0001.pgp