[CentOS] how to work with Code Repositories, but for web development?

[Les Mikesell]

Rudi Ahlers wrote:
>
> I would like some suggestion on this matter please. I have never 
> bothered using any code repositories / version control systems for our 
> web development project, many cause I didn't know any better, and 
> probably cause most of our projects don't really require that we need to 
> keep a history of what has changed. i.e. a client wants to change 
> something on their website, and we change it, whether it's cosmetics or 
> code (normally PHP & MySQL).
> 
> But, I want to see if CVS, or maybe even a forge script (like in 
> offerforge) could benefit met. Most of the time when we make changes to 
> the code, we simply update the version, from say 1.2.2 to 1.2.3 and 
> write the changes to a basic changelog, which in our case is a simple 
> text file calles changelog.txt
> 
> But, how could I benefit from a CVS, ir similar system? And what would 
> be best for this environment? I installed CVS on my CentOS server, but 
> it seems that it's not just a matter of creating a tree and dumping 
> code.  I'm not too worried about multiple users at this stage. All our 
> coding is currently stored on a CentOS 5.4 Samba server, so we can 
> access to the code from either a Windows or Linux PC. Do I need anything 
> more?

I'd use subversion rather than cvs, but the concepts are mostly similar.  Create 
a repository, import your existing file tree (or several if you want to break it 
into projects at directory levels.  Then check out a working copy somewhere 
else.  Once you are sure that works, delete (or move) your original copy and 
check out a working copy in its place (this might be your actual web server tree 
or a staging copy that you rsync to the real server(s).  From then on, you 
always edit in working copies and commit the changes back to the repository. 
Many working copies can be checked out at once, and an 'update' command will 
bring them up to the current repository version so it is easy for many people to 
share work.  You can use subversion's own server protocol or the mod_dav_svn 
module for apache for access over http(s).

> I started using eclipse+PHP a few months ago and I don't really use it 
> to its full potential, so I'm sure I could benefit from it more.

With eclipse, you can use the subclipse module for GUI access to the subversion 
features.  If you work from windows the tortisesvn program adds it to windows 
explorer.

> So, the question is, what is a good recommended setup to go with? Web 
> based access to all the files would be nice, then we could access it 
> from outside the LAN on HTTPS.
> And how do I use it to my benefit? For example, clientA wants to make 
> changes to Project1. Now I have a Project1 in the CVS tree (is this the 
> right terminology?), and make changes to file contacts.php - what now? 
> Do I need to create a subfolder called 1.2.2 (for example), and add only 
> the updated file in this folder, or do I copy the whole Project into the 
> new folder?

You can control access by path - or have separate repositories per client/site. 
   Normally everyone just commits work to the repository as they go, then when 
the changes are ready you update the site to that revision - perhaps through a 
staging/test process.

> 2 weeks down the line I need to make changes to 8 files, what do I do now?

Edit in a working copy, commit, update in the master copy.

> Does this make sense? I realize it could be beneficial to keep older 
> files, but how does one structure it?

History is kept automatically.  Every commit makes a revision number and you can 
  check out (or update to) any revision ever committed.  If you want to make big 
changes and be able to edit different versions simultaneously you can make 
branch copies.  If you want what appear to be snapshot copies with your own 
naming convention you can make tag copies.  This is all covered pretty well in 
the subversion documentation and the only thing that takes any thought is how 
the repository relates to the active site.  You might be able to make the live 
files a working copy and manage it directly with updates to current or a 
specified revision number.  Or you may want to do that in a staging area, 
perhaps with a way to preview the changes, then use rsync (which has a -C option 
to skip CVS or subversion metadata) to push to the production location(s).

-- 
   Les Mikesell
    lesmikesell at gmail.com