[Bro-Dev] CBAN design proposal

[Siwek, Jon]

> On May 26, 2016, at 11:14 PM, Robin Sommer <robin at icir.org> wrote:
> 
>> Is it an important use case for the client to be able to interact w/
>> other repos that are structured like the one the Bro Team will be
>> hosting?  Seems less likely that people will want to do that
>> especially if the CBAN repository is easy enough for people to submit
> 
> Yeah, agree it's less important with that liberal model. I would still
> like to support it though unless it's a major pain.

Ok, I’ll plan from the beginning to be able point to multiple CBAN-like repository structures and then complain if I find out it’s complicated to support that.

>> The client's “update” command will do a “git pull” in the parent repo
>> and then a “git fetch” in any installed submodules.
> 
> So does that mean the client ignores the version that the central CBAN
> parent repository points to? Say Seth finished version 1.0 of his
> cool-plugin and files a merge request. We add the submodule to CBAN;
> it will point to 1.0. Then Seth updates to 1.1 on his end. CBAN would
> still point to 1.0, but clients would just move their local clones to
> 1.1, ignoring the parent repository's state. Is that what you have in
> mind?

Yeah, the parent repo would always point to the first version that was submitted, but when a user chooses to install something, that submodule gets initialized/cloned and the user can choose to use whatever version of it they want.

And it won’t be the common case for a user to be doing any actual work inside the parent repo (unless they’re working on the cban client code), so it shouldn’t be a big deal if things like `git status` in the parent repo show a bunch of the “new commits” messages for each installed submodule.  But I’ll also probably structure it so all submodules get cloned in to a subdirectory and then list that subdirectory in .gitignore to limit the noise.

- Jon