Re: [PATCH] mk/git-package.mk (Re: migrate to git for emacs-current (24.0.50) ?

Greg Troxel <[email protected]>
Newsgroups gmane.os.netbsd.devel.pkgsrc.wip.general
Message-ID <[email protected]>
Makoto Fujiwara <[email protected]> writes:

>   You mentioned the robustness is the most important. I agree.
> git may include its integrity in their own mechanism, so it
> would be get managed I hope.

git definitely has its own integrity mechanism, based on chain sha1
hashes.  One can check a repo with git fsck.

>   First of all, I said 280MB for emacs-current for daily
> cache, it was WITHOUT --depth 1. With --depth 1, it is about
> 126MB.

OK.  Well, emacs is big, and that's just how it is.  The real question
is that if it takes 126 MB to store a copy of emacs sources, then
pkgsrc's git mode shouldn't somehow take vastly more (which I don't
think it will).

>  The second thing is that I am leaning to go with proposed
> policy, meaning that keep uncompressed tar archive of .git
> directory of daily bases. It is just like cvs-packge.mk.  If
> the disk space problem arises, just remove manually old
> generations.  (I have checked emacs-current with
> cvs-package.mk and it occupies about 30MB per day.)

I can certainly see the merit of that approach.  As for manual removal,
I use lintpkgsrc to remove unreferenced distfiles.  I don't understand
how lintpkgsrc and {cvs,svn,git}-package.mk interact, but it would be
nice if the result was that non-current snapshots would be removed.

>   We may have GIT_KEEP_GENERATIONS flag which if set, removes
> the daily archive generations exceeding that number.

We could, but so far pkgsrc doesn't have a general mechanism for this.
Old distfiles are not deleted.  I think it would be nice if we could
treat a saved git repository as a distfile.

>   I also notice that even this flags is set, archive may get
> fat by accumulating history on local copy of .git. I don't
> exactly not tell the impact of this for the time being.

I don't understand what you are trying to say.  I think if one continues
to do a 'git fetch' into a repo over time, then the storage requirements
will grow.  But I think it will grow relatively slowly.

The big choice is between

   clone
   tar up into pseudo distfile
 or
   untar previous version


and something which is much more git-aware and integrated.  I certainly
won't say that doing the straightforward thing is wrong - even though I
think a more git-centric approach would be nice.

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo

_______________________________________________
pkgsrc-wip-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-discuss
signature.asc (application/pgp-signature, 194 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (NetBSD)

iEYEARECAAYFAkwQOxYACgkQ+vesoDJhHiXn9ACgpd/aGu9ReywFIs85PgOL+i/p
wbkAniqNax7ZiZvKBbCDTH21MgGUH7z7
=2QJB
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.