Involvement in developments from other teams within a project usually require that the (production) repository is hosted somewhere centrally. This give us the advantage of having one code-base where all developers to work. The main disadvantage of this implementation though is that usually developers doesn't commit till they have something really stable and working.
Another disadvantage is that it is not clear to someone outside your mind to find out on what you are working on (and usually "manager" guys need to do so).
I was proposed to use a local repository for every developing i do where it would be easy to have "every change" commits and commit stable versions to the central repositories. This will give us both frequent commits (thus clear history view) and other are able to see on what you are working and probably comment on this work. At first i was highly against this... It's clear that it adds a lot of additional work without giving us many clear advantages.
As this was a "manager's" proposition i had to try it. The initial thought was to work on our local repository and then, when i have something stable, take a diff since last sync of the repositories to apply it to the remote (central repository).
But ... thinking on this again, is it the "svn tagging" procedure having different server for trunk and tags?
An implementation to test:
- Creation of a local test repository with trunk and tag trees
- Create a new repository to serve as "the remote central repository"
- Create a new tag at the first repository which will have an svn:external link to "the remote central repository"
- Start tagging as normal on the local test repository but always at the same tag.