> As another example: we implemented Terminal in C++, then 'contributed' into Full IDE by simple re-regestring module in nbbuild/cluster.properties.
For those who don't know NetBeans internals this was basically a 2 line change in a text file. > If the main advantage of split is "size", then we need to see new numbers when history is moved as well. I guess the biggest cluster will still be 300 - 500MB. We should run a full git filter, etc. and see. BTW, since we have commits that modify files in multiple clusters it would be nice to easily verify this in the future when we will have per cluster repositories. Perhaps the history split/migration script should be smart about this and use the same changeset ID across multiple repositories (if possible); or maybe generate some unique tag? --emi On Wed, Oct 12, 2016 at 4:54 PM, Vladimir Voskresensky < [email protected]> wrote: > On 2016-10-12 15:30 (+0300), Emilian Bold <[email protected]> wrote: > > As I mentioned before I don't see this an improvement of the status-quo, > > technically. > I would agree with Emilian, that the current structure proved to work and > it works reliable. > If the main advantage of split is "size", then we need to see new numbers > when history is moved as well. > > Btw, sometimes Java introduces the new feature, then C++ introduces the > same functionality, so we agree to make refactorings by generalizing common > parts and moving them into platform/nb layer, while keeping > Java-specific/C++-specific code in corresponding places. History is easier > manageable when it happens in one repo. > > As another example: we implemented Terminal in C++, then 'contributed' > into Full IDE by simple re-regestring module in nbbuild/cluster.properties. > One repo fits better, than moving modules between different ones > > Thanks, > Vladimir. >
