How Granular are your SVN "projects": one big project containing several releated apps or one "project' per app

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

I use both separate projects and combined projects depending on project size. For our large projects, each one is in a separate repository, and has independent build and deployment procedures. For our smaller projects we have a "tools" repository to contain them, with each sub-project as a subdirectory of the root.

I also maintain a "personal" repository where people can store their test programs one-off utilities, or other things that could benefit from source control and centralized backups, but does not belong as an independent project.

Answer 5

One app / module that is deployed independently per project. Using a single project makes it difficult to introduce release cycles if you ever find out you need Maven -ish dependency management with a module depending on stable implementations of other modules. It can also lead to people just using random useful-looking code from other apps directly instead of factoring it out to keep the dependency graph Sane (tm).

You should do integration testing using proper test suites and CI practices at clearly defined , not by relying on half your code failing all of a sudden if one part breaks.

Another problem with having a single uber-project is that it's rather onerous for git-svn users that only work on a single module.

Answer 6

Keep separate SVN repositories for separate projects. The last thing you want is to have a Merge Day

Answer 7

Grow organically. Pre optimization is the root of all evil, Dijkstra once said. Also keep YANGI (you ain't gonna need it) in mind.

Every application gets its own folder with trunk/tag/branches. If the a project within an application gets really big, then it gets pushed to it's own separate folder and can be linked to the application at build time (or even svn:externals).

That said, if your project requirements are to develop a complex application written by 10 developers and you are the gatekeeper or build master then you can consider more complex alternatives.

Answer 8

You might want to check out Subversion revision number across multiple projects.

Answer 9

Thanks for the input. I won't "choose" an answer because I think all have valuable points in them. Avoiding premature optimization does seem key as does keeping the layout as simple as possible for the time being. We are moving to a single project containing the apps because 90% of the time we release ALL together. Therefore, to complicate matters with a one-apps-per-project doesn't seem to make sense. Even when we go to maven it is likely that all maven artifacts for a given version will be made from the same branch. We can always change it later if need be using SVN history and fisheye to keep us sane.

We'll refactor the source layout just like we'd refactor the source. When a project starts to "smell bad" from a girth and dependency situation we'll break it up, but not before that. I'll probably use girth in time not girth in space: time to build & test, time to checkout. If I have a 1GB tree that I can checkout in < 10 minutes and build/test in < 30 minutes I don't really need to break it up unless I am required to release parts of it frequently.

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

Answer 10

there's no 'good' answer here, but I think there should be a distinction made between SVN repos that contain 1 or 2 projects, and others that contain 100.

I maintain a SVN repo that was migrated from VSS, it has several hundred "projects" in it, none of them have been organised along the trunk/branch/tag structure (in fact I think that structure is really unnecessary and unhelpful after I've used SVN for a while, it certainly doesn't help when you have to tag 2 or 3 projects as a single change).

We maintain a project directory for all our maintained software, under that we have subdirs for configuration and another for source. Under those we have product version numbers - so effectively we are throwing away the concept of trunk, we only have tag directories - the highest number being the trunk (we have to do this as we have to support several versions of the projects simultaneously). Merging happens as needed, so if I update a bug in project A, version 3.0; I'll merge those changes to version 4.0 and v5.0.

If I were to do a repo with just 1 or 2 projects, I may be tempted to keep the branch/tag structure, but on the other hand - I'd probably keep the directories explicit in the main tree (assuming I didn't release often enough to tag regularly)(I use the revision number as a 'tag' BTW, and I store binaries in there. So if I need to get a particular old revision, I can grab the right binary from looking at the log)

Its surprisingly easy to manage considering I have a 10Gb repo with a revnum currently up past 300,000 with lots of old code in there as well as newer. I would recommend the structure to others and will use it again.

Incidentally, one other reason tags dir wouldn't work for us is because we release every time there is a bug or change request, no matter how tiny. Our tags directory would be unmanageable after a while, this is why we use the revnum as a tag - we can associate it with the bug tracker to keep it more human readable too.

So to summarise in rough, we have a directory structure like this 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 a branch dir under 'source', and a branch/tag under each subproject too but that would become tricky if we needed to release 2 subprojects as a single change request (as we do quite often). Putting a tag subdir under the source dir would mean we tag everything, when only a single subproject got changed (doesn't fit with our requirement to track each subproject individually)