Documentation size in Git repository

[bchretien]

The gh-pages branch that contains the automatically-generated documentation is getting bigger and bigger since large chunks of the documentation are modified for any commit. We should probably trim the doc once in a while (or even do it automatically when updating the documentation). Else, users will need to use the --single-branch -b master clone options, or --depth for a shallow copy, in order to get the source in an acceptable time when using a slow connection.

This can be checked and confirmed with:

$ git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 | cut -d' ' -f1 | xargs -I{} sh -c "git rev-list --objects --all | grep '{}'"

With all the branches (including gh-pages):

78b1bbfa540226e763be9fd55c4ac233e1481213 doxygen/HEAD/a00304.png
8ac3257d289e2183860341321bf4b52cb10908c8 doxygen/v2.0/a00270.png
a4b5bcaef90c837685b690b8db6339ad5b310aec doxygen/HEAD/a00222.png
c8fdf21034f1d8d2ca62ec1e31e3452b6d56d124 doxygen/HEAD/a00351.png
218d4b56f47587f7d09450fedde5d612ac97e057 doxygen/v2.0/a00233.png
bf8a31d7f3c63d2de586b7fb21ac547b18915a13 doxygen/HEAD/a00258.png
56e22fe20f4cd1098284c09aa9f1dc65dfbc1e99 doxygen/HEAD/a00258.png
3a4b706481dbcf2de1678e00e4289633b3ac2a4f doxygen/HEAD/a00222.png
67b868e62849f0345f6c48a75165c5b7734325de doxygen/HEAD/a00160.png
31c8ff72bab796dddf36065ef8a2eb3cc3589cd0 doxygen/v2.0/a00166.png

With just master:

01fa847bc040499e689b5523d87ff85bc306e9d4 tests/visualization-gnuplot-function.stdout
6e19599f830960f82fba4fa18f48b8677cc38fe7 libltdl/ltdl.c
fd90e82261acab4ea167aacb9757024d5d3ad079 doc/Doxyfile.in
1cef4d279dfdd167b9656fef962627f28f70d566 tests/visualization-gnuplot-function.stdout
956185c0ab060a883f5da4d4b6e1b2760655d90a tests/visualization-matplotlib-function.stdout
5ac9ac21f99521cd252908a3aa261740e34c66ad ChangeLog
04a0fc31d06356aaa72c86ab3bb6323ca3f09c54 ChangeLog
268ddd8d8aaa5766e5a69362760fa9695fda6544 ChangeLog
17c15b9b27cf3bcc0258b8fb31dc0aa080e2ef21 build-aux/ltmain.sh
2f42cf8311f7360231238aa1fd2a98b39770f0d2 build-aux/libtool.m4

Also:

$ git count-objects -vH

With everyting:

count: 4551
size: 18.45 MiB
in-pack: 22726
packs: 11
size-pack: 59.03 MiB
prune-packable: 44
garbage: 0
size-garbage: 0 bytes

With just master:

count: 0
size: 0 bytes
in-pack: 7130
packs: 1
size-pack: 1.94 MiB
prune-packable: 0
garbage: 0
size-garbage: 0 bytes

[thomas-moulard]

I guess the best strategy will be to reset the branch at each release. If the release process is done correctly, the current content of HEAD will be stored in vX.Y.Z/ and we do not really care to access the old unstable documentation anyway.

So my opinion on this matter would be to reset the branch at each release :)

[bchretien]

Then this all comes down to the release cycle, which is a bit undefined for now. I guess we can add a milestone for the 3.0 release, and add what we deem important to it. I'll need some new features for my project "soon", so these will probably be a part of it, and then there will still be the move to Eigen::Ref which is going to be a major change to the API/ABI.

[thomas-moulard]

Yes, of course. For now, you can at least drop the history before the last release. I guess it should still remove quite a lot of data.

[bchretien]

Ok, now we have both 2.0 and 3.0 available, and I merged most of the commits. It still takes quite a lot of storage:

* HEAD:  8.3 MiB
* v2.0: 27.2 MiB
* v3.0:  8.3 MiB

I guess re-generating the documentation for RobOptim 2.0 may lower the final size, but for now it should be good enough.