info-cvs
[Top][All Lists]
Advanced

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

Re: Multiple developers in one work area


From: Eric Siegerman
Subject: Re: Multiple developers in one work area
Date: Fri, 15 Dec 2000 15:04:11 -0500
User-agent: Mutt/1.2.5i

On Thu, Dec 14, 2000 at 03:46:15PM -0800, Parand T. Darugar wrote:
> We would like 
> to have those multiple developers access the
> same directory of source code, as opposed to each
> having their own working area.

It sounds as though you already understand that this is
completely counter to the way CVS wants to work, so I won't
belabour the point.

> The reason behind this
> is that everyone needs to use the same web server
> for testing, and hence the same working area.

Why must they use the same web server?  What we do is give
everyone their own WWW server and JRun instance, both tied to
their personal CVS sandbox (indeed, in our shop, the word
"sandbox" has come to signify not just the CVS working directory,
but that plus its associated server instances).

Besides going along with the CVS paradigm for its own sake, this
gets us the advantages that paradigm was designed for in the
first place:
  - concurrent editing
  - each developer can test their own work in isolation (since
    each has their own WWW server to test it on)

We intend to set up separate integration sandboxes, and institute
some procedures for using them, but that hasn't really happened
yet -- too busy developing :-/

I wrote a Perl script to check out a new CVS working directory,
create a new JRun instance, and tie them together; unfortunately,
the configuration for Netscape's WWW server is weird enough that
I didn't feel comfortable automating it, so that step is still
done manually.  With Apache, this part could almost certainly be
automated as well (note that it's better to give each user their
own Apache instance, not just a virtual server; that way they can
edit their Apache configuration, and start and stop their server,
without breaking other peoples' environments).

On the development machine, we divided the IP port space into
200-port blocks starting at 10000; each sandbox is allocated one
block of ports.  A few of the ports are predefined (with the
offsets being, hopefully, somewhat mnemonic):
        BASE+0  = JRun admin
        BASE+1  = Jrun JCP (ie. the servlet server)
        BASE+80 = HTTP server
        BASE+99 = Java RMI
but the rest are free for the developer to use however they like.
This has the fringe benefit of offloading port administration
from the sysadmin: if a programmer wants to run something that
works over IP -- a network-aware Java debugger, a networked game,
or whatever -- they don't have to bug the sysadmin for a free
port number.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Nobody ever got fired for buying Microsoft -- but they could get
fired for relying on Microsoft.
        - Chris Garrigues



reply via email to

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