> 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 <
vladimi...@apache.org> wrote:

> On 2016-10-12 15:30 (+0300), Emilian Bold <emilian.b...@gmail.com> 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.
>

Reply via email to