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

[John Szakmeister]

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.

-John