Colin Watson wrote: > So, I can't stand git's user interface. I generally try to avoid making > a huge issue of this since it seems to be massively political on places > like Planet at the moment, there seems to be a certain amount of > confusion of people's personal opinions with that of their employers > going on, and in any case I normally find that revision control > flamewars have negative utility. (I don't think it's terribly relevant > to this discussion why I prefer not to use git, and I don't want to > sidetrack the thread with that; I just wanted to present an existence > case of somebody who doesn't want to switch to .git.tar.gz and yet > doesn't want to stay with .orig.tar.gz and .diff.gz forever.) (So, FWIW, I'm not sold on git. Not sold at all yet. But it was a good choice for this implementation for several reasons.) > Still, this work looks pretty cool, and I'd like to be able to make use > of it despite avoiding git whenever I can. I noticed that you'd > helpfully structured your changes such that it would be possible to plug > in a different revision control system, so I wrote a module to support > bzr. Nice. The FAQ has some questions aimed at adding other revision control systems, could you try to answer those in the context of bzr? In particular, is the data that would be shipped in the source package the same data that bzr normally reads from untrusted sources, thus ensuring that using it this way is equally (in)secure as using bzr to pull data over the network? (Note that this wasn't 100% true for git and I have had to put in several workarounds.) And is the data format stable and/or one that bzr has a history of supporting old versions of in a way that ensures backwards compatability? Also, will the bzr repos always contain the full history, or is there an equivilant to git shallow clones? How big do they tend to be? > It's true that this is no worse than dbs or dpatch or whatever, and > in fact it's better because dpkg-source will take care of the > unpacking step automatically. Still, I do think it is a downside; we > do still ship /usr/share/doc/debian/source-unpack.txt BTW, source-unpack.txt fails for both packages containing debian/subdirs/ and of course for wig-n-pen.. > * Buildds will need to have the VCS installed in their base system. This seems easily solved by recommends (installed by default). > * Some source packages want to ship non-VCS-managed files. > > It's very common for source packages to include autogenerated > objects like configure, Makefile.in, etc. Whether to check these > into a VCS is a somewhat religious matter (as acknowledged by the > gettext info documentation, for instance), and personally I lean > towards checking them in (with a few exceptions) just because it > makes it easier to see when they change and keep an eye out for > oddities, but I know that a lot of developers prefer to keep these > outside their VCS. Shipping a working tree would make it easier to > handle cases like this. Hmm, I hadn't considered that this might be a problem. I don't know if I'd want to write the code to do this, but shipping a partial working tree consisting of just those files would be enough to solve this. > * Space-constrained mirrors could conceivably exclude the VCS data if > they had to, though we probably wouldn't encourage this. > > These seem to me to be non-trivial advantages that outweigh the space > costs of shipping around the working tree. The space constraints seem pretty hard to me. Specifically, I don't want to piss the ftpmasters off and get vcs source packages banned from the archive.. The only saving grace really seems to be that shipping both vcs and upstream tar will only double the size of the archive once most everything uses the new format, and the archive will have probably doubled in size several times over due to other factors before then. I've eyeballed the code, it looks ok though so close to code I've been looking at all week that I may be missing trees for the forest. :-) -- see shy jo
Attachment:
signature.asc
Description: Digital signature