Patchwork [4,of,9] branchmap: read and write key part related to filtered revision

login
register
mail settings
Submitter Pierre-Yves David
Date Dec. 26, 2012, 8:33 p.m.
Message ID <ed03a82360c2b90195a2.1356553980@yamac.local>
Download mbox | patch
Permalink /patch/300/
State Superseded, archived
Commit 8d48af68e2ae780950479e5a65cda5a4c0730a09
Headers show

Comments

Pierre-Yves David - Dec. 26, 2012, 8:33 p.m.
# HG changeset patch
# User Pierre-Yves David <pierre-yves.david at logilab.fr>
# Date 1356187406 -3600
# Node ID ed03a82360c2b90195a2d4dacca205e5a705a1f2
# Parent  4b098d0339f9e8b1805c4f6ef1d8bcf59f5a6349
branchmap: read and write key part related to filtered revision

Now that we have a third part for the cache key we need to write and read it on
disk. It is only written when there is filtered revision. This keep the format
compatible with older version.
Idan Kamara - Dec. 26, 2012, 9:09 p.m.
On Wed, Dec 26, 2012 at 10:33 PM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:
>
> # HG changeset patch
> # User Pierre-Yves David <pierre-yves.david at logilab.fr>
> # Date 1356187406 -3600
> # Node ID ed03a82360c2b90195a2d4dacca205e5a705a1f2
> # Parent  4b098d0339f9e8b1805c4f6ef1d8bcf59f5a6349
> branchmap: read and write key part related to filtered revision
>
> Now that we have a third part for the cache key we need to write and read
> it on
> disk. It is only written when there is filtered revision. This keep the
> format
> compatible with older version.

What will happen when an older client tries to use a newly
written cache?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121226/742e3716/attachment.html>
Pierre-Yves David - Dec. 26, 2012, 11:53 p.m.
On 26 d?c. 2012, at 22:09, Idan Kamara wrote:

> On Wed, Dec 26, 2012 at 10:33 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
> >
> > # HG changeset patch
> > # User Pierre-Yves David <pierre-yves.david at logilab.fr>
> > # Date 1356187406 -3600
> > # Node ID ed03a82360c2b90195a2d4dacca205e5a705a1f2
> > # Parent  4b098d0339f9e8b1805c4f6ef1d8bcf59f5a6349
> > branchmap: read and write key part related to filtered revision
> >
> > Now that we have a third part for the cache key we need to write and read
> > it on
> > disk. It is only written when there is filtered revision. This keep the
> > format
> > compatible with older version.
> 
> What will happen when an older client tries to use a newly
> written cache?

That does not happen.

older client only tries to read `.hg/cache/branchheads`. This file contains the branchmap cache without any filtering applied. Therefore nothing is filtered and only tipnode and tiprev is written to disk exactly as the older format.

Cache for filtered version has they own file that older version won't try to read.
Idan Kamara - Dec. 27, 2012, 8:30 a.m.
On Thu, Dec 27, 2012 at 1:53 AM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 26 d?c. 2012, at 22:09, Idan Kamara wrote:
>
> > On Wed, Dec 26, 2012 at 10:33 PM, Pierre-Yves David
> > <pierre-yves.david at ens-lyon.org> wrote:
> > >
> > > # HG changeset patch
> > > # User Pierre-Yves David <pierre-yves.david at logilab.fr>
> > > # Date 1356187406 -3600
> > > # Node ID ed03a82360c2b90195a2d4dacca205e5a705a1f2
> > > # Parent  4b098d0339f9e8b1805c4f6ef1d8bcf59f5a6349
> > > branchmap: read and write key part related to filtered revision
> > >
> > > Now that we have a third part for the cache key we need to write and
> > > read
> > > it on
> > > disk. It is only written when there is filtered revision. This keep
> > > the
> > > format
> > > compatible with older version.
> >
> > What will happen when an older client tries to use a newly
> > written cache?
>
> That does not happen.
>
> older client only tries to read `.hg/cache/branchheads`. This file
> contains the branchmap cache without any filtering applied. Therefore
> nothing is filtered and only tipnode and tiprev is written to disk exactly
> as the older format.
>
> Cache for filtered version has they own file that older version won't try
> to read.

