Thread

Hello guys, Im new to this version control system and I dont even know how to use it or where to start.

Why do I need to use one of this and any tutorials where I can learn how to use a specific version control system?

This isn’t a version control system - this is a PHP development framework (see the User Guide for more info). If you are looking for a version control system, I highly recommend Subversion.

After seeing you have 59 posts, maybe I have misunderstood your question. Are you asking why you should use a version control system?

There are a lot of great articles out there going into the benefits of using one - but here are a few directly relate to web development:
http://www.alistapart.com/articles/revisioncontrol
http://www.sitepoint.com/blogs/2004/03/29/version-control-and-web-development/
http://athleticsnyc.com/blog/entry/on-using-subversion-for-web-projects

Yes, thats why I posted this in the lounge section because its not related to CI.

I’ll go check your link and come back see what happens.

thnx!

If it’s just you developing then version control becomes a muddy issue. Essentially you should be able to make necessary milestones for backup in your code and have some sort of revision history - generally manually. However if there is more than one developer it is almost essential that there be a versioning tool to maintain and track changes.

My personal pref is subversion. I use it even on my single developer projects because it helps eliminate a lot of headaches of manually creating backups. Plus once you get used to the work flow it becomes second nature.

Subversion is great. I need to get it setup with textmate. I love textmate + transmit, but version control does come in handy now and then.

Everyone is reccomending Subversion but there isnt really much competition right? CVS is just a old feature-lacking version of the same system and as far as I know there isnt much else worth talking about.

Getting the right enviroment can be tough. I found the perfect workflow using EasyEclipsePHP and its built in SVN tools, but as with all Eclipse based stuff, if you are lucky enough to get it installed and running on Windows fine, it never lasts more than a week.

Now I have had to stoop to DW + TortoiseSVN + Subweaver… yay!  😏

Who has some good posts for SVN ethics? I have learnt how to do the basics, time to get 1337!

I dont know if you can or not but how would you go about setting up svn on your own computer or even to a seperate harddrive. I want to keep version history (whatever) of the code i write so i can restore/ release etc yet do not have a web host capable of letting me do this and a local svn setup would be preferable. I just cannot find out how to do this or any detailed instructions as to how.

btw, im on os X

On Windows you could just grab TortoiseSVN and wherever you want that repo to be, create a new folder. Right click -> TortoiseSVN -> Create Repositry here.

Anyone know a good SVN client for Mac OS X?

One thing I have had an issue with…

How do you make your repository a live server?

I have tried the following in the past - placing my repository within my htdocs folder on localhost, then working on my application from another folder. But, committing my changes and viewing localhost just allows me to browse the files like a normal SVN repository.

What I would like to do is: work on my application from one directory, have my repository in another directory, and somehow automatically push those files committed to the repository, to a live web server that will act as a real web server (and not an SVN repo).

Any ideas?

Walesmd i cannot see that being possible at all due to the nature of svn, it would have to ftp everything after every change, not only is this not the role of svn but isnt very practical. The easiest way i can imagine is if the files are being svned to that server or another server, if you have ssh command line access, if you just import it to the new folder. Svn generates .svn folders and alot of other code during the process for tracking purposes so it would have to been done like any other svn checkout from the server (unless you ftp from ur computer)

One thing I have had an issue with…

How do you make your repository a live server?

I have tried the following in the past - placing my repository within my htdocs folder on localhost, then working on my application from another folder. But, committing my changes and viewing localhost just allows me to browse the files like a normal SVN repository.

What I would like to do is: work on my application from one directory, have my repository in another directory, and somehow automatically push those files committed to the repository, to a live web server that will act as a real web server (and not an SVN repo).

Any ideas?

English is not my native language, so excuse my errors below :-| .

  Well, one possibility is that you can use ‘svn export’ inside a freshly checked out folder to export a clean tree (without .svn subfolders in it), then synchronize the remote live web server with the clean tree. Update: You can automate this using commit hooks (just google it, there are many articles on this topic), but I have not done this before personally, since I think it is better to have more manual control over pushing changes to a live web server, with real users (not developers/testers ones, which can tolerate some temporary bugs and misconfigurations).

  Another possibility is to keep a checkout tree on the web server itself, outside the htdocs folder. Then, when you commit some changes, go to the web server, do a ‘cd SVNCHECKOUTED_HTDOCS’ , then ‘svn update’,  followed by ‘svn export . LOCATION_OF_HTDOCS’.
In this way, the tree inside HTDOCS will be free from the .svn folders .

  You can also try using git in combination with subversion, or even instead 😉 of subversion. This is the best solution in my opinion for the following reasons.
  The advantage with git is that it does not clutter your tree with .svn folders, so there is no need for ‘svn export’ hacks when you decide to push some changes from development and then to production environments.
