info-cvs
[Top][All Lists]
Advanced

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

Re: Tag locking change


From: Adam Bregenzer
Subject: Re: Tag locking change
Date: 09 Oct 2002 14:26:15 -0400

On Wed, 2002-10-09 at 13:58, Greg A. Woods wrote:
> [ On , October 9, 2002 at 10:03:08 (-0400), Adam Bregenzer wrote: ]
> > Subject: Re: Tag locking change
> >
> > I can think of specific examples where testing, etc. may not happen in a
> > 'working copy' of the code.  For example, one of the projects I am using
> > cvs for is a website.  I have a script in cvs that, upon checkin, copies
> > the file over to a directory so that the 'current' cvs version of the
> > site can be immediately tested.
> 
> Yes, sure, but that copying is done (or at least the source for the
> copying is created with) "cvs update", RIGHT?  (i.e. it had better be!)

Not at all.  The server that holds the cvs repository also has apache
runing on it.  When a commit occurs each file that is committed is
copied into a seperate directory.  That directory is the DocumentRoot
for apache.  That way, when a change is committed it is automagicall
viewable by browsing to the cvs server.  The point is that one who does
not edit the site manages and approves the site.  Currently that
individual runs cvs rtag when the site is in a producation ready state. 
Then a script is run that does a cvs export with that tag and posts it
to the live site.  It has nothing to do with the client, it's all
*server* side.  I see no reason for it to bve tied to an update, I don't
even know how to execute a server-side script on update and wouldn't
want to anyways.

> 
> >  There is not branching in the code or
> > anything fancy so I currently use rtag to tag the head of the branch
> > when we decide it is ready.
> 
> When it's "ready" you should be "cvs tag"ing the working directory which
> matches the "ready" revisions of the files.
But what if I have not working directory.  What if the developers are
just that.  Developers.  I can certianly tell them to tag it for me but
that's a bit strange.

> 
> What do you do with that tag afterwards?  Presumably you "cvs export"
> using it and create a master copy of the "ready" files to ship to your
> production web servers?  That would be the right way to do the release.
> 

Of course I do, it's how that tag is generated that we are discussing.

> > Also, it can be convienent to use
> > rtag if cvs is integrated with other tools.
> 
> You mean to tag the head of a branch?  That doesn't make sense.  What's
> more "convenient" about getting undefined results!?!?!?!

Actually, I realized something else, you can't run an rtag from a
application that was run from a commit info script.  That's what I was
thinking.  This is a bad example from a practiaclity standpoint but it
does illistrate my point.  Say every time you commit changes, a script
runs, looks at the first line of your comment and checks for a bug
number.  If it finds one it tags the entire source tree and adds a
comment to your bug tracking software with the tag.  This can't be
easily or practically done with a working copy of the code.  While there
are several better ways to do it and you probably can't run an rtag
command from a script run from a *info file it is an example.

Really, with the way cvs is written, I agree that rtag should lock on a
per-directory basis.  However, it can be frustrating that cvs suffers
from such a narrow scope.

> 
> -- 
>                                                               Greg A. Woods
> 
> +1 416 218-0098;            <address@hidden>;           <address@hidden>
> Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>
> 
> 
> _______________________________________________
> 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]