Hey all,<br><br>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*<br>
<br>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. <br>
<br>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.<br>
<br>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):<br>-Testing on Win32 and Mac<br>-Building/using dynamic (shared) libs<br>
-Decide on dealing with t4kcommon being unavailable<br><br>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...?<br>
<br>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.<br>
<br>(tl;dr HAAAAALP!!)<br><br>Warm wishes to those on the snowy portion of the globe!<br><br>Kindest regards,<br>Brendan<br>