info-cvs
[Top][All Lists]
Advanced

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

Re: Don't commit during tagging


From: Russ Sherk
Subject: Re: Don't commit during tagging
Date: Sun, 3 Jul 2005 23:04:20 -0400

Greets,

On 7/3/05, S I <address@hidden> wrote:
> Needn't worry about that.  CVS tags the matching copies of the revisions in
> your working folder only.  In other words, if you just did a checkout of
> -foo.bar (rev 1.6) and a developer shortly after, committed a new rev 1.7,
> your build and compile are based on 1.6 and when you tag
> cvs/respository/project...you have only tagged rev 1.6 (e.g.
> release_build_1.2.139) and 1.7 is not of your concern.  And when you do a
> checkout base on release_build_1.2.139 in the future, you'd always get rev
> 1.6 of -foo.bar.
CVS also locks on checkin/tagging (at least rtag locks).  I am not
sure as to wheather it locks on a per file basis or for the entire
duration of the tag process tho.  Your best bet is to put into place a
policy that ensures you have enough time to tag and not hold up
developers.  We do ours at 00:01 EST.  A notice is sent to all
developers informing them of the specified tagging time and any other
details.
> 
> 
> To ensure proper tagging I always work with a clean & fresh working folder.
> Delete your local project and do a fresh checkout.  You can now tag this
> pristine working folder, however, if your build does not compile or the
> Mainline's in a broken state (it does happen, you know?), then you've just
> wasted a tag.
Not so.  tag -F -rNEW_REV_OR_TAG ORRIGINAL_TAG_NAME <files>  will
force the tag up and allow a fix to be tagged with the same tag name. 
I'm not sure how kosher this is, but we do a developer build one day
before the weekly build.  All developers install and test their
changes.   Any _minor_ bugs found are fixed and the tag is forced up. 
This ensures a clean weekly build.  This way it is possible to keep
tight control over what fixes get in a load (as opposed to doing
another tag from possibly now unstable HEAD).
> 
> I always tag after, only because I have to modify couple of files and commit
> them during or after the build.  Historically most folks or build/release
> engineers tag after they've made sure they have a clean build.  But everyone
> does it differently based on their needs.
> 
> 
> AlwaysSo it doesn't matter whether you t
> 
> ----Original Message Follows----
> From: "Stephan Lange" <address@hidden>
> To: <address@hidden>
> Subject: Don't commit during tagging
> Date: Sun, 3 Jul 2005 20:25:03 +0200
> MIME-Version: 1.0
> Received: from lists.gnu.org ([199.232.76.165]) by mc7-f34.hotmail.com with
> Microsoft SMTPSVC(6.0.3790.211); Sun, 3 Jul 2005 11:30:45 -0700
> Received: from localhost ([127.0.0.1] helo=lists.gnu.org)by lists.gnu.org
> with esmtp (Exim 4.43)id 1Dp9G1-0007Um-H2for address@hidden; Sun, 03 Jul
> 2005 14:31:57 -0400
> Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)id
> 1Dp9Ey-0007L8-OHfor address@hidden; Sun, 03 Jul 2005 14:30:53 -0400
> Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)id
> 1Dp9Ev-0007Jt-HKfor address@hidden; Sun, 03 Jul 2005 14:30:51 -0400
> Received: from [199.232.76.173] (helo=monty-python.gnu.org)by lists.gnu.org
> with esmtp (Exim 4.43) id 1Dp9Ev-0007IV-Bafor address@hidden; Sun, 03 Jul
> 2005 14:30:49 -0400
> Received: from [213.165.64.20] (helo=mail.gmx.net)by monty-python.gnu.org
> with smtp (Exim 4.34) id 1Dp9Fw-0000yu-69for address@hidden; Sun, 03 Jul
> 2005 14:31:52 -0400
> Received: (qmail invoked by alias); 03 Jul 2005 18:26:02 -0000
> Received: from e180009081.adsl.alicedsl.de (EHLO mmadmin) [85.180.9.81]by
> mail.gmx.net (mp019) with SMTP; 03 Jul 2005 20:26:02 +0200
> X-Message-Info: JGTYoYF78jGErbofBFuQwn4TW5/jwTiTvD3bIpKlmB0=
> X-Authenticated: #6465864
> X-Mailer: Microsoft Office Outlook, Build 11.0.6353
> Thread-Index: AcV//IfFqwuAxwp3Qka7EV5kgQUBOA==
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2149
> X-Y-GMX-Trusted: 0
> X-BeenThere: address@hidden
> X-Mailman-Version: 2.1.5
> Precedence: list
> List-Id: Announcements and discussions for the CVS version control
> system<info-cvs.gnu.org>
> List-Unsubscribe:
> <http://lists.gnu.org/mailman/listinfo/info-cvs>,<mailto:address@hidden>
> List-Archive: <http://lists.gnu.org/pipermail/info-cvs>
> List-Post: <mailto:address@hidden>
> List-Help: <mailto:address@hidden>
> List-Subscribe:
> <http://lists.gnu.org/mailman/listinfo/info-cvs>,<mailto:address@hidden>
> Errors-To: address@hidden
> Return-Path: address@hidden
> X-OriginalArrivalTime: 03 Jul 2005 18:30:45.0421 (UTC)
> FILETIME=[537EF5D0:01C57FFD]
> 
> Hey Folks!
> 
> 
> 
> We are using cvs in an enterprise web-application development project.
> 
> 
> 
> My task is the build and deployment of the new releases.
> 
> 
> 
> The build will be making every week. Before I start the process I tag all
> the modules I need and then check out the modules with this tag.
> 
> 
> 
> The tagging process needs time because some modules are very big.
> 
> 
> 
> The question is, how can I be sure that during my tagging operation, no
> developer is committing some new stuff to the modules?
> 
> 
> 
> Thanks for your help!
> 
> 
> 
> So long!
> 
> 
> 
> Stephan
> 
> 
> 
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/info-cvs
> 
> 
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/info-cvs
> 
Anyhow, hope this helps a bit.

Toodaloo,

--Russ




reply via email to

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