Janet's progress last night with svn

I spent the first 20mins setting up the team’s username/pword and repository access through the command line. I’ll email everyone about that today so they can get on there (if they know how to use svn)

The next 2.5hours was taken up by setting up and testing the repository.

Firstly, I needed to copy over the public_html files/folders to strinerepos. I did this in the command line, in the main strine directory folder by typing:
svn import public_html http://svn.strine.net.au/strinerepos/webdocs --username jto –m “initial file import”

So what that means is:
svn = indicates it’s a subversion command

Import = what you want to do

public_html = the source of the data to action

http://svn.strine.net.au/strinerepos/webdocs = where to move it to. We have to dot he http as it goes out through the Apache server. Webdocs is the name of a folder to put all of the data in, so they aren’t just floating around in the root repos folder. I could have called it strine, but was getting lost amongst all of the strine references…this is where implementing some sort of folder/file naming convention would be awesome (but probably more important if we were creating the site files instead of using existing ones)

--username jto = this is to log me in as the user executing this action. It asked me for my password after I pressed enter to execute

- m “initial file import” = every action in subversion asks for a comment to be attached i.e. for you to explain the change you are committing. This is just a way to use the command line to do this, so in the svn register, this process will be logged and time stamped and you will be able to see what was done at this time.

So, everything copied over relatively painlessly – including the cache files, which were not needed! The cache files are just temporary versions of the site files including the template files. I’ve worked out they tend to be responsible for mucking up the code changes. I took a moment to clear them out of the repository.

Next, I used the bookmark I’d set up in RapidSVN to hook into the strine server and CHECK OUT all of the repository files to my local server. Don’t export the files at this point – that’s just like downloading them over ftp. By checking them out, the svn files remain linked and changes can be tracked.

So, I had to move all of my old pligg files away and start fresh with these linked files, to let svn track changes, which I downloaded to the same named folder as the old files had been in (hoping this would minimise the problems that came up in the code). By retaining the old files I’d worked on, I can go back and copy over the code changes I’d made easily into the svn tracked files. (If you’re confused, don’t worry. I feel like I’m bending my brain to track how this works, so I’m probably not explaining it clearly!). I noticed that the imported files were 18.3MB compared to 7.4MB in the original Pligg files – when I executed that shell script from a few weeks back, I could see that there was an invisible .svn file in all of the folders I’d downloaded – this is apparently where all of the changes were tracked and the old files kept for diff comparisons, so when you want to do that, you don’t need to check in with the server all the time!

After transferring the files across, I tried loading the local version in a browser window, but got an error re the strinemim_table not existing. I realised I had named my local database tables with the prefix pligg_ where as online I named them strinemim_, so after a bit of investigating I worked out a way to rename all of my tables in MySQLAdmin using the SQL command :
RENAME TABLE one TO two;
where ‘one’ and ‘two’ were the different table names.

This didn’t solve the problem so I googled the error and fixed it as per my post last night.
I have created a back up version of the settings.php and dbconnect.php files online in a separate folder on the segpub server

What this means in terms of using SVN and pligg for the Strine build:
I have removed the settings.php and dbconnect.php files from the repository, as these will always be local specific (as they deal with the database references, passwords and local URLs etc). You can have files in the same folder as your svn files that won’t be detected by svn unless they were downloaded that way.

When I help the team load the svn version of the files to their computer, I will need to back up their local versions of these files, install the checked out version of the files onto their server and then replace the backed up files in their rightful place. After that, it should be quiet simple for us all, as svn will track the rest of the files that we might need, and if someone does a full check in, they won’t accidentally erase anything.

When it comes to updating the live files, I will export the repository files, not check out, as there’s no need for the excess svn files, and all changes will be made in the repository, not the other way around.

I was hoping to find a way to automate the export update from the repository to the live site, but it looks like we will have to stick with a manual process, as we will have to also reinsert the settings.php and dbaccess.php files for he site to function, but it’s probably a good thing. While we’re still working out how to use this, it’s probably safer to supervise the updates in case a back track is necessary if it all falls apart. This should hopefully make for a smoother online experience for users.