Re: [pypy-dev] implementing the additional repo migrations
In a message of Sat, 26 Feb 2011 09:09:50 +0100, holger krekel writes:
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.
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.
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
On Sat, Feb 26, 2011 at 10:29, Laura Creighton <lac@openend.se> wrote: through bitbucket tools and make changes on the fork. If and when the fork is completed and useful, it can be pulled back, otherwise it just stays separate. With Hg the only problem is in storing N repositories on a computer without storing N copies of the common history, which is a different but related problem. To make branching fast, hardlinks allow to share the history between related repos, especially in Git but it seems also in Hg - search "hardlink" in the hg(1) man page, and this extension: http://mercurial.selenic.com/wiki/RelinkExtension While I'm a fan of Hg, the Git repository layout seems intrinsically better from this point of view: with Hg, as soon as you commit a change to a file in a branch, the existing history of that file can't be shared any more between the two repos (at least, it can't possibly be shared through a hardlink; it doesn't seem they implement other solutions, and it would be hard to do that in a way coherent with their design). I've got no experience with Hg on huge projects, while I have 8 branches of the Linux kernel laying around: the history of each additional branches takes ~5M (compared to 450M for the history of the main repo). If the branch stays close enough, though, this might not be a problem, but YMMV. Cheers, -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/
On Sat, Feb 26, 2011 at 10:29, Laura Creighton <lac@openend.se> wrote: through bitbucket tools and make changes on the fork. If and when the fork is completed and useful, it can be pulled back, otherwise it just stays separate. With Hg the only problem is in storing N repositories on a computer without storing N copies of the common history, which is a different but related problem. To make branching fast, hardlinks allow to share the history between related repos, especially in Git but it seems also in Hg - search "hardlink" in the hg(1) man page, and this extension: http://mercurial.selenic.com/wiki/RelinkExtension While I'm a fan of Hg, the Git repository layout seems intrinsically better from this point of view: with Hg, as soon as you commit a change to a file in a branch, the existing history of that file can't be shared any more between the two repos (at least, it can't possibly be shared through a hardlink; it doesn't seem they implement other solutions, and it would be hard to do that in a way coherent with their design). I've got no experience with Hg on huge projects, while I have 8 branches of the Linux kernel laying around: the history of each additional branches takes ~5M (compared to 450M for the history of the main repo). If the branch stays close enough, though, this might not be a problem, but YMMV. Cheers, -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/
participants (2)
-
Laura Creighton -
Paolo Giarrusso