<br clear="all"><font style="font-family: arial,helvetica,sans-serif;" size="2">-- Pradeep</font><br>
<br><br><div class="gmail_quote">On Sun, Aug 1, 2010 at 7:19 PM, Matt Mackall <span dir="ltr"><<a href="mailto:mpm@selenic.com">mpm@selenic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Sun, 2010-08-01 at 12:35 +0530, Pradeepkumar Gayam wrote:<br>
><br>
> On Fri, Jul 30, 2010 at 11:04 PM, Matt Mackall <<a href="mailto:mpm@selenic.com">mpm@selenic.com</a>><br>
> wrote:<br>
<br>
><br>
</div><div class="im">> So we're going to need a completely new changegroup command.<br>
> One that<br>
> takes some option flags. The unified protocol supports varargs<br>
> commands,<br>
> so handling multiple new flags should be easy.<br>
><br>
> Meaning, a completely new command like 'newchangegroup()' which takes<br>
> varargs and does the same job as changegroup() with additional<br>
> functionality??<br>
<br>
</div>Yes. Except using names like new, modern, NG, extended, etc., is just<br>
silly because all things cease to be new very quickly and it'll<br>
eventually be time for a newnewchangegroup. Even changegroup2 is better,<br>
though something descriptive like changegroup{flags,opts} might also be<br>
good. If we call our new bundle format bundle2, then changegroup2 might<br>
be appropriate.<br>
<div class="im"><br>
> Also, what's going on with the bundle format for parentdelta?<br>
> It<br>
> currently only supports linear deltas. So we need to extend<br>
> it,<br>
> otherwise the big manifests we were trying to shrink will<br>
> bloat back up<br>
> 10x over the wire when we do a clone or pull, which makes the<br>
> whole<br>
> feature a little pointless. And that means we're going to need<br>
> a new<br>
> bundle version number.<br>
><br>
> I am not sure about the new bundle format. I am not expert in other<br>
> areas. What ever I decide, it would be parentdelta centric.(I am not<br>
> sure if it matters for others)<br>
<br>
</div>Yes, it absolutely does matter for others. This is the ONE thing I've<br>
been trying to get through to you and vsh about your projects the whole<br>
time: fixing up the wire protocol for your projects is going to be hard<br>
and is going to require lots of interaction with other people. The wire<br>
protocol (and the bundle format, which is obviously part of it) are<br>
painful to change because we have to allow for backwards compatibility.<br>
We do not want to create a new bundle format every time we add a<br>
feature. We need to think ahead.<br>
<br>
Fact is, we've already done a large amount of that thinking ahead at the<br>
1.5 sprint. But no one's going to tell you about it unless you ask.<br>
Here's a really obvious feature that the new bundle format also needs to<br>
support: shallow clone. Another is long hashes.<br>
<br>
The bundle chunk format looks like:<br>
<br>
4 length<br>
20 node<br>
20 p1<br>
20 p2<br>
20 changeset hash (aka linkrev)<br>
* data<br>
<br>
It's going to need to be extended to something like:<br>
<br>
4 flags<br>
4 length<br>
n node<br>
n p1<br>
n p2<br>
n delta parent (either p1, p2, n-1, or possibly null?)<br>
n changeset hash<br>
* data<br>
<br>
<a href="http://mercurial.selenic.com/wiki/BundleFormat" target="_blank">http://mercurial.selenic.com/wiki/BundleFormat</a><br>
<div class="im"><br>
> So, I didn't think anything concrete.<br>
<br>
</div>Ok, but you know what's required for your piece, so start telling us<br>
about it.<br></blockquote><div><br>New bundle format is useful only when both server and client are new. Because, if one of them is old we can't use the new protocol. If new client is interacting with new server both of them are not aware of other's repo. Then a flag for each chunk in the group should be enough to ease the problem. 'delta parent' is particularly not required for the this, but can be used for cross checking.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> I am still not clear about some definitions.<br>
><br>
> 1) What is new repo and old repo.<br>
> As far as experts cleared to me in IRC if we initiate or<br>
> clone with new hg then we call it a new repo. If it is right, how do<br>
> mark them as new repo. Is it something goes into requires or a flag<br>
> into revlog header or both?<br>
<br>
</div>Traditionally, we do this with a requires flag. Newly-created<br>
repositories add the flag to say "to read and write from this repo, you<br>
must understand feature X".<br>
<div class="im"><br>
> 2) Shall we add parent deltas on the top of tip deltas in old repo.<br>
<br>
</div>No. An old repo must continue to be readable by both old and new<br>
clients. A new client can never 'upgrade' the requires file of an<br>
existing repo.<br></blockquote><div><br>So, I can do something like this:<br></div><div> </div><font style="font-family: courier new,monospace;" size="1"> <font size="2"> if self._parentdelta:<br> chain = self.deltachain(rev)<br>
else:<br> chain = [r for r in xrange(base + 1, rev + 1)]</font></font><br><br><font face="arial,helvetica,sans-serif">Which does not affect the performance on the old repos.</font><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font color="#888888"><br>
<br>
--<br>
</font><div><div></div><div class="h5">Mathematics is the supreme nostalgia of our time.<br>
<br>
<br>
</div></div></blockquote></div><br>