[RFC] Revision id aliases

[Jelmer Vernooij]

On Mon, 2006-06-19 at 11:10 -0500, John Arbash Meinel wrote:
> Jelmer Vernooij wrote:
> > On Sun, 2006-06-18 at 19:00 -0500, John Arbash Meinel wrote:
> >> Jelmer Vernooij wrote:
> >> I can say that if you were treating SVN as just another branch, you
> >> would actually be at the same place, where each merge generates a new
> >> revision id. So it isn't like bzr can't cope with each commit to SVN
> >> being a separate revision. As long as you make bzr think that they are
> >> all merges.
> > The problem with that is, if I understand you correctly, that you can't
> > use it to push from a Bazaar branch to a Subversion branch. I'm
> > interested in revision aliases so that I can say (locally) that a
> > revision id in a Subversion branch refers to the same revision I have in
> > my local branch so that 'bzr pull' won't complain about diverged
> > branches after I've pushed to the Subversion branch.
> Why would it complain about divergence if the push is marked as a merge.
> You basically end up with branches that look like:
> 
> bzr: A - B - C - D
>        \   \   \   \
> svn:     X - Y - Z - Q
> 
> If you are at 'D' and you push into Z to create Q, that just needs to be
> marked as a merge of Z+D, and then 'bzr merge' would try to merge Q (and
> maybe install XYZ as merged revisions).
> 'bzr pull' would probably try to grab Q, and then change your history to
> AXYZQ.
Ah - the "push marked as merge" bit is was what confused me. This
actually makes more sense, thanks! I hadn't thought of this solution
previously. This means I'll be able to get rid of the special revision
properties. 

I was planning on adding a couple of revision properties to track 
version revision changes. This didn't scale well though - you have to
poll for the revision properties of each revision individually. 

> I understand that this isn't optimal, but it is usable, and doesn't
> require any extra information to be recorded. I assume you would use
> some sort of SVN property to indicate that Z was merged from bzr's C,
> though where you put that in SVN is beyond me. Is it on the directory at
> the base of the 'branch'?
No, you can actually set properties on revisions, which is what I'm
doing. With the "push as merged" trick you mention, I'll be able to drop
all except the 'bzr:parents' property that I'll use to track the
revision id of the original Bazaar branch (which will show up as ghost
to others).

> The difficulties with stuff like this is handling how to propagate
> aliases to other branches, etc. If you are just using them as a local
> list of mappings, how is that different from a local cache of SVN?
> (which you are trying to get rid of).
My main aim here was trying to circumvent the problem that if you did a
'bzr push parent-branch', 'bzr pull parent-branch' would give you a
DivergedBranches error. Your solution clearly fixes that, so I'll just
use that one.

> I'm not sure what keys would make sense for your needs, since you end up
> with 2-way aliasing. I suppose you could use:
> alias:revX\trevY => 'True'
> And the file could just version if that line exists or not.
Wouldn't just adding 
'revX' => 'revY' 
and
'revY' => 'revX' work? That seems to make more sense to me.

> I got a little off topic, but I would like to see tags happen. Just
> getting them 'right' is difficult.
Same here - tags are imho the big missing features from Bazaar at the
moment.

Cheers,

Jelmer

-- 
Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~jelmer/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060619/b37e7507/attachment.pgp