--===============1440509993==
Content-Type: multipart/signed;
  boundary="nextPart3814863.a5YBOEusBt";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart3814863.a5YBOEusBt
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Thursday 12 November 2009 ext Oswald Buddenhagen, wrote:
> > -> every module in KDE gets a repo, every project in support/extragear
> >    gets a repo, koffice gets a repo
> > -> subprojects, like games or edu might choose to have a repo per app,
> >    however, they will have to help out then. Otherwise, they get lumped
> >    together. Will have to ask the module maintainers (TASK: Chani will =
do
> >    the asking)
> > -> if a subproject wants to separate all their apps, someone will have =
to
> >     help them (TASK)
>=20
> i still think (more than ever) that doing big modules is just plain
> wrong. i'm still not convinced by a single kdelibs, but even considering
> to allow lumping codebase-wise completely unrelated applications into
> common repositories is insane.
>=20
> disadvantages of big repos:
> - huge clones for everybody
> - loss of history. there are only two clean ways to preserve history
>   when moving around applications: have everything in one repo (like in
>   svn, but that just plain does not work with git) or have no need for
>   moving at all, i.e., have idependent atomic applications and do moves at
>   an abstract level (possibily via submodules).
> - merging mess (random conflict resolution). forward-merging stable =3D>
>   master is hard enough in qt already, and that's a well-organized
>   (kinda ;) company of full-time workers and "only" two major time zones.
>   imagine the bottlenecks in a disorganized bunch like kde. it simply
>   won't work.
>=20
> advantages of big repos:
> - it's simpler to check out all at once. wow. i'm impressed.

I agree with Oswald here.

Git scales well with repositories, it does not scale well with the number o=
r=20
files inside a repository. That applies to the performance as well as the=20
merging woes that you get.

Speaking from experience: We did that mistake with Qt. We did not take the=
=20
time to split up Qt when we switched to git, and now we have one big=20
repository that contains lots of unrelated code. When merging between=20
difference maintenance and development branches we frequently have to resol=
ve=20
other people's merge conflicts. Sometimes the owners of the code are not=20
reachable and then we either have to figure it out ourselves (error prone!)=
 or=20
we have to delay the merge, which is bad.

In addition with Qt the use of git is slow on non-Linux platforms.

We do plan to split up Qt into separate modules. If you look around how oth=
er=20
projects converted to Git or Mercurial then you can observe the same patter=
n.

Therefore I recommend one repository per application, in some cases=20
application + library (say konqueror + libkonq in one repository).


Simon

--nextPart3814863.a5YBOEusBt
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAksBDS8ACgkQWXvMThJCpvI3mwCg/htIvurb0EVtYAHCFAqPxsvq
eG8AoKm8iPW7Wxo+b+8NwqcGPr26fp1b
=XBru
-----END PGP SIGNATURE-----

--nextPart3814863.a5YBOEusBt--

--===============1440509993==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Kde-scm-interest mailing list
Kde-scm-interest@kde.org
https://mail.kde.org/mailman/listinfo/kde-scm-interest

--===============1440509993==--