CODEWITHSUNDEEP
svnproject-managementprojects-and-solutionsproject-structure
Max
Max

Reputation: 153

SVN in distributed development - best practice?

What are practically proven SVN structures for distributed systems which are developed by several independent suppliers?

Suppose a system with e.g. three layers (UI, Service, Data) and service contracts between them: each layer consists of several components which are developed by different suppliers which are not tied to a particular layer, e.g. supplier A develops components for UI and Service Layer and supplier B develops components for Service and Data layer.

Each supplier should only have write access to its own components as well as read access to required service contracts.

-> What is a good way to structure your SVN in such setting?

By supplier? By layer? Both? ... ?

Upvotes: 1

Views: 660

Answers (3)

Dan Nissenbaum
Dan Nissenbaum

Reputation: 13928

For clarity, I recommend organizing the structure by layer. That way, looking at the structure reveals the relationship between components. Even if there is more overhead for clients (i.e., suppliers), or more overhead for setting up each client's access to the repository, this will be worth it because each client will become accustomed to thinking about the project's overall structure, which will lessen the possibility of bugs and API conflicts in the long run.

This is a case where if managers have their way, they might be inclined to separate the repository by supplier. As a programmer, you know better. Put some of the work on the manager to see to it that proper workflow practices are adhered to - for the sake of clarity and better programming.

Also, just having different suppliers see each others' work within the same structure will, in that small way, encourage interaction (however small). This is, again, an effort for openness and commununication to weigh more heavily than security and restrictions. If you have say-so as a programmer at the beginning, it's an opportunity.

By the way, Git is superior to SVN.

Upvotes: 3

rainecc
rainecc

Reputation: 1502

You need to keep suppliers separate so will need isolation there. A trunk for each supplier component makes sense for that.

In a recent major software project, we allowed each supplier their own repository, with read access to the others. We then created a read-only consolidated trunk using triggered scripts. These were run daily, at midnight.

The consolidated trunk was then pulled by a Jenkins build environment that did regression and system integration tests, posting failures and issues back to the development teams for the start of each day.

Upvotes: 2

Andrey Adamovich
Andrey Adamovich

Reputation: 20683

If those suppliers are really independent, then I would not advice to keep all those components in one SVN repository. I would rather give suppliers separate SVN repositories and control contracts and interactions through a well-defined release process to/from common artifact (Maven-like) repository. For example, Nexus has capabilities of restricting which artifacts are available to which user and allow to control read/write.

Upvotes: 1

Related Questions