Menu
I define a project as an SVN directory containing trunk, branches, tags sub dirs.
What criteria do you use when determining when to split a project into two or consolidate several projects into one? - One App per "Project" with a shared projects for common source and resources? - One big "project" containing all source and resources for the app?
Single project or multi project both have their pluses and minus. We are heading more towards a single project and I'm trying to figure out if this s the right approach.
Split projects allow greater ability to control how different parts of the suite incorporate a change. The common library can be version and different applications can chose to use a specific version (maven dep management approach).
Split project also create multiple class hierarchies making the code more difficult to understand as a whole and potentially leading to code duplication. I would assume that proper design of the overall structure and the relationships between components would be key to managing this cost.
A unified project approach will make it easier on the developer in terms of setting up a workspace, and provide a single class hierarchy. This is a double edged sword as it will also throw much more information at the developer (too many classes to comprehend).
So, when you are trying to decide where to combine and where to split, what rules of thumb do you use?
221
But using one big monolithic repository won't work in Git. With Git, using multiple repositories is the only way to work efficiently. This enables each team to work independently, and do their work faster.
Yes. You can put multiple projects in one Git repository but they would need to be on different branches within that repo. The Git console in ReadyAPI gives you the ability to create or switch branches from the UI. More information on the Git integration can be found here in the documentation.
SVN also enables you to quickly retrieve versions of a code repository through the checkout process. While SVN doesn't support nested repositories, you can still retrieve and combine changes found in multiple code repositories into one working copy of the code using the command svn:externals.
We put all the projects related to a single app within one SVN Rep simply for the sake of ease of maintenance, centralizing the app's code base in one repository only and also ability to manage the interdependencies between different resources of the app.
we generally categorize our resources into different folders within trunk. that categorization is primarily based on the functional /modular grouping or layered grouping [DAL, BLL, GUI, etc.]. that is completely upto how you have structured the code. Hope this helps.
197
The SVN Book has a good discussion on both approaches.
In the end I would choose whatever feels more natural to repository users.
Personally, I've favoured a single SVN trunk/tags/branches approach with all my actual code projects in their own folders inside those.
However, for a larger code-base (I've only managed 3-4 small projects which were part of a single solution), I would highly consider changing to a split approach.
40
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
