[pypy-dev] implementing the additional repo migrations

[Laura Creighton]

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