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.
If I understand correctly you have something like the following structure:
svn:externals library svn://repo/library)svn:externals library svn://repo/library)svn:externals library svn://repo/library)svn:externals library svn://repo/library)svn:externals library svn://repo/library)I’m assuming you are settings
svn:externalson /project1/trunk to /library. If you then merge the revision with thesvn:externalsto /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:externalsto 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 ofsvn:externalslink in your release branch without worrying that the shared library code will ever be updated unless you manually change thesvn:externalsProbably 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:
svn:externals library svn://repo/library/tags/version3)svn:externals library svn://repo/library/tags/version1)svn:externals library svn://repo/library/tags/version2)svn:externals library svn://repo/library/tags/version2)svn:externals library svn://repo/library/tags/version1)