[Kde-games-devel] Re: Move to git

[Parker Coates]

On Mon, Jan 31, 2011 at 17:50, Stefan Majewsky wrote:
> Hi,
>
> as you probably noticed, the Git transition is moving faster than
> ever, so the following questions come up again:
>
> 1. When do we want to move? (I'm in favor of yesterday, though we
> should probably wait for the results of the merge-vs.-cherrypick
> discussion on k-c-d.)

While I'm also eager for the transition, I think patience is the right
course at the moment. I suspect that there'll be more Git migration
issues, conflicts, policy decisions, etc. uncovered during the next
couple weeks or so. Given our limited manpower and VCS expertise, I
think it's sensible to let others work through those for us. :)

Of course that doesn't mean that anybody interested in experimenting
with a Git transition should be waiting. I think we can all agree that
now is a perfect time to start playing with and testing experimental
Git repos.

> 2. Do we want a monolithic repository or split repositories per game?
> Given the current team size and the forthcoming changes regarding
> Project Tagaro, I'm in favor of a monolithic repo.

My personal opinion has flip-flopped a couple times. At first I
supported monolithic, but then the appeal of having clean, focussed,
application specific repos won me over. Now I'm kind of in between.
Could you elaborate on the reasons you gave above? Why would our small
team size make a monolithic repo better? What Tagaro plans would be
more problematic with multiple repos?

I think it'd also be valuable to research what KDE-Edu's plans are.
There are a lot of parallels between our modules, so I think we're
likely to share a lot of pros and cons on this topic.

> If we take the monolithic approach, I would also like to propose that
> libtagaro is merged right after the move as an unstable/private
> library. Then the static source copies of parts of Tagaro in Kolf and
> Granatier can be removed, and e.g. KDiamond can benefit from the
> improved theme loading capabilities in TagaroGraphics.

As I have mentioned before, for packaging reasons I don't think any of
our games can depend on a shared "unstable/private library",
regardless of repository structure.

I also think you forgot a very big question number 3. :)

3. What is the current state of our svn2git scripts? I think I
remember somebody writing some, but has anybody tested them? How
intact is the history, especially for applications surviving from the
CVS to SVN transition? Which approach (monolithic or per application)
do the scripts currently take? There's bit more to converting to Git
than just making the decision. ;)

Parker