vbabuEM
commented
5 months ago On the issue of multiple projects in a single repository, we do not have many options.
- One solution that some people use involves orphan branches or other branching strategies. That seems very difficult to enforce on all developers.
- There are options to clone only one subfolder, but again this involves a process and tough to implement across developers.
So here are my recommendations for beckn-utilities.
- It should not have any project that has github integration in its workflow (e.g. projects that automatically deploy on server when we checkin code etc). The reason is that it might be difficult to configure and the workflow will be triggered when unrelated files are modified.
- It should not have any project that has Continuous Deployment component. Again similar to 1 above. It will involve deployment when unrelated files are modified.
- It should not have any project that will involve large community component. The reason here simply is that we will be asking users to get unrelated code onto their workspace.
- It should not be used for projects which have binary assets such as images, pdf files etc. The reason is that in text based SCM tools, these are usually kept as is without diff and so the overall repo size will be high.
- It can be used for small tools that have their own publishing workflow (e.g. npm libraries)
- It can be used for internal tools and projects which involves very few developers (preferably only internal)
- When in doubt, I think we should use separate repo.
Currently the beckn-utilities repo has a bunch of small unconnected projects. It has been structured this way to prevent having an entire repo for a simple tool (like the beckn-validator tool). However a side effect of this organization is that if someone wants to develop on any of the project (present in a subfolder), they have to clone the entire repo and then delete/ignore most of the other sub-folders. Investigate if we have any options to improve this workflow.