@Matthias if my post has offended you in any way, then please accept my
apologies, it was never my intention.
In order to avoid such misunderstandings in the future, may I suggest
that you adjusted your email client to delete messages from me
automatically?
Thanks.
07.09.2020 16:12, Matthias Bläsing wrote:
Hi,
before this is even considered, you should state what is the problem
(at that means concretely), then describe the options to solve it, then
pose why submodules fix it, then describe the problems of submodules,
then describe why the workflow of all other developers needs to be
broken, then describe the consequences for the buildsystem. As you can
see there is a long list of things to do, before even considering
introducing a new technology into the netbeans build system.
To be frank: What is the f****** problem? Cloning the netbeans
repository with a depth of 1 results in this:
matthias@athena:~/tmp$ time git clone --depth=1
[email protected]:apache/netbeans.git
Cloning into 'netbeans'...
remote: Enumerating objects: 95646, done.
remote: Counting objects: 100% (95646/95646), done.
remote: Compressing objects: 100% (61517/61517), done.
remote: Total 95646 (delta 36963), reused 57418 (delta 22084), pack-reused 0
Receiving objects: 100% (95646/95646), 87.47 MiB | 2.68 MiB/s, done.
Resolving deltas: 100% (36963/36963), done.
Updating files: 100% (80311/80311), done.
real 0m58.594s
user 0m9.030s
sys 0m3.475s
matthias@athena:~/tmp$
This means: ~ 90MB are cloned in under 60s. This test was executed from
a hotel wlan, from a fixed connection it would have even been quicker.
I also tried a full clone:
matthias@athena:~/tmp$ time git clone [email protected]:apache/netbeans.g
it
Cloning into 'netbeans'...
remote: Enumerating objects: 14, done.
remote: Counting objects: 100% (14/14), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 327867 (delta 3), reused 5 (delta 2), pack-reused 327853
Receiving objects: 100% (327867/327867), 194.90 MiB | 2.76 MiB/s, done.
Resolving deltas: 100% (181522/181522), done.
Updating files: 100% (80311/80311), done.
real 1m21.883s
user 0m23.210s
sys 0m5.686s
matthias@athena:~/tmp$
For repeated contributions this is a one-time action.
My gut feeling is, that the size of the binaries required for building
is larger.
If you think, that you can build a cluster of netbeans independently
from the others you are wrong, there are dependencies between the
clusters and some of these are not just friend dependencies, but
implementation dependencies. Yes that is all solveable, but at what
price?
Sorry if this sounded rude, but I've seen such "sounds like a good
idea, lets do it" actions in the past and had to cleanup the mess, that
resulted.
Greetings
Matthias
Am Montag, den 07.09.2020, 09:08 +0200 schrieb Czukowski:
IMHO the value of splitting the source code into multiple
repositories
would really come up if it were possible (and practical) to develop
NetBeans modules independently, for example, clone a module repo,
work
on it, then run/test it using an already built IDE, then release the
module update (increment the version, etc). And when the time comes
to
release new NetBeans version, build script would pull all the pieces
together.
Then again, they don't necessarily need to be git submodules as they
could prove to be a little hard to use due to having to link them
all
using git and re-link on each update. It would suffice if the build
script just knew where to get them (eg. repo URLs), then if a
specific
cluster is build, it wouldn't be necessary to download all of them.
Regards.
06.09.2020 16:15, Eric Bresie wrote:
While reading an article recently, the topic of git submodules came
up, which I started looking up the topic (1).
Given the size of the netbeans code base and the complexity of
other projects inclusion like the specific plugin/clusters, etc., I
was wondering if it’s worth considering breaking out some of these
elements into separate submodule projects.
This would reduce the overall size of the netbeans project (but the
placeholder submodule - normally empty until submodule is pulled)
and would allow each submodule to be managed independently.
The drawback may be a little learning curve on submodule usage
which may add to some issues initially as well as a few extra steps
during builds.
(1) https://git-scm.com/book/en/v2/Git-Tools-Submodules
Eric Bresie
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
