SVN: Release branch and externals?

Question

We have two websites for the same client (main www site and another for the ecommerce site which sits on a seperate server) that use shared portion of code (various features/styles/javascript etc.). We currently manage this by having the shared code as seperate projects (in the same repos) in SVN and using svn:externals to pull the branch of each of these into the two website projects.

We have just created two release branches, one each for the two sites. Everything gets commited to trunk for each of the sites as normal when working and when "ready for live" we merge it into the release branch for that site. Works a treat except today we modified the some of the shared code and noticed that the release branch pulled it in straight away when we did an update on the release branch. This is not what we wanted :(

So any ideas how we can iron out this problem. We used externals to DRY up the sharing of the code but is there another way? Notice that in this question (How can I branch in SVN and have it branch my svn:external folders as well?) they mention externals are bad and we should be using a different build process but no mention of what that should be.

We have CruiseControl.net running our builds and are keen to get this nut cracked. Has anyone any ideas on a better process?

Cheers

Pete

UPDATE: We've since moved to using Mercurial (Fogcreek's Kiln) for our source control. Mercurial also has the idea of sub-repos so we followed that route with our project there too. However it comes at a cost, branching is made really difficult as is tagging and simply keeping everything up to date. Our latest method is to bring both projects into one repos including all the shared repos too. This gives us one "mega project" which slows clone time (check out in SVN) but we do that so rarely that the gains of not having to deal with sub-repos makes it well worth while. We now use feature switching/toggling rather than branching which also simplifies our development greatly.

Answer 1

If I understand correctly you have something like the following structure:

• project1
  • trunk
    • library (via svn:externals library svn://repo/library)
  • branches
    • release1
      • library (via svn:externals library svn://repo/library)
    • release2
      • library (via svn:externals library svn://repo/library)
• project2
  • trunk
    • library (via svn:externals library svn://repo/library)
  • branches
    • release1
      • library (via svn:externals library svn://repo/library)
• library

I'm assuming you are settings svn:externals on /project1/trunk to /library. If you then merge the revision with the svn:externals to /project1/branches/release1 and update that branch, you will automatically get the latest version from the library. By default svn:externals will get the HEAD revision of the link.

You could define the svn:externals to link to a specific revision, like this: svn:externals -r123 library svn://repo/library. This means that the externals link will always point to that specific revision. So you can safely use this type of svn:externals link in your release branch without worrying that the shared library code will ever be updated unless you manually change the svn:externals

Probably a better way would be to use tags for the shared library and link to a specific tag. In this case you would get the following repository structure:

• project1
  • trunk
    • library (via svn:externals library svn://repo/library/tags/version3)
  • branches
    • release1
      • library (via svn:externals library svn://repo/library/tags/version1)
    • release2
      • library (via svn:externals library svn://repo/library/tags/version2)
• project2
  • trunk
    • library (via svn:externals library svn://repo/library/tags/version2)
  • branches
    • release1
      • library (via svn:externals library svn://repo/library/tags/version1)
• library
  • tags
    • version1
    • version2
    • version3

Answer 2

Otherside has some good advice, but it really is using svn:externals as a poor man's dependency management system. It is making a hacky anti-pattern somewhat workable for the disciplined.

You're absolutely correct that that svn:externals is not the path.

One thing more to think of, if you stay on that path - unless your svn tags are atomic (via a pre-commit hook), you'll want to specify the revision as well as the tag.

I'm currently suffering shell shock at having inherited some .NET stuff, makes me miss maven so much. I'd even settle for a mess of ant/ivy.

You may want to check out https://www.nuget.org/

Answer 3

You can do svn update --ignore-externals if you don’t want the externals to be updated.