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:25:32 -0400

>From address@hidden  Tue Feb 13 09:22:22 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 
JAA05956
        for <address@hidden>; Tue, 13 Feb 2001 09:22:20 +0900
Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org)
        by fencepost.gnu.org with esmtp (Exim 3.16 #1 (Debian))
        id 14STAV-00059H-00; Mon, 12 Feb 2001 19: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 14ST9i-00058j-00
        for <address@hidden>; Mon, 12 Feb 2001 19:17:18 -0500
Received: from localhost 
        by mail.telepres.com (Smail-3.2.0.111 2000-Feb-17 #1; 2000-Feb-24)
        (5069 bytes) via sendmail with 
/P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
        id <address@hidden>
        (sender <address@hidden>)
        for address@hidden; Mon, 12 Feb 2001 19:17:17 -0500 (EST)
From: Eric Siegerman <address@hidden>
To: "Group, CVS Info," <address@hidden>
Subject: Re: checking out src code from dev repo to release repo.
Message-ID: <address@hidden>
Mail-Followup-To: "Group, CVS Info," <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 Tue, Feb 13, 2001 at 
08:42:14AM +1000
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: Mon, 12 Feb 2001 19:17:17 -0500
Status: O
Content-Length: 4522
Lines: 107

On Tue, Feb 13, 2001 at 08:42:14AM +1000, Peter Disiot wrote:
> I'm doing a project where we check into the repo, source code that is
> reviewed, and tested.  We require a sandbox type repository, where we can put
> our stubs etc.

Do I understand correctly that you're trying to create one
repository for "approved" sources, and one for not-yet-approved
work in progress?  (If not, my comments may not make much sense.)

> Essentially we have two repositories, one call dev/projectName and the other
> simply called projectName.  How do I checkout code etc from the dev repo into
> the projectName repo.  I've tried the -d on the co command but I get a "repo
> dev does not match repo projectName" error.

No, CVS doesn't work that way.  A sandbox can only be associated
with one repository!

CVS doesn't directly support what you're trying to do, but you
could fake it with branches:
  - When a programmer starts on a task, they create a branch
    to be used exclusively for that task.

  - They happily commit on the task branch.  (This doesn't
    affect people working on other tasks, since each task
    has its own branch.)

  - When they're ready to submit their work for review, they
    simply tell the reviewer the name of the task branch.

  - When the reviewer has approved the changes, they merge the
    task branch into the mainline.

  - That task branch is NOT used for any other work.  If the
    reviewer asks for changes, of course, those will be made on
    the task branch in question; but once the task has been
    accepted and merged, its task branch should be retired
    permanently (though probably still kept in the repo for
    reference).

  - Someone just posted patches to implement per-branch
    permissions.  You might consider using these, and making
    retired task branches read-only.

Thus, the mainline (aka trunk) contains approved work, and the
work in progress appears on many short-lived task branches.
(There will likely also be other longer-lived branches, for
post-release bug fixes and the like.  The bug-fixing work might
itself be done on task branches, but merged into the bugfix
branch, instead of into the trunk.)

This repo will rapidly become an incomprehensible mess, unless
you write some wrapper scripts to:
  - ensure that things are done in a methodical way (enforce a
    naming scheme for branches, among other things)

  - keep track of which branches are "live" and which have been
    retired (since CVS can't do that)

  - provide a way for people to list only the active branches,
    and/or to list all the branches with their statuses (after a
    while, the great majority of branches will be retired ones,
    and visually weeding through the list CVS provides will be
    annoying and error-prone)

  - update the per-branch permissions, if you opt to go that
    route

Possible alternative source-control systems (which I haven't
used, but which contain features that you might find helpful):
  - Aegis, which is claimed to let you enforce process (eg. code
    must have regression tests, and pass them, before you can
    commit it).

  - ODE, which already distinguishes between the operations
    "commit" and "publish" (I'm probably misremembering the
    terminology).  "Commit" creates new revisions, but they're
    only visible to the committer.  "Publish" is what makes the
    work visible to the rest of the team.  So you can do a bunch
    of commits, to keep track of your own work, without worrying
    about breaking things for others; and only publish your work
    when it's ready for public consumption.  (I can't remember
    whether you can "publish" to the reviewer but not to other
    developers; for you, that's a key issue.)
    
    CVS, of course, doesn't make this distinction -- a "cvs
    commit" does both things.  My suggestion above is precisely
    an attempt to fake ODE's commit/publish distinction in CVS.

> I guess this is a two fold question in that maybe our process is wrong. 

Not your process; just your attempt to fit CVS to it :-)
Though extreme-programming folks would probably disagree...

--

|  | /\
|-_|/  >   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]