How granular are your SVN projects: one large project containing several released applications or one “project” for each application

Question

I define the project as an SVN directory containing a chest, branches, sub dirs tags.

What criteria do you use when determining when to split a project into two or merge several projects into one? - One application for the "Project" with joint projects for a common source and resources? - One big "project" containing all the sources and resources for the application?

One project or multiproject has its pluses and minuses. We are heading for one project, and I'm trying to figure out if this is right.

Split projects allow you to more effectively control how the various parts of the package include changes. A shared library may be a version, and different applications may use a specific version (maven dep control approach).

A split project also creates several class hierarchies, which makes the code more difficult to understand as a whole and can potentially lead to duplication of code. I would suggest that the correct design of the overall structure and relationships between components would be key to managing this value.

A single approach to the project will make it easier for the developer to set up the workspace and provide a single class hierarchy. This is a double-edged sword, as it will also provide much more information for the developer (too many classes to understand).

So, when you are trying to decide where to combine and where to share, what rules of thumb are you using?

Answer 1

Thanks for the input. I will not “choose” the answer, because I think everyone has valuable points in them. Avoiding premature optimization seems to be key, as maintaining the layout is as simple as possible at the moment. We are moving on to one project containing applications, because 90% of the time we release ALL together. Therefore, to complicate the situation with one application for each project, it seems to make no sense. Even when we go to maven, it is likely that all maven artifacts for this version will be made from the same branch. We can always change it later if you need to use the SVN and fisheye story to keep us sane.

We reorganize the original layout in the same way as refactoring the source. When the project starts to smell bad from the situation of girth and dependence, we will break it, but not earlier than this. I will probably use grasp in time, not grasp in space: time for assembly and testing, time for verification. If I have a 1 GB tree that I can check in <10 minutes and builds / tests in <30 minutes I really don't need to break it unless I need to release parts of it often.

So thanks for the input. It was very helpful in framing my question for the team and evaluating options.

Answer 2

We put all projects related to one application into one SVN Rep just for ease of maintenance, centralizing the application code base in only one repository, as well as the ability to manage interdependencies between different application resources.

we usually categorize our resources into different folders within the trunk. that categorization is mainly based on functional / modular grouping or multi-level grouping [DAL, BLL, GUI, etc.]. it completely depends on how you structured the code. Hope this helps.

Answer 3

SVN Book has a good discussion of both approaches.

In the end, I would choose what seems more natural to users of the repository.

Personally, I approve of the SVN trunk / tags / branches approach with all my actual code projects in their own folders inside them.

However, for a larger code base (I managed only 3-4 small projects that were part of one solution), I would really like to switch to a split approach.

Answer 4

I use both individual projects and combined projects depending on the size of the project. For our large projects, each of them is in a separate repository and has independent assembly and deployment procedures. For our small projects, we have a “tools” repository to contain them, with each subproject being a subdirectory of the root.

I also maintain a “personal” repository where people can store one-time utilities for their test programs or other things that can benefit from source control and centralized backup, but do not belong to an independent project.

Answer 5

I use separate projects and combine them to form a solution through svn: externals.

Answer 6

One application / module that is deployed independently for each project. Using one project makes it difficult to introduce release cycles if you ever find out that you need to manage Maven -ish dependencies with a module depending on the stable implementation of other modules. It can also lead to people simply using random useful code from other applications directly, instead of decomposing it to save the Sane (tm) dependency graph.

Integration testing should be carried out using appropriate CI test suites and practices with a clear definition, and not under the condition that half of your code will not suddenly be unexpected if one part breaks.

Another problem with having one uber project is that it is quite burdensome for git-svn users who work with only one module.

Answer 7

Organically grow. Pre-optimization is the root of all evil, as Dijkstra once said. Also hold YANGI (you won’t need it).

Each application gets its own folder with trunk / tag / branch. If the project inside the application becomes really large, then it falls into a separate folder and can be attached to the application during assembly (or even svn: externals).

However, if your project requirements are to develop a complex application written by 10 developers, and you are a gatekeeper or assembly wizard, then you can consider more complex alternatives.

Answer 8

Keep separate SVN repositories for individual projects. The last thing you want is Merge Day

Answer 9

You might want to check the Subversion version number for several projects .

Answer 10

there is no “good” answer here, but I think there should be a difference between SVN repositories that contain 1 or 2 projects and others that contain 100.

I support the SVN repo, which was ported from VSS, it has several hundred “projects” in it, none of them were organized along the structure of the connecting lines / branches / tags (in fact, I believe that the structure is really unnecessary and useless after I used SVN for a while, this certainly will not help when you need to mark 2 or 3 projects as one change).

We maintain a project directory for all of our supported software, according to which we have subdirectories for configuration, and another for the source. At the same time, we have product version numbers - so effectively we discard the concept of the trunk, we only have tag catalogs - the highest number, which is a chest (we must do this because we must support several versions of projects at the same time). Merging occurs as needed, so if I update an error in Project A, version 3.0; I will combine these changes with versions 4.0 and v5.0.

If I only performed repos with 1 or 2 projects, I might be tempted to keep the branch / tag structure, but, on the other hand, I would probably keep the directories explicit in the main tree (assuming that I (I often use the revision number as a “tag” BTW, and I store binaries there. Therefore, if I need to get a specific old revision, I can get the correct binary information from viewing the log)

Its surprisingly easy to manage, given that I have a 10Gb repo with a jealousy that currently exceeds 300,000 with a lot of old code as well as newer. I would recommend the structure to others and will use it again.

By the way, another reason dir doesn't work for us is because we issue every time there is an error or request for change, no matter how tiny they are. After some time, our tag catalog will be unmanageable, so we use revnum as a tag - we can associate it with an error tracker to make it even more readable.

So, to summarize in a crude form, we have a directory structure where v1 and v2 are product versions:

maint/source/v1.0/projectA maint/source/v1.0/projectB maint/source/v2.0/projectA maint/source/v2.0/projectB etc 

obviously, we could put the branch branch in the "source" and the branch / tag under each subproject, but it will become difficult if we need to release 2 subprojects as one change request (as it often happens). Inclusion of a tag subdirectory in the source directory would mean that we would mark everything when only one subproject has changed (does not meet our requirement to track each subproject individually)