[PATCH 5 of 6] introduce fncache repository layout

[Matt Mackall]

On Thu, 2008-08-14 at 14:24 +0200, Adrian Buehlmann wrote:
> On 14.08.2008 13:21, Adrian Buehlmann wrote:
> > On 31.07.2008 11:47, Adrian Buehlmann wrote:
> >> # HG changeset patch
> >> # User Adrian Buehlmann <adrian at cadifra.com>
> >> # Date 1217492034 -7200
> >> # Node ID 31913bc2a85fd2c9d8c9731483c14ff0acd7db4d
> >> # Parent  3299dc704f6d8dbaabeab2ac345705bfaba86f9f
> >> introduce fncache repository layout
> > 
> > This is now most likely incompatible with current main and crew tip
> > (0642d9d7ec80) due to recent refactorings around store.py.
> 
> Biggest new (reintroduced) problem is that it's no longer the store
> itself
> which creates the file writing opener, which invalidates the strategy
> to create
> a special opener which logs newly created files (as I've done in
> http://selenic.com/pipermail/mercurial-devel/2008-July/007338.html):

No, it just makes it a little more convoluted:

class wrappedopener(object):
    def __init__(self, opener):
        self.opener = opener
    def __call__(self, path, ...):
        # handle new paths
	self.opener('paths.log', 'a').write("saw %s\n" % path) 
	# and then
  	return self.opener(path, ...)

But note that this would continue to work if the provided opener worked
read/write over sftp or whatever.

Since we currently only have one highly neglected alternative to normal
file access, it's not immediately obvious that this sort of thing is
what those weird opener things are for.

-- 
Mathematics is the supreme nostalgia of our time.