--nextPart4021693.TDokKaAQg2
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 11 July 2007 08:05:43 am Paolo Capriotti wrote:
> since a few days, I've been experimenting with git for managing my KDE
> project (playground/games/kboard) and git-svn to interface back to the KDE
> svn repository.

Yeah, while I haven't gotten around to KDE hacking yet (I'm still pulling d=
own=20
revision history via git-svn), I use git pretty much exclusively at work,=20
even though the central repository it SVN.

I am really liking git as a tool for myself personally, but there's a numbe=
r=20
of issues with it that I think would make moving the KDE project over to=20
it... something approaching disastrous.  The inability for git to pull less=
=20
than the entire history of the project for the initial checkout is a large=
=20
issue (bazaar has fixed this flaw in their distributed VCS).

I've also played with bazaar, and read a bit about darcs and mercurial.  As=
=20
best I can tell, none of them are the right fit for KDE as a whole, and I d=
o=20
think there's a lot of value in the way KDE organizes their massive tree.

> Git encourages a development model where many branches are created,
> features are developed out of the main line, and then merged back to the
> master branch. This is something which is hardly possible with svn (and
> impossible, if one wants to keep some of the branches private), but IMHO
> highly desirable for many KDE projects.

It's quite possible to do merges with SVN that are quite complex.  However,=
=20
you end up having to do more manual merging than you would with git AND you=
=20
end up having to keep track from merge points manually (or at least in the=
=20
commit message).  Basically branching and merging are much easier and take=
=20
less time (manual intervention) in git.

You also need not be afraid of long lived branches in git, as long as you p=
ull=20
changes in one direction with some degree of frequency (e.g. trunk -> featu=
re=20
branch).  Since it keeps track of merge points, it's smarter about weaving=
=20
the two branches back together when you finally pull the other way (e.g.=20
completed feature branch -> trunk).

> Using git-svn when the git repository is used by more than one developer =
is
> quite hard, and I could not manage to make it work properly (i.e. without
> adding extraneous 'merge' commits to svn), so I've decided to switch
> development completely to git (at least for the moment) to try it out
> fully. However, moving away from the KDE svn repository apparently means
> that the project is not anymore part of KDE, and will not be until moved
> back there. KDE reviews and translations are based on svn, as well as
> tagging for the releases.

Yeah, and neither a) moving the whole of KDE to git nor b) allowing the KDE=
=20
project to be split across multiple VCSs, or even c) remove your program fr=
om=20
the KDE project is an acceptable option. So, you'll have to take d) abandon=
=20
git, or e) do the extra work necessary to keep a KDE SVN <-> public git=20
gateway synchronized.  (Or of course, any of the spectrum of options betwee=
n=20
(d) and (e), including only using git privately.)

Yeah, there are numerous issues, but with some massaging I think you could =
get=20
(e) working, at least most of the time.  I'd be open to helping you write t=
he=20
cron scripts to drive this.  This largest issue is that you should git-svn=
=20
prefers that you rebase branches off a SVN branch, but rebase-ing a public=
=20
branch should be done as little as possible to make downstream pull-ing=20
easier.

There numerous upsides to getting (e) working; I can see it being genuinely=
=20
useful outside of your project and my work.

> What I would like is some kind of official support for projects that wish
> to use git (or maybe other distributed VCS's?).

That would involve (b) above, at the least, and that's a monster task.=20

Although if (e) was complete, it would be much easier.

It seems like the easiest way to handle (e) would be to have a private bran=
ch,=20
that was regularly rebased back and forth between the git-svn branch and th=
e=20
public branch that wants to track SVN.  With each rebase, you might need th=
e=20
script to call for human assistance.

=2D-=20
Boyd Stephen Smith Jr. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ,=3D ,-_-. =3D.=20
bss03@volumehost.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 `-'(. .=
)`-'=20
http://iguanasuicide.org/ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0\_/ =C2=A0 =C2=A0=20

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

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

iD8DBQBGlr9EdNbfk+86fC0RAmK/AJ0bZ19R0N3OJClcyyckOEaeRKbKvQCfRWjZ
jPvKWSezWIePwo2iS3091/4=
=2Wym
-----END PGP SIGNATURE-----

--nextPart4021693.TDokKaAQg2--