In a message of Sat, 26 Feb 2011 09:09:50 +0100, holger krekel writes:

Hi Laura,

...

Why should we ever care about space?

Small repositories are faster to clone and work with. I am fine to copy everything related to extradoc, though.

I thought we had unlimited repos in bitbucket. If so, then this is an argument for putting the extra documentation in a different repo than the pypy one, not for getting rid of things in extradoc.

...

I don't think that much (or maybe any) reconstruction is necessary. The things in extradoc really are the tex files, pdfs and what-have-you that you would expect from their filename extensions. The problem is that codespeak improperly serves them up as binary files. So no reconstruction needed. Just serve them properly.

this has nothing to do with codespeak but which svn:mime-type files have in the svn repository. If you find a file in the repo that should have a certain mime-type you can e. g.

svn ps svn:mime-type application/pdf path/to/file.pdf

it.

I am actually not sure how mercurial or bitbucket handles serving such fi les.

Sorry, I knew that, I didn't mean to imply that it was some flaw in codespeak. Though it is very far from clear to me how svn got in the business of giving our files mimetypes, which I think happened secretly, under-the-hood. I don't think any of us explicitly went around typing svn commands to set a mime-type of binary to those files, it just happened silently. And, for me, at any rate, svn was an unexpected culprit -- by this I mean that when I went investigating the problem of 'why is this talk being served up as a binary file' svn was not one of the places I thought to look. The mercurial authors (like me) don't like the concept of binrary files, see http://mercurial.selenic.com/wiki/BinaryFiles , so I guess all we need to find out is does bitbucket itself make assumptions. I wouldn't think so, but then I thought that about svn as well.

But I think we should anyway go for serving talks via http://pypy.org/tal ks/ just through apache and avoid giving out links to version control repositories. We might eventually migrate away from bitbucket and we would then again have the problem of stale links.

I'm not fond of a solution which leaves the extradoc files in two versions, the one in the repo and the one on http://pypy.org/talks , and where you have to keep remembering to change the pypy.org one because you have made a change to the one in the repo.

cheers, holger

I think we may have a more general problem, in that the flexibility of pypy should lead to massive experimentation, not only by ourselves but by third parties. What then should we do with the experiments? I'd like to find a way to keep the interesting ones around without making branching horribly slow. I thought that having many separate repositories would go a long way to getting this, was this also a mistaken assumption? Laura