views:

31

answers:

2

Is there a way in subversion to specify that a specific path is an alias for a different path, with the ability to update that alias as conditions change? Can I lock paths to prevent changes in them?

I'm working on a repository structure and what I'd like to do is have the following paths:

  • /versions/1.0 - Previous Release (Locked)
  • /versions/1.1 - Previous Release (Locked)
  • /versions/1.1.1 - Current Release (Unlocked for patch development)
  • /versions/1.1.2 - Next Minor Release (Unlocked for development)
  • /versions/1.2 - Next Major Release (Unlocked for development)
  • /patch - Alias for /versions/1.1.1, Checkins appear in both places
  • /subrelease - Alias for /versions/1.1.2, Checkins appear in both places
  • /trunk - Alias for /versions/1.2, Checkins appear in both places

The goal is to keep trunk moving to keep up with where most developers are working. After we release a couple times and 1.2 goes live, the structure would be:

  • /versions/1.0 - Previous Release (Locked)
  • /versions/1.1 - Previous Release (Locked)
  • /versions/1.1.1 - Previous Release (Locked)
  • /versions/1.1.2 - Previous Release (Locked)
  • /versions/1.2 - Current Release (Unlocked for patch development)
  • /versions/1.2.1 - Next Minor Release (Unlocked for development)
  • /versions/1.3 - Next Major Release (Unlocked for development)
  • /patch - Alias for /versions/1.2, Checkins appear in both places
  • /subrelease - Alias for /versions/1.2.1, Checkins appear in both places
  • /trunk - Alias for /versions/1.3, Checkins appear in both places

I know I could do this on my own machine, but mandating this in source control gives everyone a common set of verbiage to work with.

+1  A: 

There's no support for aliases, sorry. It is quick and easy to copy whole trees, however. You can either not create version/1.2 etc. and then just copy trunk to version/1.2 when the time comes, or instead just work in version/1.2. Alternatively you could manage both but use a process to copy commits between the two, e.g. once they had passed all the tests on your continuous integration server it copies commits from trunk to 1.2.

Locking: you can write a server-side commit hook to prevent commits to specific paths and add your paths there to lock them. There's no built-in support in either the server or default client however. Some clients e.g. TortoiseSVN will treat paths containing 'tags' as should-be-locked and warn you if you're going to commit to them, but that's purely client-side and client-specific.

Rup
+1  A: 

To the best of my knowledge, you can achieve something similar to this using the svn:externals property to make a folder act as an alias to another. If you never have to commit in two versions/branches at once, it should work.

Victor Nicollet
Actually yes, I forgot about that. I've had mixed experience with that but that's working with an external inside another checkout rather than taking the external from the whole checkout. I have seen internal links discussed a few times on the svn list too, but AFAIK they don't exist yet.
Rup