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

[John Szakmeister]

On Fri, Jun 4, 2010 at 3:53 PM, Jelmer Vernooij <jelmer at samba.org> wrote:
[snip]
> I guess that means we'll need "push_merged_revisions = delete-branch" or
> something to remove such a branch after pushing it.

That would be useful, yes.

> There is an open bug about push_merged_revisions not working,
> https://bugs.edge.launchpad.net/bzr-svn/+bug/486811 . Is that the same
> problem you were seeing?

You know, it might have been.  I actually thought I saw the revisions
being pushed up there though... I could be wrong about that though.
I've got a little time at the moment, so I'm looking into it.

[snip]
> From all I hear it sounds like what you're really after is indeed the
> push_merged_revisions setting. Pushing without the merged revisions
> implies ghosts and there's no way we can make up information we don't
> have, the information you'd like bzr to display in annotate.

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.

[snip]
> IMHO we should fetch all of the revisions for which we have tags. If
> that means fetching more revisions than we'd want then the user can
> always remove tags remotely and try again.

I'd be very happy with that solution.  Having the tags is pretty
useful, IMO.  And it's nice to be able to use them in a far simpler
way than Subversion. :-)

-John