PHP/HTML Development And Version Control? 10
MadWhtHatter asks: "I work for a Web development company that is looking for a way to version control Web content, both PHP and HTML. I have been unable to find anything that meets my needs, which are: minimal developer retraining, security, it should be able to handle HTML and PHP pages. Unfortunately, most version control systems are designed to work with C++ code, and cannot deal with potentially live Web based code. They also severely impair the developer's ability to work with their favorite tools (Dreamweaver, Editplus). Any suggestions?"
Re:Untrue (Score:1)
I wouldn't mind finding something like that myself :-).
Professional Content Management Systems (CMS) (Score:1)
Probably the most popular are TeamSite [interwoven.com] and Documentum [documentum.com], but there are also contenders such as LiveLink [opentext.com] and NetPerceptions [netperceptions.com].
My own personal opinion leans towards TeamSite, but because I've heard good things about rather than trying it myself.
Re:Professional Content Management Systems (CMS) (Score:1)
CVS and CMS systems are functionally the same -- however, the big win with CMS systems is in the user interface rather than in the technology.
HTML designers use Macs. They don't want to figure out what 'cvs co mozilla-seamonkey -r 1414143221' means. If you give them a nice user interface, they won't complain about it and tie up the engineers all the time.
I make assumptions all the time about people's comfort level with command line systems. Usually I find out I need to do lots and lots of hand holding, to the point where I am officially support and spend my time looking at line options and environment variables.
Re:Untrue (Score:2)
I do have a little bit of an idea tho. I realize that most web developers prolly don't want to learn Unix or CVS if at all possible, but realistically that combo is the only viable option. With that in mind, you should explore ways to make CVS easy and convenient to use. There are a few good, intuitive GUIs for CVS available (LinCVS [freshmeat.net], more on freshmeat). Setup a combo CVS/X/file server and allow people to run the graphical CVS interface over X (there is a free X server for both PC and Mac called TNTlite, check yahoo) to check out HTML into their home directory. Then share the home directory via Samba (or Netatalk, if you're a Mac shop). Voila - people can checkout files over the network, edit them on the server w/filesharing, save the changes, and check them back in. It's kind of a roundabout way of doing things, but it works.
--
Untrue (Score:3)
I do believe that quite a few commerical versioning packages may be designed for C++, but the plain vanilla Revision Control System (RCS) will work with basically any text file. Using RCS, to built on top of it, CVS, works very well for HTML and is quite common. I have seen $Id$ tags on very many web pages. I don't understand what you mean by "web based code" - if you mean stuff that resides on another server, then that is the least of your worries. CVS handles distributed projects like a champ - like every major software package available for Linux right now, pretty much. I would go with CVS.
--
Using CVS (Score:3)
I agree with RG Ristroph's post -- the hard part is establishing version control -- the tool is not the most important part. That said, CVS is a pretty good tool. It works well over both LANs and WANs (unlike sourcesafe, for example), handles branching/merging about as well any as tool can, and bonus, is free. You *will* need someone who is dedicated to managing the system and answering questions. It may not (should not) be a full-time job, but until people are up-to-speed, they will make mistakes, and you need someone whose priority it is to fix those mistakes, and help the other developers learn how to accomplish what they need. (The above is true of any version control system, by the way, not just CVS.)
Before you install any VC system, you need to decide what you're trying to accomplish, and design the procedures to do that. CVS (or whatever) is a tool, not a methodology.
Finally, here are some hopefully useful links:
Ask Philip Greenspun..... Again (Score:1)
CVS ? (Score:1)
Re:CVS ? (Score:5)
As for frontends to it, there exist a number of them. The cvs homepage has a list. I use pcl-cvs, an X/Emacs package, and also the command line.
I don't understand what you mean by " deal with potentially live Web based code" and "impair the developer's ability to work with their favorite tools (Dreamweaver, Editplus)." It seems that by "live Web based code" you seem to think that a web site will be running right out of the repository, or something. You should have a repository to keep track of versions, and you can check out a particular version from that. Normally, you should check out a copy to a "development server" where you edit and test and debug. The world cannot see or access this, or if they can, it is not the main one on your company's site. Then you check your modified code back into the repository on a special tag or branch. Others check it out to their development servers and validate your work, maybe merging with their own, and you update your copy to get and examine their changes. At somepoint every one agrees that it is stable, and then you do a single checkout to the "production server", the live site.
So CVS should not have to be integrated with Dreamweaver or Editplus or whatever else GUI nonsense you are crippling yourself with. (Hint: emacs has a variety of html editing modes. Try them out and use one. Plain old Fundamental mode works great too.)
You mention developer retraining. In about a page you can list the basic commands which will allow each developer to check things in and out, veiw differences (even in ediff, if you use pcl-cvs) and mark versions. Teaching the use of CVS is simple.
( I have a simple little text file how-to that I wrote for members of my team when we first started -- it tells how to set things up and check out your first copy and etc. Email me if you want it.)
But the real problem is not the training associated with CVS at all; the commands are pretty simple and book (the one by Pers Cederqvist that comes with the distribution as a postscript file) is great. The problem is training developers to use configuration management at all. You have to talk with all of them and develop a plan of how to label branches, a naming scheme, etc. Many of them will check out one copy and hack for weeks and then feel frustrated and betrayed because the version has evolved so far that everything is impossible to merge.
You are going to have those problems no matter what management system you use.
My advice is to set up and use CVS, and focus on building a culture of development under configuration management among your co-workers. If you have to switch from CVS to something else it won't be that big a deal; getting people to use configuration management at all is the big step.
Re:Professional Content Management Systems (CMS) (Score:1)
Zachary Smith of Rare Medium did a comprehensive review of document-management options for several clients and stressed that no one solution merits an A+. Of the available products, TeamSite generally got highest marks because it played well with other software.
In another presentation given by an engineer from TeamSite, I asked if there were any difference between managing source code and managing Web files. He said essentially no, but that sometimes designers and other non-programmer type balk at checking files in and out and learning the tools.
I say go with with CVS.