Tom Glover - 11 September 2008 05:04 PM

Tortoise SVN is the only good option for Windows.

I know this is months later, however I waned to say that I disagree, I find that RapidSVN works much better when dealing with network and remote repositories than Tortoise; it is free also, so anyone having problems with Tortoise (like I did) they should give RapidSVN a shot.

SVN pops up more and more and is clearly the “now” way to develop software. Understanding this, anyone with more information on symlinks etc should post it here as SVN takes a while to get your head around.  I’m just learning it now and downloaded the latest version in the trunk.

If by the time I learn enough to pass on my learnings, I’ll do so - in the meantime this is certainly a big topic that’ll only grow moving on.

Hi Derek,

I saw some problems in this approach like other members have noticed with the externals stuff, so I decided that I was going to try your very good idea but avoiding this problems, and this is what I finally did:

I created a public directory and I put all the symbolic links there. I put a copy of the index.php with the configuration pointing to the app directory outside of the “ci” codeigniter folder.

public/
——————————————-
.htaccess -> ../site-extras/.htaccess
images -> ../site-extras/images/
index.php
js -> ../site-extras/js/
system -> ../ci/system/

and I have the external at the root of the project, like this:

ci http://dev.ellislab.com/svn/CodeIgniter/tags/v1.7.1

Then I have all the advantages of your approach but without having to deal with the svn:externals problems that I found in it.

Thank you for your good idea.

I’ve changed my basic CI layout after a year of hosting several CI web applications on Ubuntu/AWS:

Changes from last year’s post:

* The public`folder is no longer svn:extern’d to CI, instead it’s symlinked to the lib folder that’s externally linked.  This fixes a Subversion annoyance where `svn up` reported a circular reference.
* The lib folder can contain other libraries like Markdown, ExpressionEngine, jQuery, and so on (all of which you can link using svn:extern)
* index.php is modified by the configure script to reference the root level `application` folder (instead of symlinking)
* the `configure` script is renamed to a more standard name, and it does the symlinking, permissions work, and vhost setup (if needed)

This approach is not workable on Windows (lacking symlinks), but it works well on all *nix hosts including OS X.

Note that the `svn:extern` + scripted approach (including decoupling CI) makes it easy to patch a server quickly.  This is a serious, and important security principle.  It also makes it easy to upgrade portions of the application by themselves without much thought.  We can bring our servers up in < 3 minutes (including reboot) after a fatal issue using this method.  It’s super duper.

I only scratch my head and wonder why when I look at other setups posted…

here is my setup, it’s simple, easy to maintain, a tiny bit more secure and… just plain easy…

/usr/share/php/mylib/CI/system <~ CI system folder (owned by root)

/var/www/mysite/application/        <~ CI application set above public level for security
/var/www/mysite/public_html/        <~ set this as DocumentRoot in Apache vhost.conf file
              (css,js,images,themes,etc)
              index.php
              .htaccess

edit index.php thusly…

no symlinks and no *nix magic required….

you can set CI to update through SVN or copy/replace of the system folder, you can host multiple CI websites from one CI system folder, etc and not turn your site directory into one big CF looking mess.

If for some reason you have to leave the CI system at a lower version simply copy the old version to /usr/share/php/mylib/CI1x/ and edit the index.php file, which would allow you to host multiple versions of multiple CI apps relatively easily, or name the newest version to that version, etc.

I edited my application/config/config.php file so that I can change one variable and the entire thing is configured for production or testing -  though the file is a bit bigger than original.

Finally this allows me to ensure that no one else can modify the CI system without my knowledge and it also prevents me and others from editing the Core files during development.

brianw1975 - 17 September 2009 11:02 PM

...

no symlinks and no *nix magic required….

...

We use symlinks (and svn:externals) on our production servers for a few reasons, namely that the various linking methods can:

* refer to other mounts (performance)
* refer to other physical hardware, like NAS (performance, scalability)
* include other web roots or projects (integration)
* pull in other subversion repos (orthogonality between libraries, and multiple libraries)
* allow rebuilding a complex web app (with any mix of the above) quickly

Most of our web services include several libraries like CI spliced into one web root, which all need to be kept up to date, and separate where possible.

It doesn’t make sense for Windows web developers, or smaller scale projects, but it’s something that makes scaling to millions of users (dozens of machines) and other larger capacity problems simpler.

I agree that the application folder + mods to index.php make the most sense.  Our setups have it scripted, but any method works.

I’m trying out something similar/different

project/          —> svn top-level dir
  /app             —> physically copied from ci/system/application; checked in
  /lib               —> to hold multiple libraries
      /ci             —> svn:external of CI svn repository at tags/1.7.2
  /web             —> DocumentRoot points here; contains index.php

Whenever I want, I can propedit and change the svn:external to 1.7.3 or whatever, this protects me from bleeding edge problems.

Copying app gets around application sync problems.  lib/ci/system/application continues to exist and gets ignored.  If future ci updates actually change around the application folder structure, I’ll diff and review it then.  web merely contains index.php, and whatever else I eventually add in.

This seems to be the simplest way to structure it to me.  Easy to type, too.

I am setting up svn to work on an existing project. I’ve never used svn before and have no desire to make mistakes.

I realize that the config folder is an example of files that would be different on my dev server and the live server.

Tortoise allows you to ignore files/ folders from what I have read, but no idea how to do this.

So my question, is how do I set up ignore rules, where do I put them so that my config folder never gets checked out.

I beleive checkout is the right word to use.

Thanks.

megabyte - 11 February 2010 01:53 AM

So my question, is how do I set up ignore rules, where do I put them so that my config folder never gets checked out.

We do it like this. Rename the config.php and database.php to config.default.php and database.default.php. Then commit those. Now whenever someone checks out a project, you have no danger of overwriting their config.php or database.php. This way you can safely do an export to a live machine without having to fear that you overwrite any local settings.

You can do the same for the index.php so you have error messages turned ON when developing, and turned OFF on your live server.

if you rename the config.php and the database.php file though, how will your local know what to use? won’t it be looking for config.php and database.php still?

I’m sure I’m missing a step or understanding a small part.

I honestly never could wrap my head around how this article was saying to set everything up and use Subversion.

It wasn’t until I read a Wordpress article about doing a Clean Subversion Install that it finally clicked. Here’s basically what I came up with.

I should mention, I made absolutely NO MODIFICATIONS to the index.php file.

My own article on the subject

Derek Allard - 15 August 2008 01:02 PM

the people attracted to CodeIgniter are among the smartest, most talented and down-to-earth developers around today.

You are absolutely right! Even though I’m new here but I have had help from the many posts on CodeIgniter.

Here is a small blog entry on this:
http://tudip.blogspot.in/2012/04/ci-with-svn.html