[VERY FIRST TO TACKLE] decide on repository structure

[M-Welsch]

Description

we want a common understanding of which repository to use, which branch to use and where to place files. Last one is not a hard line because this one can easily be refactored

What happens if we don't do it (aka Why is it important)?

• we don't have a place to put the files we are working with

Definition of Ready

• no prequisites

Key Tasks

• [x] decide on single repository or multiple repositories
• [x] decide whether we make a new branch and name it
• [x] decide how to structure the project

Acceptance Criteria

• [x] we have a place where to push our changes to

[M-Welsch]

Single vs. Multiple Repos

Pro Single

• the components of the backup server only make sense together. PCU doesn't work without a hardware and a BCU to interact with. Likewise the Webapp as frontend needs the BCU as backend
• only one repository to check out
• developers can easier see the work of the others
• easy to draw a common baseline, like "this bcu works with this pcu and hardware"
• easier to see inconstencies between repos
• possible to start clean

Pro Multiple Repos

• smaller repos instead of one big repo
• merge conflicts are more probable
• possible to exclude webapp as an optional component
• different frontends possible ("Baukastenprinzip")
• need to feed git history from former repos into the new one

Discussion

we see advantages for the single repo approach. Regarding the disadvantages:

• a big repo is not a real problem (we have bandwidth and space)
• merge conflicts aren't probable because the parts are well separated (BCU, PCU, hardware, Webapp)
• webapp shouldn't be excluded
• no other frontends are planned

well, we need to put the histories of the older git repos into the new one.

Conclusion

• some real advantages for the Single Repo Approach
• disadvantages of single repo are either small, improbable or unrealistic
• we do the work of putting the repos together. We use the single repo approach

[M-Welsch]

done