CODEWITHSUNDEEP
svnlampsymlink
Ken
Ken

Reputation: 78852

Switching between trunk and branch with symbolic links

(This question earned me a tumbleweed badge on SuperUser but I was advised to try it here instead)

I'm working on a major branch on my LAMP development server, but I frequently need to make minor but urgent updates to trunk.

I am experimenting with serving my local site from a symbolic link (foo), which I can then rewrite to point at branch or trunk. This allows me to switch backwards and forwards without worrying about uncommitted changes, means that I can use the same bookmarks, path aliases, etc

# svn working copies for trunk and branch
/sites/footrunk/
/sites/foobranch/
/sites/foo -> foobranch  #symbolic link

# eg to switch to trunk
cd /sites;
ln -s footrunk foo_tmp && mv -fT foo_tmp foo
cd -; 
sudo service apache2 restart

My problem is that apache occasionally gets confused immediately after a switch, and seems to be holding onto empty, old or duplicate (cannot redeclare class error in php?) versions of files. Restarting apache seems to resolve everything, but there are warning bells going off in my head.

Is this a reasonable use of symbolic links, or am I just saving up problems for the future?

Upvotes: 3

Views: 613

Answers (1)

Emile
Emile

Reputation: 11721

I used symbolic links extensively to source common libraries. Shared libraries change, cool every project gets the latest code. I managed many projects in this way and it seemed perfectly reasonable.

That is until i realised there was a serious issue in the symbolically linked library. Fine, change the source code everyone benefits. 20 hudson builds later and and you start to think, ah yeah not such a good idea, what if a project 4 years ago, using the symbolic link, fails...

We remove dependencies in our code, why not our deployment environments...

Whole heartedly, no, using symbolic links isn't really a good idea in the long run and yes warning bells should be going off.

What are the alternatives?

Still using symbolic links i would branch the linked libraries for each unique project and reference those. This still meant linked libraries, and when your switching between branches and trunks that created a headache as well. It got to the point that i just completely removed symbolic links.

I now have two methods, the first is i create an eclipse library project for the library and reference that from my other project. The other is i either create a Jar or Swc(flash lib) and import those directly as a dependency in my project. If changes occur on the source for a project then i can either update the project or re-import the libraries built on hudson.

My scenarios don't use Appache, so i'm no help there but in general using symbolic links, especially in SVN should be kept well clear of project work.

Also, changes to symbolic links aren't i believe versioned. They're static and you can't track changes to them. (please correct me if i'm wrong on that point). They also don't travel or work between different repositories if i'm correct.

Edit 2

As per the comment, perhaps this might help, when i want to serve both trunk and branches of a project from apache i'll use apache alias's. Of course you might have uri issues, so it might not work, but its an alternative to try. This again totally depends on your setup (i'm guessing i'm missing something as to how sym links are working for you).

>touch /etc/apache2/other/emiles.conf
>pico /etc/apache2/other/emiles.conf

.. add the following.

Alias /fooBranch "/Users/emile/fooBranch"
Alias /fooTrunk "/Users/emile/fooTrunk"

<Directory "/Users/emile/fooBranch">
    Options +Indexes +MultiViews +FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>
#copy above with "/Users/emile/fooTrunk"

Restart appache, and then access both

http://localhost/fooBranch
or 
http://localhost/fooTrunk

You might even set up localhost to just reference fooTrunk, or perhaps use different ports, virtual hosts (which i'm not that familiar with).

Upvotes: 3

Related Questions