Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Fri, 9 May 2003 09:56:20 -0400, "Samuel Neff" <srnlists at speakeasy.net> wrote: >Hello, > >Just setting up CVSNT for the first time. We've done testing with it and >are almost ready for real deployment. We had a few questions on best >practices and were hoping to receive some suggestions. > >We develop several different types of applications, primarily Macromedia >Flash and ColdFusion. I've used VSS and Star Team before for VB work but >never for web work and am a little confused about how to set it up. > >Web Development > >The issue is that all developers share one development server. Our initial >thoughts are to use CVS as our repository for ColdFusion files and set up >CVS to automatically copy files from the repo to the webroot on each >check-in. VSS called this shadowing, and I think I saw some utility for >CVSNT to do this. > >The problem one developer pointed out is that while developing CF apps we >will need to commit the files just to test them, not when we're done. This >will result in probably as many as a few dozen commits per day per developer >for each file they're working on. The history will grow large and it'll >make finding older versions difficult. > >There were two suggestions from our own group but nobody is really happy >with either. > >1. Use CVS only for managing the "authoritative" copy of the CFM files and >during the day while developing copy the files to the server using FTP or >RDS. We don't like this idea since we're now using two technologies to >transfer the same files to the same server and CVS becomes an additional >step with extra work, as opposed to an efficiency boost. > >2. Install development copy of the server software on everyone's local PC. >This is an option but has some logistical issues and we'd rather avoid it. > >Are there any other options we haven't thought of? All suggestions would be >welcome. As I understand it CVS was really created for open-source projects >where each developer does have the ability to run the files locally, so >maybe #2 is our only option. > >BTW, we're in a distributed environment where developers are in different >offices and everyone is in a different location from the servers--so no LAN >access. > >Cross Module Shadowing > >When looking at the option to have CVS copy files to the webroot upon commit >(sorry if anyone is offended by my use of the VSS term shadowing--I don't >know if there is an official CVS term), the issue arises that the Macromedia >Flash files are really a hybrid of resource/webroot files (i.e., some files >go in the module outside of webroot and a few--mostly just the swfs--go to >the webroot). Again, we'd like to avoid forcing people to make file copies >or movements outside of CVS. > >Can we set up CVS to copy certain files from one module to a shodowing >directory set up for another module? What about if the developer locally >copies the file from one module to another and then does a commit on the >target, will that cause problems for CVS? These are binary files if it >makes a difference. > >All suggestions, comments, corrections, whatever will be most welcome! > >Best regards, > >Sam As you point out the CVS system is best used when the developers can edit their files, compile and test locally until they are satisfied. Only then should they commit files. This makes for about one commit per developer per day or so. But if the need is for a commit just in order to test then it soon becomes unwieldy as you also realize yourself. I am doing some (but very little) web development and I have it set up in a different way: On my own machine I have a *checked out copy* of the entire website. This is then served by my own IIS on my own PC. Now I can edit my file as one may say 'on location' and immediately test my own edits. If I need see the other developers results too then I just do an update on my file set. Once I am satisfied with the results then I can commit my stuff and now it goes into the CVS server as fully working files. You should program the postcommit script file to do the "shadowing" out to the 'production' server so it will duplicate all committed files to this server automatically. Then the production server will only have code that has been deemed OK by the developer. In your scenario the production server would have all kinds of non-working and intermediate files from various developers sometimes (maybe often) not related to the work being done by a particular developer. This may well break major functionality and can cause bigtime time loss. It is much better that all developers know that whatever is causing the strange behaviour they see is due to their own coding.... Binary files Ooops! This may cause you some problems because binary files are not mergeable and so if two developers simultaneously edits such files then the work of one will be lost! Here you really need some kind of locking, which is not the stronghold of CVS. Search the archives for 'reserved edits' and you can read a lot about it. Not being on a LAN What do you mean by this? Surely your developers are connected? Otherwise using CVS seems rather futile. But I might have misunderstood you? /Bo (Bo Berglund, developer in Sweden)