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 >>
