[Tux4kids-tuxtype-dev] Branches and conflicts and git, oh my!

[B. Luchen]

Hey all,

Got a chance to put some more hours into wrapping the t4kcommon branch
up...or so I thought. I _really_ wound up spending half the day fighting
against merge conflicts upon trying to update with the latest changes in
trunk. Not fun. I'm still only perhaps halfway through it all (with plenty
of dubious "merges" already), and wondering if it's worth going further.
*ahem*

It was a mistake to branch off the whole honkin' repository. Not only did
this not jive with there being no branches/build/people/tags/trunk structure
at the repo root (for good reason), but it "branched" the existing branches
under each project. Not pretty. In hindsight it would have been more than
sufficient to leave the t4kcommon project under root and branch the trunk of
each project making use of it, separately.

As it is, stuff is so messy right now that I'm not convinced it's even
salvageable. Specifically in terms of source code, each branch has simply
changed too much in terms of file structure that neither line merging nor
manual examination can really do an adequate job to preserve all the new
developments. In other words, the files can hardly be compared any more.
Even if I or somebody else could cobble together a good enough
approximation, I fear the same thing would happen the next time I attempt a
merge. If it weren't for all the work Bolek put into that section of the
repo, I'd be ready to scrap it and start the right way. If couple others
would care to take a look at things and offer some ideas, that would be
cool.

In any case, when the dust has settled, here's what I recall remains to be
done before adopting the common lib (maybe I've missed something):
-Testing on Win32 and Mac
-Building/using dynamic (shared) libs
-Decide on dealing with t4kcommon being unavailable

I think David had mentioned preferring a shared lib to a static one. Was
there a specific reason for that? Distribution requirements, perhaps? The
extra complexity would mean some additional headaches, I think, especially
on other platforms. I'm still in favor of a plain ol' static library, since
it'll only be our handful of apps using it. Now, with regard to scenarios
where the lib isn't found, there's two possibilities: this happens at run
time (only if using a shared lib) or at compile time. The latter can be
dealt with by keeping an up-to-date copy of t4kcommon underneath each
project, to fall back on if t4kcommon isn't actually installed on the
development machine. But maybe this isn't the best way to go about it...?

Oh, git: I've been using git in school, and my experience has been that it's
_much_ (much!) faster and (after a learning curve) more friendly to merge
conflicts. I don't suppose it would eliminate the possibility of pouring
work into a branch and leaving it unmerged, but it'd make the job more
pleasant ;) The one possible drawback compared to SVN is that it's not as
well supported on Windows, but from a developer's standpoint that's not so
bad, because neither is svn+ssh. So here's one vote all in favor of moving
to it.

(tl;dr HAAAAALP!!)

Warm wishes to those on the snowy portion of the globe!

Kindest regards,
Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/tux4kids-tuxtype-dev/attachments/20091226/7d3536d6/attachment.htm>