>--- Forwarded mail from [EMAIL PROTECTED]
>Paul Sander writes:
>>
>> But the following streams of commands are exactly equivalent (assuming
>> rtag were modified to accept both -D and -r options):
>>
>> cvs checkout -r branch module cvs rtag -D now -r branch module
>> cvs tag label
>No
Paul Sander writes:
>
> But the following streams of commands are exactly equivalent (assuming
> rtag were modified to accept both -D and -r options):
>
> cvs checkout -r branch module cvs rtag -D now -r branch module
> cvs tag label
No, they're not, unless the module has no subdirectori
-0400), Adam Bregenzer wrote: ]
> > Subject: Re: Tag locking change
> >
> > On Wed, 2002-10-09 at 13:58, Greg A. Woods wrote:
> > >
> > > Yes, sure, but that copying is done (or at least the source for the
> > > copying is created with) "cvs update"
>--- Forwarded mail from [EMAIL PROTECTED]
>Paul Sander wrote:
>> I claim that "y" == "now" is a common special case. Therein lies the
>> "tag the head of a branch" issue.
> It is an *uncommon* special case. In every other case, the tagger
>has an honest chance of knowing what they're
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Wednesday, October 9, 2002 at 10:13:42 (-0700), Paul Sander wrote: ]
>> Subject: Re: Tag locking change
>>
>> There are lots of cases where someone demands "tag branch x as of time y".
>What the heck does tha
Adam Bregenzer wrote:
> 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 auto
On Thu, 2002-10-10 at 05:40, Adam Bregenzer wrote:
> On Wed, 2002-10-09 at 14:58, Greg A. Woods wrote:
>
> > My point was that you can do the same thing more reliably with a "cvs
> > update" in a working directory that is the DocumentRoot.
> But then it wouldn't be automagic, it would be whenever
On Thu, 2002-10-10 at 04:26, Adam Bregenzer wrote:
> 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.
> While there
> are several bett
[ On , October 9, 2002 at 15:40:35 (-0400), Adam Bregenzer wrote: ]
> Subject: Re: Tag locking change
>
> On Wed, 2002-10-09 at 14:58, Greg A. Woods wrote:
> >
> > My point was that you can do the same thing more reliably with a "cvs
> > update" in a worki
[ On Wednesday, October 9, 2002 at 10:13:42 (-0700), Paul Sander wrote: ]
> Subject: Re: Tag locking change
>
> There are lots of cases where someone demands "tag branch x as of time y".
What the heck does that have to do with tagging the head of a branch?!?!?!?
> As for
On Wed, 2002-10-09 at 14:58, Greg A. Woods wrote:
> [ On , October 9, 2002 at 14:26:15 (-0400), Adam Bregenzer wrote: ]
> > Subject: Re: Tag locking change
> >
> > On Wed, 2002-10-09 at 13:58, Greg A. Woods wrote:
> > >
> > > Yes, sure, but that copying
[ On , October 9, 2002 at 14:26:15 (-0400), Adam Bregenzer wrote: ]
> Subject: Re: Tag locking change
>
> On Wed, 2002-10-09 at 13:58, Greg A. Woods wrote:
> >
> > Yes, sure, but that copying is done (or at least the source for the
> > copying is created with) "c
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, October 8, 2002 at 22:32:18 (-0700), Mike Ayers wrote: ]
>> Subject: Re: Tag locking change
>>
>> Greg A. Woods wrote:
>>
>> > If you really Really REALLY want to tag the head of a branch then just
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'
[ On Wednesday, October 9, 2002 at 11:26:08 (-0400), Larry Jones wrote: ]
> Subject: Re: Tag locking change
>
> Greg A. Woods writes:
> >
> > I think the issue is some of us don't want 'cvs rtag' to "work" when the
> > intent is to tag th
[ 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 web
Greg A. Woods writes:
>
> I think the issue is some of us don't want 'cvs rtag' to "work" when the
> intent is to tag the head of a branch, especially not with the new more
> per-directory-only locking scheme
Just to reemphasize, the per-directory locking scheme is not "new", it's
what all versi
day, October 8, 2002 at 22:32:18 (-0700), Mike Ayers wrote: ]
> > Subject: Re: Tag locking change
> >
> > Greg A. Woods wrote:
> >
> > > If you really Really REALLY want to tag the head of a branch then just
> > > check out the branch (or do a "cvs upd
[ On Tuesday, October 8, 2002 at 22:32:18 (-0700), Mike Ayers wrote: ]
> Subject: Re: Tag locking change
>
> Greg A. Woods wrote:
>
> > If you really Really REALLY want to tag the head of a branch then just
> > check out the branch (or do a "cvs update" in
to tag the head of
a branch in an instantaneous fashion. Wouldn't you want to
build/test, etc. first? If you're just doing daily tags, can't you
just tag the previous second - wouldn't that be good enough?
I'm kind of lost on what the point of contention is her
[ On Tuesday, October 8, 2002 at 20:02:14 (-0700), Paul Sander wrote: ]
> Subject: Re: Tag locking change
>
> >--- Forwarded mail from [EMAIL PROTECTED]
>
> >[ On Tuesday, October 8, 2002 at 16:11:42 (-0700), Paul Sander wrote: ]
> >> Subject: Re: Tag locking change
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, October 8, 2002 at 16:11:42 (-0700), Paul Sander wrote: ]
>> Subject: Re: Tag locking change
>>
>> >--- Forwarded mail from [EMAIL PROTECTED]
>>
>> >Mark writes:
>> >>
>> &
[ On Tuesday, October 8, 2002 at 16:11:42 (-0700), Paul Sander wrote: ]
> Subject: Re: Tag locking change
>
> >--- Forwarded mail from [EMAIL PROTECTED]
>
> >Mark writes:
> >>
> >> If one wants to tag the latest on a branch, why should one have to create
>--- Forwarded mail from [EMAIL PROTECTED]
>Mark writes:
>>
>> If one wants to tag the latest on a branch, why should one have to create a
>> workarea to do it?
>How do you know you want to tag the latest on a branch? Either you have
>no idea what the "latest" actually is, or you know that no
Greg A. Woods writes:
>
> If you're just creating a branch based on some other tag then I think
> it's much more efficient to use 'cvs rtag -r BRANCH_BASE_POINT', at
> least it seems to be if you're running directly on the repository server.
Indeed, creating a tag based on an existing tag is one
Mark writes:
>
> If one wants to tag the latest on a branch, why should one have to create a
> workarea to do it?
How do you know you want to tag the latest on a branch? Either you have
no idea what the "latest" actually is, or you know that no one is going
to be trying to commit changes while
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Monday, October 7, 2002 at 12:39:29 (-0400), Larry Jones wrote: ]
> > Subject: Re: Tag locking change
> >
> > Paul Sander writes:
> > >
> > > Another serious issue is when someone commi
[ On Monday, October 7, 2002 at 16:38:19 (-0400), Larry Jones wrote: ]
> Subject: Re: Tag locking change
>
> Patwardhan, Rajesh writes:
> >
> > Would it be a safe workaround to use something like -D"10 minutes ago "
> > and assume that something currentl
Paul Sander writes:
>
> After checking the manual again, I see that the "cvs rtag" command can
> take -r and -D options. It doesn't say that both can be given in the same
> command. Hopefully they can.
Unfortunately, they cannot. I'm not sure why -- just removing the
check would probably do t
Commit uses two-phase locking principles, which means it locks everything
it needs, does the processing, then unlocks. Larry's change removes two-
phase locking from rtag, which means that rtag can be interrupted by other
write operations. So rtag won't interfere with commit, but commit can
inte
Patwardhan, Rajesh writes:
>
> Would it be a safe workaround to use something like -D"10 minutes ago "
> and assume that something currently being checked in will not be in the
> tagging process initiated with a rtag.
>
> ( I am assuming I wait for 10 minutes after a proper file as needed by
>
Title: Re: Tag locking change
A quick question in the context of the question below
Would it be a safe workaround to use something like -D"10 minutes ago " and assume that something currently being checked in will not be in the tagging process initiated with a rtag.
( I am
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Monday, October 7, 2002 at 12:39:29 (-0400), Larry Jones wrote: ]
>> Subject: Re: Tag locking change
>>
>> Paul Sander writes:
>> >
>> > Another serious issue is when someone commits while an rtag
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> > and lots of people complained about it because
> tagging large trees can
> > take a long time and no one can even do checkouts
> or updates while the
> > tag is in progress.
>
> That's life. Tell them to get a faster disk
> subsystem, or get ove
On Mon, Oct 07, 2002 at 02:01:36PM -0400, Greg A. Woods wrote:
> [ On Monday, October 7, 2002 at 12:39:29 (-0400), Larry Jones wrote: ]
> > Anyone who does an rtag without specifying an explicit revision to tag
> > gets exactly what they deserve.
>
> This part I sort of agree with, though strictl
[ On Monday, October 7, 2002 at 12:39:29 (-0400), Larry Jones wrote: ]
> Subject: Re: Tag locking change
>
> Paul Sander writes:
> >
> > Another serious issue is when someone commits while an rtag is in
> > progress, and the new data are erroneously tagged.
>
>
[ On Monday, October 7, 2002 at 12:38:21 (-0400), Larry Jones wrote: ]
> Subject: Re: Tag locking change
>
> Greg A. Woods writes:
> >
> > Is this really a good idea? Do people who start a 'cvs co -r' or some
> > other command using the new tag too soon bef
Paul Sander writes:
>
> Another serious issue is when someone commits while an rtag is in
> progress, and the new data are erroneously tagged.
Anyone who does an rtag without specifying an explicit revision to tag
gets exactly what they deserve.
-Larry Jones
Sometimes I think the surest sign t
Greg A. Woods writes:
>
> Is this really a good idea? Do people who start a 'cvs co -r' or some
> other command using the new tag too soon before an [r]tag is finished
> deserve to lose (assuming by some strange quirk of concurrency that
> their command catches up to the tag)?
Yes, I'd say they
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Sunday, October 6, 2002 at 18:01:01 (-0400), Larry Jones wrote: ]
>> Subject: Tag locking change
>>
>> I've checked in a change to the [r]tag command to go back to locking
>> one directory at a time (correctly,
[ On Sunday, October 6, 2002 at 18:01:01 (-0400), Larry Jones wrote: ]
> Subject: Tag locking change
>
> I've checked in a change to the [r]tag command to go back to locking
> one directory at a time (correctly, this time) rather than locking the
> entire tree for the whole t
I've checked in a change to the [r]tag command to go back to locking
one directory at a time (correctly, this time) rather than locking the
entire tree for the whole time. In the process, I noticed that the
admin command also locks the entire tree, for no good reason that I can
think of. Can any
42 matches
Mail list logo
