硬件 (ECAD)、文档和固件项目的版本控制工作流/架构建议

Question

Shall we use SVN or GIT? for the following use case

How shall we organize the system:

1: "master repo" containing all the projects and stand alone drivers as that the projects use, each project / driver being a different "branches"?

example:

MasterRepo
|-Project1
| \---Hardware
|     \--ECAD
| \---Firmware
|     \--src
|     \--includes
| \---Documentation
|-Project2
| \---Hardware
|     \--ECAD
| \---Firmware
|     \--src
|     \--includes
| \---Documentation
|-Drivers
| \---driver1
|     \--src
|     \--includes
| \---driver2
|     \--src
|     \--includes

2: Separate repos for each project and stand alone drivers? we will need to "pull" or "merge" from the driver repo into the project repo. This is important to show tractability to know which projects are affected in the case of a bug in the driver layer.

Project1Repo
|---Hardware
|   \--ECAD
|---Firmware
|   \--src
|   \--includes
|---Documentation


Project2Repo
|---Hardware
|   \--ECAD
|---Firmware
|   \--src
|   \--includes
|---Documentation


DriversRepo
|---driver1
|   \--src
|   \--includes
|---driver2
|   \--src
|   \--includes

Shall Hardware be in a separate repo completely?(we are embedded software engineers we need to see schematics and know when there are changes or suggest changes etc. )

Shall each driver be in separate repo?

We are an embedded electronics company, in the automotive industry. Until i started the software team did not use any versioning control system, everything was "versioned" via folders and zips. and the Hardware side of things still use that way of versioning.

We have started using SVN(but not tied to it). We are currently for software using the adhoc made-up model of the following:

MasterSoftwareRepo
|-Documentation
|-MicroControllerMFG1
| \--FamilyOfMCUs
|    \--Drivers
|    \--Projects
|       \--Project1
|          \--active
|             \--src
|             \--test
|             \--build
|          \--release
|             \--srev1
|             \--srev2
|             \--srev3
|          \--projectSupport
|       \--Project2
|          \--active
|          \--release
|          \--projectSupport
|       \--Project3
|-MicroControllerMFG2
| \--FamilyOfMCUs
|    \--Drivers
|    \--Projects
|       \--Project10
|       \--Project11
|       \--Project13
|-MicroControllerMFG3
| \--FamilyOfMCUs

.......................and so on. 

The system works... Its not pretty, nor is it efficient. As we have only used the system for say 6 months and have occurred a total repository size of over 40gigs. And due to the structure we arnt really using the version control as intended, its more folders with history.

Also some more background, our team is mid-size but the teams working on each project is very small... 1 software, 1 hardware, 1 mechanical per project. and each of us may have 1-2 projects at a time. We have 20 something people in our department.

So the big idea of merge conflicts due to people working on the same project or file is non-existent as the repos are truly just here to track ourselves, and keep documentation of changes, etc.

What are some suggestions for our use case? The 1 repo idea is too big we believe but we are stuck on the idea of using that so we can pull from the drivers. and base project structure etc. so we have full tractability to the beginning.

Shall Hardware be a separate repo? can we include it in our repo as a branch or how would we do that?

Not using hosted solutions, all solutions need to be self hosted.

And yes, I know this is a long post, but I figured the more detail I gave the better you may understand the situation and our usecase.

Answer 1

If you have been using the repository for 6 months and it is already 40 gigs in size, it will likely become too large to easily manage over time.

For a problem like you are encountering, I would recommend switching over to git - but using git-lfs to manage your binary (non-ascii) files. git-lfs allows users to only have the latest version of a binary file locally - whereas with normal git, all previous versions of every file are stored locally (in a compressed form).

This would allow you to keep your documentation and ECAD in the same repository - but only see the current/latest version of the files locally.

I think the first repository option will be the best solution currently

MasterRepo
|-Project1
| \---Hardware
|     \--ECAD
| \---Firmware
|     \--src
|     \--includes
| \---Documentation
|-Project2
| \---Hardware
|     \--ECAD
| \---Firmware
|     \--src
|     \--includes
| \---Documentation
|-Drivers
| \---driver1
|     \--src
|     \--includes
| \---driver2
|     \--src
|     \--includes

As for the number of branches - are you able to do all of your testing on the branch from the pull request? or do you need your changes to be tested for 1-2 months before determining if they are stable/good?

If the first option is realistic, I think a single 'master' branch would work - where you submit a pull request and do all of your testing on that branch before merging that PR into the main master line.

If the second option is better, you could go with a dual branch structure- one 'master' and one 'stable' - where you have a main development branch that is in testing - and a final release/stable branch where changes will go - once they are proven on the development line.

If in the future you plan on having an extremely large number of projects where even storing a single copy of each file becomes too large you could also look into git submodules (separate repositories but each project repository would contain a pointer to a certain point in time in another repository). The last option would be to look into using Virtual File System for git - but this option would limit any git GUI options you may be looking into.