[RFC] Revision id aliases

[John Arbash Meinel]

Jelmer Vernooij wrote:
> On Sun, 2006-06-18 at 19:00 -0500, John Arbash Meinel wrote:
>> Jelmer Vernooij wrote:
>>> Another feature that would come in handy for foreign Subversion branches
>>> is revision id aliasing. Are there any plans to support these in the
>>> near future or are they postponed until after 1.0 ?
>> What do you actually mean? That you have 2 revision_ids, but they refer
>> to the same information?
> 
>> I think you are considering using aliases so you can push into
>> subversion, and then have bzr believe that it is the same revision that
>> I just committed. (Or more importantly, the same series of revisions).
> 
>> And I think you want aliases, because Subversion doesn't let you denote
>> any sort of custom id, so you are stuck with their notation.
> Yes, exactly. 
> 
>> 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.

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'?

>> I don't know that much has been done for revision ids. It could be done
>> with a simple aliases table, but we would need to think out the
>> performance implications as well. eg. I want to pull from you, and you
>> have rev-ids 1,2,3,4, but I don't realize they are aliased to my
>> revision ids a,b,c,d so I don't need to pull anything. I assume aliases
>> can be updated after the revisions are created, so it isn't as simple as
>> just pulling new revisions and noting their aliases. (If a is newly
>> aliased to 1, then 1 is actually newly aliased to a as well).
> I'll have a look at some of the old mailing list posts. I'm mainly
> interested in having a locally updated list of revision id aliases at
> the moment, for which a simple dict with mapping should do. What
> specific other use cases are there for revision id aliases?

Some people wanted something similar for quilt-like performance. They
wanted to be able to say 'rev X is like rev Y, but takes precedence'. So
when they change patch 2, and update patches 3-10, doing a pull from
that branch doesn't say 'diverged' but 'replaced'.

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).

> 
>> As far as pre/post 1.0. It just depends if someone like you really wants
>> them, and comes up with a reasonable solution before we decide we are at
>> 1.0. We are already at 0.8. With a major performance push coming up, I
>> wouldn't be surprised if we hit 1.0 fairly soon. (I don't really like to
>> say any absolutes, but probably this year, and it wouldn't surprise me
>> much if it was within 6 months or so).
> Ah, cool - I wasn't expecting it that soon, actually. Is tagging a
> showstopper for 1.0?
> 
> Cheers,
> 
> Jelmer

tags probably should be. The real question is figuring out what for tags
will take.
As an interesting aside, if we implement tags with a general 'metadata
about revisions', it would seem putting aliases in there would seem to
be a good fit.
My current idea of a meta-info file would use something like
knits/weaves to create a per-line ancestry. And then merging happens on
a per-line basis, rather than as a whole file.
It probably couldn't be exactly a knit or a weave, since they actually
work on chunks rather than lines.
Maybe something like key=>value pairs, where the 'key' becomes the line
identifier, and the value is versioned. ('tag:bzr-0.7' is the key,
'mbp at sourcefrog.net-234234234' is the value).

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.

But meta information adds a whole layer of meta-revision-ids, which adds
another layer....
I got a little off topic, but I would like to see tags happen. Just
getting them 'right' is difficult.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060619/416c0341/attachment.pgp