info-cvs
[Top][All Lists]
Advanced

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

Re: version control with shared workplace


From: Eric Siegerman
Subject: Re: version control with shared workplace
Date: Thu, 8 Feb 2001 17:15:34 -0500
User-agent: Mutt/1.2.5i

Here's what I wrote a couple of months ago (with a few small
revisions) in response to a similar question.  I guess it's a FAQ
(hint to that person who's compiling one).

On Thu, Feb 08, 2001 at 03:57:14PM +0100, kozma peter wrote:
> I would like to set up a version control system for a website with lot of
> server side scripting.  Because of the server side scripts it is
> inevitable that the developers use a shared working place, namely the
> document root of the webserver (otherwise they cannot check the effects
> of their changes immediately).

What we do is give everyone their own WWW server and JRun
instance (JRun being a Java servlet server), 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 which 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 can be automated as well,
as my colleague has done (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, start and stop their
server, etc., 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

A couple of things my colleague did differently:
  - He assigned port blocks based on "your phone extension * 100"
    (he was using 100-port blocks) -- but this may not make sense
    in every situation.
  - He used BASE+0 for the HTTP server.  This makes a lot of
    sense, and I plan to use it from now on -- of all those
    preassigned ports, this is the only one you tend to type a
    lot; the rest go into a config file or two and are then
    forgotten.

The rest of the ports in the block 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
|  |  /
Interviewer: You've been looking at the stars all your life:
Is there anything in astrology?
Arthur C. Clarke: It's utter nonsense.  But I'm a Sagittarius,
so I'm naturally skeptical.



reply via email to

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