Using Subversion for managing Web service contracts

Question

Hi there,

I'm looking at using Subversion for managing WSDL and XSD artefacts, where I have a service catalogue of around 60 services. Does anyone know of any articles recommending best practice around this with regards to the granularity between tagging and versions of services.

With SVN, it appears that you can only tag from the trunk. If our trunk contains all our WSDLs then we would have to tag in a specific way in order to version each service. For example, if we had a service called AddressManager which was contained in the same trunk as CustomerManager, then in order to tag the trunk to represent a change on the AddressManager service, then the tag would have to be "AddressManager_v1.0.0". Which seems a little unwieldy.

Ideal what I'd like to get to is to be able to manage my service contracts using SVN and my tags to simply refer to the version number of the service (i.e. v1.0.0). But would this mean a trunk per service? Again, seems like a bit of an overhead.

This has to be a common issue for service contract (WSDL & XSD) management - can anyone share any anecdotes or advice on this?

Thanks,

Stuart

Answer 1

It depends how much development is done and how many users access the SVN. If there is heavy development than is good to create a trunk for each service (or for a bunch of service).

If you develop in one or two people than this is overhead.

When you develop a project than your project should be store in trunk. When you decide to release a version you create a branch for it. Into this branch you add only bug fixes (which are merged into trunk).

If you do most bugfixes you don't need to create branches. It's just enough to commit everything into trunk and for each release you remember revision number only.

Visualization of a very simple Subversion project: