pull-sigs for bzr.dev

[Robert Collins]

On Tue, 2006-02-21 at 17:00 -0600, John A Meinel wrote:
> Robert Collins wrote:
> 
> ...
> 
> >> Yes, I was thinking we should include a revision testament in the request.
> > 
> > we need revid for locating the revision, testament for verification -
> > note that the testament is useless if the request isn't signed.
> > (pqm-the-software allows unsigned requests; pqm-the-bzr-instance does
> > not).
> > 
> > the revid could be passed by adding it to the url like we discusssed way
> > back:
> > 
> > merge BRANCH;revid=mbp at 0349-85i04395i43 http://bazaar-ng.org/bzr/bzr.dev
> 
> Well, I think giving rev_id is a requirement anyway. It solves the "I
> want you to merge this revision, but I forgot to push", and the "I
> pushed something extra that I don't want merged yet before pqm got
> around to it".
> 
> > 
> > However the testament has the revid in it.. I am wondering about two
> > variations here:
> 
> Yes, but you can't extract it from the short version of the testament.
> Since the rev-id has been hashed.

Eh?
=== 
bzr testament 
bazaar-ng testament short form 1
revision-id: robertc at robertcollins.net-20060221224858-2b61aaa0f1636293
sha1: 8a840f1ff3e7354151ae2bfcaab3a2755c3657c7
===

The short form is that literal text above.

> If we only had the testament sha1 and expected it to match, we couldn't
> tell if the branch was different than expected, if revisions were just
> pushed, etc.
> I would like to see the pqm do a 'merge -r revid:foo' otherwise there
> are racy things going on.


> > 
> > merge
> > BRANCHURL;revid=mbp at 0349-85i04395i43;testamentsha=aabcdef123412543847198432423/ http://bazaar-ng.org/bzr/bzr.dev
> > 
> > The idea being that the sha of the testament should match.
> > 
> > This gets it all on one line, which the current line orientated pqm
> > parser appreciates.
> > 
> > Alternatively:
> > 
> > extended-merge
> > #rio format data here
> > from: xxx
> > into: xxx
> > testament: however-rio-represents-multiline-literals
> > end-extended-merge
> > 
> > 
> > 
> > Rob
> 
> I would prefer the having an extended format. I think pure linewise
> means that it won't scale very well.
> 
> I also think a better way to extend the pqm is to do it as:
> 
> rio-request-v1
> # rio formatted request
> request: merge
> from: url
> into: url
> testament: bazaar-ng testament short form 1
> 	revision-id: john at arbash-meinel.com-20051231172930-809e9723aef8a0d9
> 	sha1: 82cde2efdcd53c04818d8e102ecb0c41e07655e2
> 

Well, possibly. Some points to note though:
- pqm supports multiple requests in one submitted script. This lets you
(for instance) branch a new branch, then merge into it. in one single
'command'.

So we still need some delimiter between extended requests, the current
delimiter is EOL.

> I kind of still like having a revision-id separate from the testament,
> because that allows us to grab it without parsing the testament section.
> But I guess it doesn't help much if they are both in rio format. (Any
> vulnerabilities in the rio parser can be exploited either way.)
>
> I like having a version indicator in the request message, so that it
> becomes easier to change the syntax in the future.
> 
> I don't know about the internals of the pqm, but the above is meant to
> activate the rio parser, which then grabs as much as rio ever grabs (up
> until 2 new lines), which means you could probably inter-mix the
> requests. Something like:

ok, 2 new lines is an ok delimiter. Dunno how hard it will be to hook
the rio interpreter in. The guts of pqm are still not as well factored
out as I would like.

> rio-request-v1
> # rio formatted request
> request: merge
> ...
> 
> 
> star-merge url url
> 
> rio-request-v1
> # rio formatted request
> request: merge
> ...
> 
> 
> etc.
> 
> Anyway, I think being line-wise makes the parser brittle. Since it means
> you have to shove everything onto one line. And certainly means you
> can't copy and paste a request into some mail clients.

Not arguing.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- 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/20060222/8af83d3c/attachment.pgp