Re: git interface to snapshot.debian.org

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Joachim Breitner writes ("Re: git interface to snapshot.debian.org"):
> Am Dienstag, den 25.08.2015, 13:59 +0100 schrieb Ian Jackson:
> > > If the answer is „Nothing is stopping, just that someone has to do it“,
> > > then I’m volunteering, as long as I can do most of it during DebConf.
> > 
> > There are two problems that are stopping us doing this right away:
> > 
> >   - Maybe the amount of data is too big to suddenly dump in the dgit
> >     git server (we should talk to DSA)
> 
> as mentioned I created a proof-of-concept bash script, and for example
> the (git gc’ed) repository of all history of ghc is 137MB. screen
> -message, as an example for a small package, amounts to 572KB. Not sure
> how to best extrapolate that, though.

Right.  I can't see how to do it without actually trying it on the
whole archive.

I guess we could run a program that did this for each package, noted
the size, and then threw the resulting git branch away.  That would
use up some computer time and elapsed time but wouldn't require an
enormous scratch area.

> > > >    - Parents: This is the interesting bit
> > > >      The set of parents should be the commits corresponding to any
> > > >      version mentioned in debian/changelog, pruned by those that
> > > >      are transitively reachable.
> > > 
> > > Nice idea.
> 
> At least for GHC, which had independently running branches in unstable
> and experimental for a while, with occasional merges from unstable to
> experimental, this worked fine.
> 
> I guess dgit by itself does not do anything like that, but rather
> expects the right ancestry to come out of the „normal“ git use of the
> maintianer.

Indeed.  (Although if a .dsc migrates between suites, the git history
is updated.)

> Anyways, I postponed this project for now; too much other things going
> on. I might get back to it in the future. In that case, I would
> probably first try to get nice git repositories from all of
> snapshot.d.o, independent of dgit. Once we have that, one can see if
> and how that is best integrated with dgit.

OK.

> (If you or someone else beats me to it: Even better :-))

Heh.

Thanks,
Ian.