bzr-svn, round 2 (was: Re: Sharing experiences...)

[Jelmer Vernooij]

Hi John,

On Tue, 2010-06-08 at 06:17 -0400, John Szakmeister wrote:
> On Fri, Jun 4, 2010 at 4:07 PM, John Szakmeister <john at szakmeister.net> wrote:
> [snip]
> > That's the thing, I don't think we have to make up information, just
> > use less accurate information.  The merge commit has useful data
> > there.  I think the painful part is getting to it while you're trying
> > to walk the graph.  But the merge commit has a revision, it has the
> > diff, it has a timestamp and an author.  It might not be the same as
> > the guy who did they work, but there's a name and a time frame of
> > someone I can go talk to find out more about a problem.  Don't get
> > wrong, the proposed branch is better than crashing.  It'd be nice if
> > we could take it on step further though.
> 
> FWIW, I've been looking at this some, and I now see the problem.  The
> text index doesn't include merge commits, and that also has an effect
> on what is present in the VersionedFiles object.  It's rather
> unfortunate that we can't get to the repository object to grab some of
> this data from the parent.  I found exactly where we need to make the
> decision, but putting in the correct key leads to VF screaming about
> the entry not being in the keyspace.  Is there really any reason to
> have VF be more constrained in the revisions that it can see?  I guess
> it boils down to index size, but it really complicates trying to do
> something more useful in situations like this.

The text index (or rather, VersionedFiles, which is the API that matters
- the text index is an implementation detail) does include merge
commits. If it doesn't then that's a bug in bzr-svn. 

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/20100608/64820e2c/attachment-0001.pgp