Also, git is distributed and branching is very cheap, so you can work on several bug fixes/enhancements without worrying about merging at all. Last, but not in importance - git is VEEERY FAST for the most common operations like log, commit, checkout (svn revert), so playing with branches is easy and your edit/test/commit cycle will be greatly accelerated, which is always a good thing 😊 .

  Our current setup for most of our projects is this:
1) root repository (RR) - it serves as a central location for synchronization between the different branches/developers.
2) dev machine 1 (DM1) -> this machine have several branches on it, use ‘git branch’ and ‘git checkout’ to switch between branches.
3) dev machine 2 (DM2) -> the same as above, but for a different developer, so generally has different branches.
4) test machine 1 (TM1) -> Changes are tested here, serves as a stage environment to iron out bugs missed during development. If you want and have automated test scripts, you can setup a continuous integration very easy with some shell scripts.
5) production machine (PM) - this is a live environment, so changes here should be done *after* full tests. The only commands that will run here are ‘git pull’ - to retrieve the current head version from the RR,  and eventually ’ git checkout HEAD^ ’ -> when you want to revert to a previous version, if you really have to.

note that 1) 4) and 5) were all on different machines, but now 1) and 4) are on the same machine, while 5) is on a separate one.

  So a typical development/bug fixing happens like this:
1) change something on DM1 or DM2
2) on DM1 run ‘git add -u’ to automatically track the changes, if they were in a version controlled file, ‘git add FileName’ otherwise.
3) on DM1 run ‘git commit -m “Commit message describing change.”  ’  . Now the changes are stored in your local repository, you can run diff, checkout, log, blame and so on without problems.
4) repeat steps from 1) to 3) as many times as are required.
5) Push the changes to the common repository RR, by ‘git push’. Now the changes are in the common remote repository, and anyone can sync with them.
6) On the TM1, run ‘git pull’. Now the changes are on the test machine, so you can test them extensively. If you notice a bug, fix it on one of the DM machines, and go through the steps 1 to 6 again.
7) When you are sure that everything is OK, you can run ‘git pull’ on the PM too. In case you have to revert, run ‘git checkout HEAD^’ to go back to the previous version, ‘git checkout HEAD^^’ for the version just before the previous and so on.

git can use ssh, git+ssh, http, https for transport methods (we prefer ssh setup with RSA keys cached in an SSH agent, so we do not have to enter password except when starting our work day). Since SSH encrypts everything, it can be very secure.

I hope that the above will help you.

An offtopic question - how do you make new paragraphs using this forum system ?

I tried to make the above (and this post too) clear, but it seems that multiple lines get stripped.

Your posts look clear to me…

Thanks for the info guys, I’ll have to do some looking into SVN even more - I’ve only ever used it for the very basic.

Delian has a great suggestion with how version control works - I can give a view of how I just setup our environment at work. We work with both php and *gasp* .net sites. We also have multiple types of databases (sql server, mysql, postgres). Originally (before I got there), development was done on all sites in a single shared folder from someone’s desktop (horridly not backed up either)... Ironically a week before I showed up the previous team suddenly quit without warning. So I had the fortunate opportunity to bring in my own set of fresh faces to revamp this company’s web and IT dept.

So with the limited budget I had to play with we built some boxes for our in house dev environment. Because the method was to work on the live site and ftp after every change - which is terribly expensive in time. So after getting servers setup to handle all the client aspects and management. We built a box to house the code base - both of live sites, dev sites, and big idea code we’ve been working on… set it up as a shared drive on the network.

Then commissioned 3 separate boxes to handle the server layer of our sites - one uses windows 2k3 server with IIS6 (obviously for our .net sites). Second one is using FC6 (I like fedora for some reason) apache 2, with RoR, Perl, Python, and PHP running. the third is houses our database engines. With some fancy dns work we have it setup so that you can go to a domain through your browser and see directly to the mounted drive - based on it’s server needs we have the internal DNS controller setup with private cname records pointing to either the linux or the windows boxes.

Our workflow uses the following process:
* Dev => only developers internally can see this based on our vlan
* Stage => everyone in our company can see this - plus we’ve setup a way for our clients to hit it through a custom url which then points to our network.
* Production => this is the live server at the data center

We use a combination of sFTP and rsync to promote code to the production environments (all depends our our clients). Currently I’m working on a python interface that will promote between dev and staging - however at the moment this is all done by hand.

When it comes to subversion we use svn (TortoiseSVN since we dev from windows boxes) to manage the code within the dev environment. Then we do batch exports from the repo to staging as the need dictates. I myself use a combination of PHPEclipse (love it), UltraEdit and SCiTE to edit files. One of our other developers uses only UE and our third uses Dreamweaver. So we’ve found this setup to be pretty robust to handle just about any crazy configuration we may have.

Let me know if I was confusing on this and I’ll try to clear up some points.