[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please help me arrange my development environment

From: Jesus Manuel NAVARRO LOPEZ
Subject: Re: Please help me arrange my development environment
Date: Wed, 16 Jan 2002 18:13:07 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20010901

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,, or -for currently in production, -next release, 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


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]