Le 20 juil. 2014 à 19:39, kp kirchdoerfer <kap...@users.sourceforge.net> a écrit :
> Am Sonntag, 20. Juli 2014, 19:22:18 schrieb Yves Blusseau: >> Le 20 juil. 2014 à 19:04, kp kirchdoerfer <kap...@users.sourceforge.net> a > écrit : >>> Am Sonntag, 20. Juli 2014, 18:40:15 schrieb Yves Blusseau: >>>> Le 20 juil. 2014 à 18:22, kp kirchdoerfer <kap...@users.sourceforge.net> >>>> a >>> >>> écrit : >>>>> Hi Yves; >>>>> >>>>> Am Sonntag, 20. Juli 2014, 18:09:00 schrieb Yves Blusseau: >>>>>> Hi all, >>>>>> >>>>>> actually the size of the git repository (i'm speaking of the "database" >>>>>> not >>>>>> the checkout) is about 3.5GB. It's really too big. The problem is that >>>>>> the >>>>>> "database" contain ALL the versions of "tar source files". So if >>>>>> someone >>>>>> need to clone our repository, he need to download at least 3.5GB of >>>>>> data. >>>>>> >>>>>> What i propose is to remove all the external source tar files from the >>>>>> history and put them (at least the last one) in another git repository >>>>>> on >>>>>> SF. The source tar files will be download (if needed) from this new git >>>>>> repository (using the http protocol). With this, the bering-uclibc will >>>>>> contain only textfiles and some patch, and i think it will take only >>>>>> some >>>>>> MB. We will continue to create a sources.tgz file when we release a new >>>>>> version to meet the requirements of SF. >>>>>> >>>>>> What do you think about this idea ? If you are ok, i can made the >>>>>> process >>>>>> to "clean" the repository and update the buildtool.cfg files to change >>>>>> the repo from local to SF. >>>>> >>>>> The way I work is to copy the current repo to a local directory and use >>>>> as main server >>>>> >>>>> <Server localrepo> >>>>> >>>>> Type = filesymlnk >>>>> Serverpath = repo >>>>> >>>>> </Server> >>>>> >>>>> Whatever I do in the local directory it won't clash with changes in git >>>>> vice versa I will not crash git :) >>>>> >>>>> So if we do have two repos (one for the sources, one for the buildtool.* >>>>> and patches etc) I prefer that buildtool will be able to still use local >>>>> directories (in the first place) and only download from SF if sources >>>>> are >>>>> missing. >>>> >>>> The simplest is to declare where to get the tar files with something >>>> like: >>>> <Server sourceforge> >>>> >>>> type = http >>>> Serverpath= xxxx >>>> >>>> </Server> >>>> And the buildtool will download the file only if it's not already >>>> download >>>> in the repo directory. So if the tar files are already in the repo >>>> directory you can build all the lrp offline. >>> >>> That sounds good. >>> >>>> For the source.tgz you only >>>> have to change the definition of Server sourceforge to <Server >>>> sourceforge> >>>> >>>> Type = filesymlnk >>>> Serverpath = repo >>>> >>>> </Server> >>>> because all the files are already in the sources.tgz >>> >>> Just to understand: >>> >>> Is "sources.tgz" meant as example like "linux-3.10.47.tar.gz" or do you >>> refer to a tgz file that conatins *all* sources in one file? >> >> About "sources.tgz" i refer to a tgz file that contain "all" sources in one >> file. > > And how do we maintain the file, if we only upgrade one source like the > kernel? > Repackage sources.tgz and upload a huge file? Yes if it is a requirement for SF > I understood your proposal that we maintain the sources in a seperate git > repo > and use this to package all into one to fit SF requirements. >> From this repo we download sources, if they are not in the local directory, > otherwise we can build from a local directory/repo. > I think about a buildtool logic that checks, if the source is available > otherwise it will download from the git repo. Yes perhaps buildtool must be upgrade a little. It will be great also to have a checksum to be sure that the file has been correctly downloaded. This is what all builders use (openembedded, macports, etc…) Just for info, i have remove on my local git clone all the "source tar files" and the git "database" size go from 3.5G to 11MB and i think it can be reduce :D Yves
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
_______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
