On Thu, Jan 31, 2008 at 01:14:40PM +0000, Daniel Leidert wrote:
> Am Donnerstag, den 31.01.2008, 13:36 +0100 schrieb Pierre Habouzit:
> > On Thu, Jan 31, 2008 at 12:08:24PM +0000, Daniel Leidert wrote:
> > > Am Mittwoch, den 30.01.2008, 21:22 +0100 schrieb Pierre Habouzit:
>
> [..]
> > > > Well, the point is that your repository isn't self contained in that
> > > > case.
> > >
> > > My VCS always contains a debian/watch file or a get-orig-source target.
> > > So everything necessary is available.
> >
> > Nope, you don't have the merge capabilities of your $SCM to backport
> > patches, and see them automagically go away when you package the next
> > upstream release.
>
> So you are referring to a patchless-maintenance (ditto for Colin Watsons
> answer). I can imagine this has advantages if you maintain a package
> alone. But it IMHO makes it harder to track changes in collaborative
> maintenance and requires excellent merge qualities of the VCS, which
> currently seems to guide to just one VCS: git. But especially the
> possibility to use any (aka the preferred) VCS (at alioth.d.o) seems to
> be one of the main advantages of the current approach for me.
You're wrong, I don't see what makes it difficult, and you don't need
patchless workflow. FWIW my patch queue is in git (but unlike what you
say this should work the same with bzr or mercurial), and I use the
rebasing (which use merge internally) features of git to reduce that
patch queue for each upstream. And I believe this can work with a team
too. FWIW I export the patches from my branch, so it's not 100%
patchless, it's just that the patch series isn't what I modifies to
change the patches, it's just a "compiled" form in my PoV.
> > You're wrong, I don't store the whole orig.tar.gz, I keep its content,
> > and the delta (often less than 2kb).
>
> Then I seem to misunderstand you. What does "content" mean, if you do
> not store the whole .orig.tar.gz? Do you just store the diffs between
> upstream versions?
I store the extracted orig.tar.gz, and uses pristine-tar to store a
small delta file that allow me to regenerate the exact original tarball
from it.
> > Each new upstream release costs little extra size, and the more
> > revisions there are, the less additionnal size I need (because there
> > are already enough good files to make good deltas in the
> > repository). The more a git repository grows, the slowest.
>
> Can you show me a public example? To be honest, I have some problems to
> understand your workflow.
Well, comme to FOSDEM, I'll present it. But to give some examples, for
the linux-2.6 kernel tree:
* git packfile is 185Mo big (full history since first kernel in git,
aka 2.6.12 IIRC) :
185Mo .git/objects/pack/pack-7bc9f383c92cbffe366da2d2a62b67bb33a53365.pack
* git tar.gz for 2.6.24 is 55Mo big (57695 Ko).
* the unpacked source holds 296Mo of disk usage (according to du).
For xorg-xserver:
* debian orig.tar.gz is 8Mo;
* the git packfile is 16Mo big;
* the unpacked sources are 20Mo big.
> > I can see that you never packaged anything complicated, just by that
> > assertion.
>
> You shouldn't make assumptions you never tried to check.
I could easily say the same to you then :)
> > History is important, a full VCS history is even better,
> > because you can tell when a change (think regression) occured, and
> > understand why.
>
> A regression made in a version older than the one in oldstable? Pierre,
> are you kidding me? How often this will happen? Which package(s) are you
> referring to?
I don't really care about _older_ than oldstable. I care about finer
information than "regression since the last debian release 5^H2 years ago".
And with git, if you have the full history since the last debian
release, say 18months of history, usually history from the begining of
times is less than 10% of size growth for your repository. I don't see
why I should bother. And I can work offline, you can't.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpTCAMb3bqNl.pgp
Description: PGP signature