Reading this patch alone doesn't suggest that but I see
it's changed in the next couple of patches in this series.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121227/3f6b06b1/attachment.html>
Kevin Bullock - Dec. 27, 2012, 4:56 p.m.
On Dec 27, 2012, at 2:30 AM, Idan Kamara wrote:

> On Thu, Dec 27, 2012 at 1:53 AM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
> >
> >
> > On 26 d?c. 2012, at 22:09, Idan Kamara wrote:
> >
> > > What will happen when an older client tries to use a newly
> > > written cache?
> >
> > That does not happen.
> >
> > older client only tries to read `.hg/cache/branchheads`. This file
> > contains the branchmap cache without any filtering applied. Therefore
> > nothing is filtered and only tipnode and tiprev is written to disk exactly
> > as the older format.
> >
> > Cache for filtered version has they own file that older version won't try
> > to read.
> 
> Reading this patch alone doesn't suggest that but I see
> it's changed in the next couple of patches in this series.

Yeah, this patch should've come _after_ 5 and 7 in the series. Not a huge deal, but leaving open the chance of writing a branchcache file (with an hg at this changeset, but before the later ones in the series) that an older client can't read is suboptimal.

pacem in terris / ??? / ?????? / ????????? / ??
Kevin R. Bullock
Pierre-Yves David - Dec. 27, 2012, 5:19 p.m.
On 27 d?c. 2012, at 17:56, Kevin Bullock wrote:

> On Dec 27, 2012, at 2:30 AM, Idan Kamara wrote:
> 
>> On Thu, Dec 27, 2012 at 1:53 AM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
>>> 
>>> 
>>> On 26 d?c. 2012, at 22:09, Idan Kamara wrote:
>>> 
>>>> What will happen when an older client tries to use a newly
>>>> written cache?
>>> 
>>> That does not happen.
>>> 
>>> older client only tries to read `.hg/cache/branchheads`. This file
>>> contains the branchmap cache without any filtering applied. Therefore
>>> nothing is filtered and only tipnode and tiprev is written to disk exactly
>>> as the older format.
>>> 
>>> Cache for filtered version has they own file that older version won't try
>>> to read.
>> 
>> Reading this patch alone doesn't suggest that but I see
>> it's changed in the next couple of patches in this series.
> 
> Yeah, this patch should've come _after_ 5 and 7 in the series. Not a huge deal, but leaving open the chance of writing a branchcache file (with an hg at this changeset, but before the later ones in the series) that an older client can't read is suboptimal.

except nothing filtered is written to disk before #9.

Patch

diff --git a/mercurial/branchmap.py b/mercurial/branchmap.py
--- a/mercurial/branchmap.py
+++ b/mercurial/branchmap.py
@@ -16,13 +16,17 @@  def read(repo):
         f.close()
     except (IOError, OSError):
         return branchcache()
 
     try:
-        last, lrev = lines.pop(0).split(" ", 1)
+        cachekey = lines.pop(0).split(" ", 2)
+        last, lrev = cachekey[:2]
         last, lrev = bin(last), int(lrev)
-        partial = branchcache(tipnode=last, tiprev=lrev)
+        filtered = None
+        if len(cachekey) > 2:
+            filtered = bin(cachekey[2])
+        partial = branchcache(tipnode=last, tiprev=lrev, filtered=filtered)
         if not partial.validfor(repo):
             # invalidate the cache
             raise ValueError('(tip differs)')
         for l in lines:
             if not l:
@@ -110,11 +114,14 @@  class branchcache(dict):
 
 
     def write(self, repo):
         try:
             f = repo.opener("cache/branchheads", "w", atomictemp=True)
-            f.write("%s %s\n" % (hex(self.tipnode), self.tiprev))
+            cachekey = [hex(self.tipnode), str(self.tiprev)]
+            if self.filtered is not None:
+                cachekey.append(hex(self.filtered))
+            f.write(" ".join(cachekey) + '\n')
             for label, nodes in self.iteritems():
                 for node in nodes:
                     f.write("%s %s\n" % (hex(node), encoding.fromlocal(label)))
             f.close()
         except (IOError, OSError):