Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

repository structure #23

Open
mikelovic opened this issue Dec 21, 2017 · 2 comments
Open

repository structure #23

mikelovic opened this issue Dec 21, 2017 · 2 comments

Comments

@mikelovic
Copy link
Member

mikelovic commented Dec 21, 2017

@case06 @DhavalGambhava
for a clean repo structure I want to propose following structure:
.../LibreSolarBox/...

  • ...components -> the needed components like UPK, libre solar CAD files, Batteryfiles, connectors, ...
    • .../components/frame
    • .../components/electric
    • .../components/battery
    • .../components/interface
  • ...box_designs -> folder in which the different components are set together
    • .../box_designs/v01_upk -> current version
    • .../box_designs/v02_upk -> next version

so the main folder would be components and design.
in components we should list all possible components we can integrate in the box.
in designs we should list all possible design how the components can be connected and enclosed.


feedback and suggestions are welcomed :) thx

@case06
Copy link
Contributor

case06 commented Dec 22, 2017

i am fine with the folder-structure but be aware that a repo may have dependend local-repos (upstream, downstream) and you have to make sure, that within them everything changes accordingly (automatically) if they try to synchronize.

So a suggestion: Make a separate repo for the V2-Version and introduce there the suggested folder structure from the scratch. "box-designs" then can contain instead different sub-versions.

@hoijui
Copy link

hoijui commented Mar 30, 2019

An ohter/additional suggestion: Make a script that creates the new folder structure and moves files around, fully automated. It can then be applied in forks, braches, and even to multiple/all commits in different git histories. It could be used to make a V2 repo, while keeping the (altored) project history.

This approach worked well for me in the past. one can continually apply the script to the old repo automatically, while still developing the script, until one is happy with the result, and while development is still going on in the project repo itsself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants