Managing the projects under the same repository: Yes\ No ?

This wiki is meant to deal with the question of whether to manage both Parking project and the Alexa project under the same repository or not.

Same repo - optional implementations

We explored the options for manageing multiple projects under the same repository:

Sub-trees

This option allows a project to be managed as a sub-tree (sub-repo) of a given repo, while changes in the "father" repo won't affect the sub-repo, unless manual-pulling is done. This can be seen at https://help.github.com/articles/about-git-subtree-merges/

Sub-modules

This option allows a project to be managed as a sub-tree (sub-repo) of a given repo, while changes in the "father" repo do affect the sub-repo. This can be seen at https://git-scm.com/docs/git-submodule

Adding Project

We explored the option at https://github.com/TechnionYP5779/team5/projects , but it seems that it only creates a project-board, which its purpose is to manage a TODO-list for the projects, and not actually manage a seperate project under the same repo.

Same repo: Pros/Cons

Pros

• modules that can be shared between the two projects can be accessed and managed more easily
• easier tracking of the team's progress (including collected knowledge stored in wikis), either by the course's staff or the team members (in case we want to move teammates between projects)

Cons

• working history is messy and more complicated to track, because it contains hostory of both projects
• any desired changes in one project might affect the second one as well (e.g. in terms of reverting a project to an older commit)
• external Github users watching the repo might get confused (is the .readme file should contain information about both projects?)
• though possible, it leads to a more complicated management of CI
• Java11 isn't supported by AWS lambda-functions (of Alexa), it may cause us to downgrade the Parking project to Java8, orelse management of two Java version projects in the same repo might be cumbersome

Separated repos: Pros/Cons

Pros

• clean history for both projects, changes and progress can be tracked more easily
• changes in one project won't affect the other one
• more readable for external users
• two separated CI can be managed more easily
• Java versions of the repos are independent

Cons

• modules that can be shared between projects might be duplicated in some way
• more difficult to manage two repos instead of one, including tracking team's progress

Conclusions

We think that separate repos are better than managing both projects on the same repo, for the following reasons:

• as for the issue of the shared modules: actually, it seems that there are little-to-none shared modules between these projects, as the Alexa's interface does use neither GUI nor web modules, and about the DBs and user session - it is already managed by Amazon-Alexa's interface, while in the Parking projects it should all be done manually.
• we manage weekly-detailed Wikis about our progress in both projects, so moving between the two projects should be easy and informative.
• if we'll change our decision and decide to consolidate both repos to a single repo, it will be easier than spliting a single repo into two.