Reduce download size & time

[Jan Holesovsky]

Hi,

I have implemented an ooo-build ./configure switch named --with-git.  When you
use it, ./download will clone the git trees from
  http://cgit.freedesktop.org/ooo-build/
instead of downloading the source tarballs.  During unpack, the checkouts will
be copied to build/<milestone> instead of unpacking the tarballs.

What are the advantages?

You will download about 900M once, and then, with every new
milestone, ./download will fetch just the new stuff, which will be much less
than the full tarballs.

Another advantage is that the git trees are updated every night automatically
from the OOo SVN, so you don't have to wait for anyone to pack the tarballs.

And, the source code in the git mirror is nicer thanks to the conversion of
the leading tabs to 4 spaces for *.[ch]xx, *mk, and few other file types ;-)

Regards,
Kendy
_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

[Jan Nieuwenhuizen-2]

Op donderdag 28-05-2009 om 12:14 uur [tijdzone +0200], schreef Jan
Holesovsky:

> I have implemented an ooo-build ./configure switch named --with-git.

Great, thanks!

> And, the source code in the git mirror is nicer thanks to the conversion of
> the leading tabs to 4 spaces for *.[ch]xx, *mk, and few other file types ;-)

Uh, this doesn't break git-annotate or easily upstream-applyable
git-format-patch, I hope?

Jan -- still hoping for a usable annotate on oo.o code instead of seeing
       who pressed `integrate' or whatnot ;-)

--
Jan Nieuwenhuizen <janneke@...> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl    | http://lilypond.org

_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

[Jan Holesovsky]

Hi Janneke,

On Thursday 28 of May 2009, Jan Nieuwenhuizen wrote:

> > And, the source code in the git mirror is nicer thanks to the conversion
> > of the leading tabs to 4 spaces for *.[ch]xx, *mk, and few other file
> > types ;-)
>
> Uh, this doesn't break git-annotate

Well, the filtering is done on the level of import from the SVN, so it has the
same annotation as in the SVN [== useless, because you see the commits as
done by the release engineers, not by the authors].

But at least you should be able to see which commit changed that much faster,
and see the real author in the commit message.

> or easily upstream-applyable
> git-format-patch, I hope?

You have to use patch -l to apply such a patch, but that works fine (apply.pl
uses -l too).

> Jan -- still hoping for a usable annotate on oo.o code instead of seeing
>        who pressed `integrate' or whatnot ;-)

Hehe :-)

Regards,
Kendy
_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

[Jan Nieuwenhuizen-2]

Op donderdag 28-05-2009 om 17:08 uur [tijdzone +0200], schreef Jan
Holesovsky:

Hi Kendy,

> > Uh, this doesn't break git-annotate
>
> Well, the filtering is done on the level of import from the SVN, so it has the
> same annotation as in the SVN [== useless, because you see the commits as
> done by the release engineers, not by the authors].

Useless.  Is that on purpose?  What reason does Sun give for
needing release engineer code line annotation, which is so important
it warrants destroying developer code line annotation?

Greetings,
Janneke

--
Jan Nieuwenhuizen <janneke@...> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl    | http://lilypond.org

_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

[Jan Holesovsky]

Hi Janneke,

On Tuesday 02 of June 2009, Jan Nieuwenhuizen wrote:

> > Well, the filtering is done on the level of import from the SVN, so it
> > has the same annotation as in the SVN [== useless, because you see the
> > commits as done by the release engineers, not by the authors].
>
> Useless.  Is that on purpose?  What reason does Sun give for
> needing release engineer code line annotation, which is so important
> it warrants destroying developer code line annotation?

I don't think they deliberately break the annotation, to me it seems that they
use wrong tools ;-)  It looks to me that instead of a real svn merge, the CWS
integration tooling just takes a snapshot of the CWS and commit it to the
trunk as a new commit; but I may be wrong - better ask on dev@tools.

HTH,
Kendy
_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org