[Architecture] Git repository layout for desktop personalization

Kasper Galschiot Markus kasper at raisingthefloor.org
Thu Feb 23 14:05:22 UTC 2012


That's a great idea Boyan!

Will make a suggestion for an updated diagram!

~Kasper

On 2/23/12 2:00 PM, Boyan Sheytanov wrote:
> Hi Colin,
>
> This repository structure seems very well-suited, as it naturally 
> encompasses the three architecture levels:
> 1. Cloud components
> 2. Local platform-independent components
> 3. Local platform-specific components
>
> On an unrelated note, it might be useful to modify the program flow 
> diagram to more clearly depict these three levels, which would make 
> the architecture much easier to grasp at first sight.
>
> Best,
> Boyan
>
> On Wed, Feb 22, 2012 at 20:46, Clark, Colin <cclark at ocadu.ca 
> <mailto:cclark at ocadu.ca>> wrote:
>
>     Hi developers,
>
>     I've been contemplating the issue of how we should structure our
>     repositories in Git for easy development, collaboration, and
>     installation. Here's a rough proposal followed by a few questions.
>
>     It makes sense to define a small number of repositories divided
>     along "physical" boundaries within the architecture:
>      1. The preferences server
>      2. The cross-platform local desktop modules (e.g. the match
>     maker, the flow manager, the solutions registry, etc.)
>      3. One platform-specific repository for each platform (Linux,
>     Windows, eventually Mac), containing any platform-specific
>     bindings (e.g. the gsettings handler, the USB stick user listener,
>     etc)
>
>     This would make it quite easy to eventually automate the release
>     and installation process, where a script could assemble only the
>     repositories needed for a given platform.
>
>     Yura and I were chatting about this layout today in the office,
>     and he raised the question, "Where do the common bits of code and
>     configuration go, such as our Infusion Node module, the DataSource
>     abstractions, etc.?" In the old days of SVN, this is probably
>     something we'd use SVN externals for, allowing us pull in common
>     code from a separate repository. Git has submodules, but they're a
>     little more complex and perhaps less suited to this particular
>     process. Any other ideas for how we might manage separate but
>     shared resources like this?
>
>     Other thoughts or suggestions about this repository layout proposal?
>
>     Colin
>
>     ---
>     Colin Clark
>     Lead Software Architect,
>     Inclusive Design Research Centre, OCAD University
>     http://inclusivedesign.ca
>
>     _______________________________________________
>     Architecture mailing list
>     Architecture at lists.gpii.net <mailto:Architecture at lists.gpii.net>
>     http://lists.gpii.net/cgi-bin/mailman/listinfo/architecture
>
>
>
>
>
> _______________________________________________
> Architecture mailing list
> Architecture at lists.gpii.net
> http://lists.gpii.net/cgi-bin/mailman/listinfo/architecture
>
> -- 
> Kasper Galschiot Markus
> Research Engineer,
> Raising the Floor - International,
> www.raisingthefloor.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/architecture/attachments/20120223/b38fcbf4/attachment.html>


More information about the Architecture mailing list