Re: Please help me arrange my development environment

[Jesus Manuel NAVARRO LOPEZ]

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
***
address@hidden
***