KDE development with git

Boyd Stephen Smith Jr. bss03 at volumehost.net
Fri Jul 13 00:54:39 BST 2007


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 down 
revision history via git-svn), I use git pretty much exclusively at work, 
even though the central repository it SVN.

I am really liking git as a tool for myself personally, but there's a number 
of issues with it that I think would make moving the KDE project over to 
it... something approaching disastrous.  The inability for git to pull less 
than the entire history of the project for the initial checkout is a large 
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 
best I can tell, none of them are the right fit for KDE as a whole, and I do 
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, 
you end up having to do more manual merging than you would with git AND you 
end up having to keep track from merge points manually (or at least in the 
commit message).  Basically branching and merging are much easier and take 
less time (manual intervention) in git.

You also need not be afraid of long lived branches in git, as long as you pull 
changes in one direction with some degree of frequency (e.g. trunk -> feature 
branch).  Since it keeps track of merge points, it's smarter about weaving 
the two branches back together when you finally pull the other way (e.g. 
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 
project to be split across multiple VCSs, or even c) remove your program from 
the KDE project is an acceptable option. So, you'll have to take d) abandon 
git, or e) do the extra work necessary to keep a KDE SVN <-> public git 
gateway synchronized.  (Or of course, any of the spectrum of options between 
(d) and (e), including only using git privately.)

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

There numerous upsides to getting (e) working; I can see it being genuinely 
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. 

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 branch, 
that was regularly rebased back and forth between the git-svn branch and the 
public branch that wants to track SVN.  With each rebase, you might need the 
script to call for human assistance.

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03 at volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070712/69b041d2/attachment.sig>


More information about the kde-core-devel mailing list