Hi, Preston: Preston Crawford wrote:
> On Tue, 15 Jan 2002 17:38:49 -0800, Chris Smith wrote: > > >>Depends on how you're planning on using CVS. [...] >> > > The way I plan on using it in the short term is for me to develop and to > keep track of my source so I can version, rollback, etc. I will be the > only developer. But we're bringing at least one person on shortly and Under these circumnstances it really doesn't matter how you do it: being the single developer it would just work the same *if* your transparently access to the remote machine... provided you didn't know in advance or look the output of some command how can you tell (cualitatively, it migth be a bit slower) if your developing space is local or remote? (more on this later) > maybe more in the future, so what I'm trying to do in part is get a feel > for how it's done in the Java world and the CVS world, by and large. First of all I would say that Chris has put you on the rigth track. On the long run the "each developer works on his own copy on his own box" will pay the most; the single box model is (on most cases, but not all of them) just crap due to misunderstunding things or misworking software. With this in mind, it is true that specially in the begining assuring each box is properly configured can pose a heavier load on the sysadmin side than if the only box which works properly (regarding your project) is only one central server. But you say you have just one developer, so you just have to take care of two boxes you already know well (server and yours), and future additions will be on a low pace so you will be able to cope with them. > Because, as I stated, the absence of something like FrontPage Server > Extensions seems to prevent the creation of an environment where there is > a centralized development server like this. The only way you could > seemingly do that with CVS would be to ssh into the server and CVS down. > And even in that situation it seems to me like you'd be talking multiple > instances or hosts on the web server. > As I told you I prefer by far the "each developer works on his own copy on his own box". Anyway it can be done the way you tell, at least if all developers are on the same LAN. On the other hand, the "centralized" approach only works well when all developers are on the same LAN too (while it *can* work... more or less even through the Internet). The point here is what I stated earlier: if you can find a way to function transparently: You configure your iPlanet so it publishes from, let's say /usr/local/htdocs/ProjectX, so you make it to be a sandbox from the ProjectX module from the CVS repo. Then your developers remote-mount /usr/local/htdocs/ProjectX as it locally fits (let's say D:\ local disk if they use some Win flavour using Samba to export it from the server or as /projects/ProjectX if using Un*x through NFS). They install and properly configure CVS for remote access (using pserver, rsh, ssh or whatever fits). Finally, they just launch their IDEs and that's all: They alter files and since they are working on a CVS sandbox any of them can remotely checkin the changes at leisure. That's all. Well that's not all. You soon will find why the "centralized" approach doesn't pay: as soon as two developers try to edit the same file, or as soon as the additions/modifications from one developer break the whole app (and I don't mean *by mistake*: if a change needs to expand more than a file it's most than probable that the app breaks as soon as the first file's changes to the time when the last file is fixed and saved). During this time frame is more than probably that the other members of the development team will have no option but to wait hand on hand till their mate ends his work. These are the most common problems. But on given time some of them will need to try something on his own, or you will want to try something that you don't know in advance if it will work or will end up on the main devel line, or just will span more than a few days and you will find you are, for instance, working on the next version of your app when one client needs some modification or bugfix on the currently in production. Then you will need to publish not only one version of your site but two/three/four (something like production.myapp.com, nextrelease.myapp.com willthiswork.myapp.com, or www.myapp.com:80 -for currently in production, www.myapp.com:8080 -next release, www.myapp.com:8081 that bugfix my client urgently needs...) But this, of course, are problems you already know for they already appear when using frontpage/VSS (well, that's why even frontpage server can be managed to work locally -for development, and then sync with a remote server... just to discover you have deleted the last change your mate did but you didn't noticed, so you didn't updated your local site with the changes). > >>You will, of course, want a separate system for integration testing on >>any project of reasonably large size. This would be separate from any >>of the developers' machines, and would be used for regression testing to >>be sure that multiple developers don't make changes that logically >>conflict (which is still quite possible with any source control system). >> >>Chris Smith >> > > Thanks for the advice. So how is it done out there, then? It sounds like > local development on a local web server, pitching your source up to a > central CVS repository is the way to go. I think in a way I might confuse Yep. > things by bringing up CVS, when the real issue has to do with distributed > web development in a world where a system like FrontPage (keeping aware > that there are MANY problems with FPSE obviouslY) Server Extensions, > Interdev and SourceSafe aren't as usable. > Distributed/cooperative development is one of the issues here, the other being parallel multiversion development. -- SALUD, Jes�s *** [EMAIL PROTECTED] *** _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
