Per the various limitations, it may be if we start to look at the various code bases, and to be able to take advantage of modularization and GitHub, that various modules subfolders or collections of them, php.* groovy.* as examples, get moved into their own repositories and the main NetBeans build uses submodules to link in everything which is the "standard" build. That can also make working on specific subsets easier for some perhaps, but would need thought out. Just putting out another possibility.
Wade On Oct 6, 2016 6:12 PM, "Geertjan Wielenga" < [email protected]> wrote: > Yes, though let's do that on a Wiki page, once we have it set up. > > Gj > > On Thu, Oct 6, 2016 at 11:47 PM, Mark Struberg <[email protected]> > wrote: > > > Indeed it’s way too early. And indeed we need to discuss a lot of things > > when it comes to it. But we need to have a plan. And for that we need to > > analyse the existing codebase. > > > > We now know how to import from hg to git and we know that this works > fine. > > We also know that the hg repo contains lots of stuff which we need to > > handle different than the core NetBeans parts. > > > > So we could e.g. start with identifying which parts are ‚core‘ and which > > parts are modules which contain GPL and might need to get split from the > > core NetBeans repo. > > We also could start to script the git-filter-branch handling. That should > > be doable in a repeatable manner. > > Most of the questions will in the end come back to you old NetBeans folks > > anyway ;) > > > > LieGrue, > > strub > > > > > Am 06.10.2016 um 23:26 schrieb Geertjan Wielenga < > > [email protected]>: > > > > > > Thu, Oct 6, 2016 at 11:16 PM, Mark Struberg: > > > > > >> I’ve migrated the NetBeans hg repo into GIT. > > > > > > > > > > > > It is appreciated a lot. But we definitely need to wait a bit before > > doing > > > this. The JDK 9 branch needs to be merged into the main branch, etc, > > i.e., > > > we really need to do quite some work on the NetBeans side before > anything > > > is ready for this kind of migration at this point. It is too early for > > this > > > and we need to discuss this in a lot of detail first. Timing is > > everything. > > > > > > Gj > > > > > > > > > On Thu, Oct 6, 2016 at 11:19 PM, Michael Nascimento <[email protected] > > > > > wrote: > > > > > >> 3 > > >> > > >> Regards, > > >> Michael > > >> > > >> On Thu, Oct 6, 2016 at 6:16 PM, Mark Struberg > <[email protected] > > > > > >> wrote: > > >> > > >>> Hi! > > >>> > > >>> I’ve migrated the NetBeans hg repo into GIT. Sadly this repo takes > > about > > >>> 3.6 GiB and thus we cannot host it on github or Bitbucket (both have > a > > >> 2GB > > >>> limit). > > >>> I am currently hosting the repo on a small private server. > > >>> If anyone is interested then send me a private mail with your public > > key > > >>> and I’ll give you access. > > >>> Jaroslav, Geertjan and a few others already have a clone. > > >>> > > >>> There are basically 3 ways how we can handle this > > >>> > > >>> 1.) import a tarball into a fresh git repo. We would loose the > history > > >> but > > >>> we only have sources which are explicitly cleared by Oracle. > > >>> > > >>> 2.) import the full hg history. That is pretty thick which means it’s > > not > > >>> that easy to clone. github pull requests also wont work as we exceed > > the > > >>> 2GB limit… > > >>> In addition the hg repo currently also contains lots of GPL libraries > > >> like > > >>> e.g. hibernate jar, etc. That’s something we don’t host at the ASF. > > >>> > > >>> 3.) Take the git import from hg and filter it. Remove all (most) > jars, > > >>> temporary build results etc. We might also get rid of a few old > > branches > > >>> etc. If we keep the original hg repo around in read only mode then we > > >>> should be able to loose tons of weight. > > >>> > > >>> I personally prefer option 3. > > >>> But that is also the most labor intensive. > > >>> > > >>> > > >>> LieGrue, > > >>> strub > > >> > > > > >
