info-cvs
[Top][All Lists]
Advanced

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

(no subject)


From: root
Subject: (no subject)
Date: Mon, 13 Aug 2001 05:12:12 -0400

>From address@hidden  Fri Feb  9 07:20:45 2001
>Return-Path: <address@hidden>
Received: from fencepost.gnu.org (address@hidden [199.232.76.164])
        by gateway.camelot.jp (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id 
HAA18655
        for <address@hidden>; Fri, 9 Feb 2001 07:20:44 +0900
Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org)
        by fencepost.gnu.org with esmtp (Exim 3.16 #1 (Debian))
        id 14QzOB-0004eF-00; Thu, 08 Feb 2001 17:18:07 -0500
Received: from telepres.com ([209.226.75.17] helo=mail.telepres.com)
        by fencepost.gnu.org with esmtp (Exim 3.16 #1 (Debian))
        id 14QzLj-0004d9-00
        for <address@hidden>; Thu, 08 Feb 2001 17:15:35 -0500
Received: from localhost 
        by mail.telepres.com (Smail-3.2.0.111 2000-Feb-17 #1; 2000-Feb-24)
        (3968 bytes) via sendmail with 
/P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
        id <address@hidden>
        (sender <address@hidden>)
        for address@hidden; Thu, 8 Feb 2001 17:15:35 -0500 (EST)
From: Eric Siegerman <address@hidden>
To: address@hidden
Subject: Re: version control with shared workplace
Message-ID: <address@hidden>
Mail-Followup-To: address@hidden
References: <address@hidden>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <address@hidden>; from address@hidden on Thu, Feb 08, 2001 at 
03:57:14PM +0100
Organization: Telepresence Systems Inc.
Sender: address@hidden
Errors-To: address@hidden
X-BeenThere: address@hidden
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:address@hidden>
List-Post: <mailto:address@hidden>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/info-cvs>,
        <mailto:address@hidden>
List-Id: Announcements and discussions for the CVS version control system 
<info-cvs.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/info-cvs>,
        <mailto:address@hidden>
List-Archive: <http://mail.gnu.org/pipermail/info-cvs/>
Date: Thu, 8 Feb 2001 17:15:34 -0500
Status: O
Content-Length: 3435
Lines: 78

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.

_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs




reply via email to

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