RE: How to lock CVS for check-in

2001-10-15 Thread Jerry Nairn 


> From: David Everly [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 12, 2001 5:03 PM

> cvs -n stat filename seems only to work from a 'sandbox' point of
> view.  How would I use that in the context of a commitinfo script?

In local mode, the commands in commitinfo have direct access to your
"sandbox." In client/server mode, copies of the files being committed are
put in a "sandbox" in /tmp on the server. A commitinfo command can use
either:
cvs -n stat filename
or
cvs -n log -h filename
to find out if the file is on a branch in either case.
I use the "-n" option to cvs because at one point, trying to use these
commands while doing a commit would have you waiting for your own lock. Even
though these commands would not modify your workspace or the repository
using "-n" or not, when you used "-n" you didn't have to wait for the lock.
I'm not sure if this behavior has changed in a recent release or not, but in
any case, using these commands with "-n" works.
Jerry

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-12 Thread David Everly 

To recap, I'm looking to a way to lock branches so that people don't
accidentaly check out or commit to an 'inactive' branch.  I also need
the solution to work for those accessing CVSROOT vi the :ext: method.

cvs -n stat filename seems only to work from a 'sandbox' point of
view.  How would I use that in the context of a commitinfo script?

On Thu, Oct 11, 2001 at 09:19:38PM -0700, Jerry Nairn wrote:
> 
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, October 10, 2001 10:11 PM
> > [ On Thursday, October 11, 2001 at 08:24:11 (+0530), 
> > Shubhabrata Sengupta wrote: ]
> > > Wondering why this enhancement is needed in the commitinfo 
> > interface when
> > > you can always get the branch information out of the 
> > CVS/Entries file which
> > > is always available to the commitinfo script.
> > 
> > I'm not sure the CVS/Entries file is always available, and in any case
> > accessing it directly is a very very very bad hack.  Its 
> 
> cvs -n stat filename
> 
> works very well to get this kind of info from a commitinfo script. You get
> it from the CVS/Entries file through a cvs command.
> Jerry
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs

-- 
[EMAIL PROTECTED]
V-Net:   622-3286
Phone: 1-719-535-3286
Pager: 1-800-724-3624 # 140-1311

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-12 Thread Greg A. Woods 

[ On , October 12, 2001 at 11:30:07 (-0400), Jake Colman wrote: ]
> Subject: Re: How to lock CVS for check-in
>
> So please explain how you would prevent access to specific branches for
> specific users?  I'm not sure why you think that this is not a reasonable
> thing to want to try to do?

Simply put, I wouldn't.

Provided you trust each other (you should if you're working on the same
project), and provided everyone keeps an eye on everyone else looking
for not just illicit use, but also simple mistakes and such, there's no
real need for branch locking.

I see accidental commits to the wrong branches in all kinds of projects,
but they never cause any problems and they're easily reverted.  People
usually learn from their mistakes, and sometimes they even learn from
the mistakes of other, hopefully learning to be more careful, which is
generally a good thing.

The only time I could possibly see any real need for branch locking
would be in a scenario where people who are more naturally adversaries
are working on separate branches.  However even in this case if a third
independent party is responsible for doing merges, etc., then the
project will still be very much self-policing.

The problem with controls of any kind (locking, access controls, etc.)
is that they can get in the way more than they benefit.  In scenarios
where there are much more powerful mitigating forces they become only a
burden on everyone, not the least of which are the people who have to
set them up and maintain them.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-12 Thread Jake Colman 

> "GAW" == Greg A Woods <[EMAIL PROTECTED]> writes:

GAW> Far worse are operations which add, delete, or move, tags; but as
GAW> I've mentioned several times again recently it would be very easy to
GAW> add an additional access control for those kinds of things, at least
GAW> on a per-repository basis, in much the same way the existing
GAW> cvsadmin feature exists.

Greg,

So please explain how you would prevent access to specific branches for
specific users?  I'm not sure why you think that this is not a reasonable
thing to want to try to do?

...Jake

-- 
Jake Colman 

Principia Partners LLC  Phone: (201) 946-0300
Harborside Financial Center   Fax: (201) 946-0320
902 Plaza Two  E-mail: [EMAIL PROTECTED]
Jersey City, NJ 07311  www.principiapartners.com

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: How to lock CVS for check-in

2001-10-11 Thread Jerry Nairn 


> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 10, 2001 10:11 PM
> [ On Thursday, October 11, 2001 at 08:24:11 (+0530), 
> Shubhabrata Sengupta wrote: ]
> > Wondering why this enhancement is needed in the commitinfo 
> interface when
> > you can always get the branch information out of the 
> CVS/Entries file which
> > is always available to the commitinfo script.
> 
> I'm not sure the CVS/Entries file is always available, and in any case
> accessing it directly is a very very very bad hack.  Its 

cvs -n stat filename

works very well to get this kind of info from a commitinfo script. You get
it from the CVS/Entries file through a cvs command.
Jerry

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-11 Thread Shubhabrata Sengupta 

Absolutely - I would be relieved if commitinfo scripts get the branch
information as well. But I am reluctant to go do it myself because of my
unfamiliarity with CVS code and lack of time to gain some familiarity with
it. Though there have been patches floating around which achieved the same,
for some reason or the other they have not been integrated into the CVS
codebase. I could have built a patched CVS binary and use it, but the shop
where I work, the CVS server is controlled by the IT department (since it is
shared among a whole bunch of groups) and they are extremely reluctant to
accept such patches.

Thanks

Shubho

-Original Message-
From: Greg A. Woods <[EMAIL PROTECTED]>
To: CVS-II Discussion Mailing List <[EMAIL PROTECTED]>
Date: Thursday, October 11, 2001 10:38 PM
Subject: Re: How to lock CVS for check-in


>[ On Thursday, October 11, 2001 at 11:11:21 (+0530), Shubhabrata Sengupta
wrote: ]
>> Subject: Re: How to lock CVS for check-in
>>
>> At least in pserver access it is and I think it is also available in for
>> local repository access as well. I am not sure about :ext: access though.
>>
>> I agree that its contents and its structure is entirely internal to CVS
and
>> may change without notice from one CVS release to another. I do not write
>> anything into CVS/Entries at all - I use it to read the branch name of
the
>> file that is being committed. So that way there is very little danger of
>> corrupting that file. Of course I make assumptions about the structure of
>> the file and that may change from one CVS release to another - I am ready
to
>> change the regex I use to grep the branch name when that happens. The
>> advantages I get from controlling access to branches through commitinfo
>> script outweighs the risk in my case.
>
>Then is it not better to improve the commitinfo interface so that access
>to the raw CVS/Entries file is not necessary?
>
>--
> Greg A. Woods
>
>+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
>Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>
>
>___
>Info-cvs mailing list
>[EMAIL PROTECTED]
>http://mail.gnu.org/mailman/listinfo/info-cvs
>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: How to lock CVS for check-in

2001-10-11 Thread Greg A. Woods 

[ On Thursday, October 11, 2001 at 15:14:47 (-0700), Pyatt, Scott wrote: ]
> Subject: RE: How to lock CVS for check-in
>
> I don't know your environment, but branch locking is a common mechanism 
> for allowing read-only access to a branch.

Wel, "DUH!"  :-)

>  It's really quite useful 
> and given the high frequency that this issue pops up in this forum, I'm 
> not alone in my view.

I think the right phrase would be:  "not alone in your confusion".

>  I'm not knocking CVS.  Nor am I knocking anyone 
> who finds no use in it.  But in companies that have a sizable 
> development team, especially one that's globally dispersed, and need to 
> many support back releases, branch locking provides a good solution.

Do you have any idea how big the three main *BSD projects are, how
widely diverse and dispersed their committers are?  They seem to do well
enough without branch locking.

> Regardless of your SCM needs, there are many of us that would be better 
> off having branch locking as a standard feature in CVS.

More likely it`s: "many of you need to learn more about employing
external process controls"

>  If adding some 
> form of branch locking directly or indirectly (e.g., changing the 
> interface to commitinfo) causes other problems, I'll live without it, 
> add a kludge or move to a tool that supports it.  I'm okay with those
> choices, IF there is a technical reason for CVS to not support branch
> locking.

El-cheap-o branch locking is not hard to hack on with commitinfo.
That's about as far as it needs to go I think

> You say that it solves the wrong problem.  Given an example from my day 
> yesterday, a developer was swapping between a couple of workspaces to 
> compare what gets built in a release that is to ship in a few months 
> with one that shipped months back.  She accidentally checked in part of 
> a new feature in a back release.  Hey, she's human and fifteen minutes 
> later I had the problem fixed.  Our organization is large enough that
> this is a common problem, not because of one or two idiots, but because
> of the shear number of developers, with differing levels of experience, 
> and number of branches, this problem keeps popping up.  

I don't see the problem here.  You've apparently already got very
effective external process controls.  No disaster resulted.  Your
process prevailed.

Remember:

CVS is not a substitute for management.
CVS is not a substitute for developer communication.
CVS does not have change control
CVS does not have a builtin process model

You can build these things atop/around CVS -- i.e. use CVS as a
component in a larger system.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-11 Thread Greg A. Woods 

[ On , October 11, 2001 at 22:27:38 (+0100), James Youngman wrote: ]
> Subject: Re: How to lock CVS for check-in
>
> Speaking as someone who recently came very close to having to use "cvs
> co -p" to undo someone else's mistake (they were workign on the wrong
> branch by mistake) I disagree.

That particular command could not have caused any permanent damage, so
I'm not really sure what you're so worried about.

Far worse are operations which add, delete, or move, tags; but as I've
mentioned several times again recently it would be very easy to add an
additional access control for those kinds of things, at least on a
per-repository basis, in much the same way the existing cvsadmin feature
exists.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: How to lock CVS for check-in

2001-10-11 Thread Pyatt, Scott 

Greg,

I don't know your environment, but branch locking is a common mechanism 
for allowing read-only access to a branch.  It's really quite useful 
and given the high frequency that this issue pops up in this forum, I'm 
not alone in my view.  I'm not knocking CVS.  Nor am I knocking anyone 
who finds no use in it.  But in companies that have a sizable 
development team, especially one that's globally dispersed, and need to 
many support back releases, branch locking provides a good solution.

Regardless of your SCM needs, there are many of us that would be better 
off having branch locking as a standard feature in CVS.  If adding some 
form of branch locking directly or indirectly (e.g., changing the 
interface to commitinfo) causes other problems, I'll live without it, 
add a kludge or move to a tool that supports it.  I'm okay with those
choices, IF there is a technical reason for CVS to not support branch
locking.

You say that it solves the wrong problem.  Given an example from my day 
yesterday, a developer was swapping between a couple of workspaces to 
compare what gets built in a release that is to ship in a few months 
with one that shipped months back.  She accidentally checked in part of 
a new feature in a back release.  Hey, she's human and fifteen minutes 
later I had the problem fixed.  Our organization is large enough that
this is a common problem, not because of one or two idiots, but because
of the shear number of developers, with differing levels of experience, 
and number of branches, this problem keeps popping up.  

The right solution to the right problem may be to genetically engineer 
developers that don't make mistakes, but it might be a bit easier to 
implement branch locking.

-Scott

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 11, 2001 1:46 PM
To: Jake Colman
Cc: [EMAIL PROTECTED]
Subject: Re: How to lock CVS for check-in


[ On , October 11, 2001 at 14:41:17 (-0400), Jake Colman wrote: ]
> Subject: Re: How to lock CVS for check-in
>
> So what do _you_ recommend for implementing branch locking?

I don't recommend implementing branch locking in CVS at all.

Anyone who thinks they need it probably has far larger problems that
branch locking won't really solve in the first place.  It's a bad
workaround to the wrong problem.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-11 Thread James Youngman 

[EMAIL PROTECTED] (Greg A. Woods) writes:

> [ On , October 11, 2001 at 14:41:17 (-0400), Jake Colman wrote: ]
> > Subject: Re: How to lock CVS for check-in
> >
> > So what do _you_ recommend for implementing branch locking?
> 
> I don't recommend implementing branch locking in CVS at all.
> 
> Anyone who thinks they need it probably has far larger problems that
> branch locking won't really solve in the first place.  It's a bad
> workaround to the wrong problem.

Speaking as someone who recently came very close to having to use "cvs
co -p" to undo someone else's mistake (they were workign on the wrong
branch by mistake) I disagree.

-- 
James Youngman
Manchester, UK.  +44 161 226 7339
PGP (GPG) key ID for <[EMAIL PROTECTED]> is 64A95EE5 (F1B83152).

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-11 Thread Greg A. Woods 

[ On , October 11, 2001 at 14:41:17 (-0400), Jake Colman wrote: ]
> Subject: Re: How to lock CVS for check-in
>
> So what do _you_ recommend for implementing branch locking?

I don't recommend implementing branch locking in CVS at all.

Anyone who thinks they need it probably has far larger problems that
branch locking won't really solve in the first place.  It's a bad
workaround to the wrong problem.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-11 Thread Jake Colman 

>>>>> "GAW" == Greg A Woods <[EMAIL PROTECTED]> writes:

GAW> [ On Thursday, October 11, 2001 at 08:24:11 (+0530), Shubhabrata
GAW> Sengupta wrote: ]
    >> Subject: Re: How to lock CVS for check-in
>>
>> Wondering why this enhancement is needed in the commitinfo interface
>> when you can always get the branch information out of the CVS/Entries
>> file which is always available to the commitinfo script.

GAW> I'm not sure the CVS/Entries file is always available, and in any
GAW> case accessing it directly is a very very very bad hack.  Its
GAW> contents should be private and for CVS internal use only.  The fact
GAW> that some of its structure is documented in the manual is not
GAW> permission to go mucking about in it unless you're cleaning up some
GAW> form of corruption or another.


So what do _you_ recommend for implementing branch locking?

...Jake

-- 
Jake Colman 

Principia Partners LLC  Phone: (201) 946-0300
Harborside Financial Center   Fax: (201) 946-0320
902 Plaza Two  E-mail: [EMAIL PROTECTED]
Jersey City, NJ 07311  www.principiapartners.com

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: How to lock CVS for check-in

2001-10-11 Thread Pyatt, Scott 

Greg,

Are you arguing that this functionality be added as part of standard CVS in
a future release (which I would prefer) or are you simply suggesting to
Shubhabrata to change the CVS code for his or her own needs?

-Scott

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 11, 2001 9:58 AM
To: CVS-II Discussion Mailing List
Subject: Re: How to lock CVS for check-in


[ On Thursday, October 11, 2001 at 11:11:21 (+0530), Shubhabrata Sengupta
wrote: ]
> Subject: Re: How to lock CVS for check-in
>
> At least in pserver access it is and I think it is also available in for
> local repository access as well. I am not sure about :ext: access though.
> 
> I agree that its contents and its structure is entirely internal to CVS
and
> may change without notice from one CVS release to another. I do not write
> anything into CVS/Entries at all - I use it to read the branch name of the
> file that is being committed. So that way there is very little danger of
> corrupting that file. Of course I make assumptions about the structure of
> the file and that may change from one CVS release to another - I am ready
to
> change the regex I use to grep the branch name when that happens. The
> advantages I get from controlling access to branches through commitinfo
> script outweighs the risk in my case.

Then is it not better to improve the commitinfo interface so that access
to the raw CVS/Entries file is not necessary?

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-11 Thread Greg A. Woods 

[ On Thursday, October 11, 2001 at 11:11:21 (+0530), Shubhabrata Sengupta wrote: ]
> Subject: Re: How to lock CVS for check-in
>
> At least in pserver access it is and I think it is also available in for
> local repository access as well. I am not sure about :ext: access though.
> 
> I agree that its contents and its structure is entirely internal to CVS and
> may change without notice from one CVS release to another. I do not write
> anything into CVS/Entries at all - I use it to read the branch name of the
> file that is being committed. So that way there is very little danger of
> corrupting that file. Of course I make assumptions about the structure of
> the file and that may change from one CVS release to another - I am ready to
> change the regex I use to grep the branch name when that happens. The
> advantages I get from controlling access to branches through commitinfo
> script outweighs the risk in my case.

Then is it not better to improve the commitinfo interface so that access
to the raw CVS/Entries file is not necessary?

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-10 Thread Shubhabrata Sengupta 

At least in pserver access it is and I think it is also available in for
local repository access as well. I am not sure about :ext: access though.

I agree that its contents and its structure is entirely internal to CVS and
may change without notice from one CVS release to another. I do not write
anything into CVS/Entries at all - I use it to read the branch name of the
file that is being committed. So that way there is very little danger of
corrupting that file. Of course I make assumptions about the structure of
the file and that may change from one CVS release to another - I am ready to
change the regex I use to grep the branch name when that happens. The
advantages I get from controlling access to branches through commitinfo
script outweighs the risk in my case.

Thanks

Shubho

-Original Message-
From: Greg A. Woods <[EMAIL PROTECTED]>
To: CVS-II Discussion Mailing List <[EMAIL PROTECTED]>
Date: Thursday, October 11, 2001 10:47 AM
Subject: Re: How to lock CVS for check-in


>[ On Thursday, October 11, 2001 at 08:24:11 (+0530), Shubhabrata Sengupta
wrote: ]
>> Subject: Re: How to lock CVS for check-in
>>
>> Wondering why this enhancement is needed in the commitinfo interface when
>> you can always get the branch information out of the CVS/Entries file
which
>> is always available to the commitinfo script.
>
>I'm not sure the CVS/Entries file is always available, and in any case
>accessing it directly is a very very very bad hack.  Its contents should
>be private and for CVS internal use only.  The fact that some of its
>structure is documented in the manual is not permission to go mucking
>about in it unless you're cleaning up some form of corruption or another.
>
>--
> Greg A. Woods
>
>+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
>Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>
>
>___
>Info-cvs mailing list
>[EMAIL PROTECTED]
>http://mail.gnu.org/mailman/listinfo/info-cvs
>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-10 Thread Greg A. Woods 

[ On Thursday, October 11, 2001 at 08:24:11 (+0530), Shubhabrata Sengupta wrote: ]
> Subject: Re: How to lock CVS for check-in
>
> Wondering why this enhancement is needed in the commitinfo interface when
> you can always get the branch information out of the CVS/Entries file which
> is always available to the commitinfo script.

I'm not sure the CVS/Entries file is always available, and in any case
accessing it directly is a very very very bad hack.  Its contents should
be private and for CVS internal use only.  The fact that some of its
structure is documented in the manual is not permission to go mucking
about in it unless you're cleaning up some form of corruption or another.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-10 Thread Shubhabrata Sengupta 

Yes it is - I use that same kind of scenario down here in my workplace. I
had posted a script to do this sometime back on this list, a Python script
 I forget the name of the author - apologies)  was also posted a couple of
weeks back which achieves the same thing - searching the archives should
unearth them.

I have the same kind of scenario - there are a whole bunch of branches (some
for support, some for experimental dev. some for the current release and so
on and so forth) and we have a geographically distributed team as well.
Branch locking is necessary for us the same reason - developers have shot
themselves in the foot a number of times inthe past.

Thanks

Shubho

-Original Message-
From: Pyatt, Scott <[EMAIL PROTECTED]>
To: 'Shubhabrata Sengupta' <[EMAIL PROTECTED]>; 'Brad L.
Chisholm' <[EMAIL PROTECTED]>; David Everly <[EMAIL PROTECTED]>
Cc: Larry Jones <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
<[EMAIL PROTECTED]>; [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, October 11, 2001 9:07 AM
Subject: RE: How to lock CVS for check-in


>Is CVS/Entries available to the commitinfo script when the repository is on
>a Unix server and the developer is working on an NT client (pserver)?  If
>so, I can put something together.
>
>With companies like mine that have so many branches in order to support a
>number of back and future releases, I really need to implement branch
>locking to keep the developers from accidentally shooting themselves in the
>foot (happened again today).  I'm just surprised that something as basic as
>branch locking has not made its way into CVS yet.  That aside, CVS has been
>a decent tool for us.
>
>Thanks,
>-Scott
>
>-Original Message-
>From: Shubhabrata Sengupta [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, October 10, 2001 7:54 PM
>To: Pyatt, Scott; 'Brad L. Chisholm'; David Everly
>Cc: Larry Jones; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Re: How to lock CVS for check-in
>
>
>Wondering why this enhancement is needed in the commitinfo interface when
>you can always get the branch information out of the CVS/Entries file which
>is always available to the commitinfo script.
>
>Thanks
>
>Shubho
>
>-Original Message-
>From: Pyatt, Scott <[EMAIL PROTECTED]>
>To: 'Brad L. Chisholm' <[EMAIL PROTECTED]>; David Everly
><[EMAIL PROTECTED]>
>Cc: Larry Jones <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
><[EMAIL PROTECTED]>; [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>Date: Thursday, October 11, 2001 3:36 AM
>Subject: RE: How to lock CVS for check-in
>
>
>>"How to lock a branch?"  This seems to be the number one question posted
to
>>info-cvs.  I posted it myself two years ago.  Is there anyway this
>>enhancement can get rolled into a future release of cvs (e.g., 1.12)?  If
>>not, is the fear that it may break existing commitinfo scripts?
>>
>>Thanks,
>>-Scott
>>
>>-Original Message-
>>From: Brad L. Chisholm [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, October 10, 2001 1:15 PM
>>To: David Everly
>>Cc: Brad L. Chisholm; Larry Jones; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>>Subject: Re: How to lock CVS for check-in
>>
>>
>>You can selectively lock branches, but only if the branch info can get
>>passed to your commitinfo script.  We have "enhanced" the commitinfo
>>interface locally to send additional parameters we find useful, including
>>the branch info.  I'd be happy to send the diffs (commit.c), if anyone
>>is interested.
>>
>>-Brad
>>
>>On Wed, Oct 10, 2001 at 11:57:25AM -0600, David Everly wrote:
>>> Can I do a selective lock using this process, such that only certain
>>> branches are locked?  What would my script look for if this could be
>>> done?
>>>
>>> On Wed, Oct 10, 2001 at 12:59:46PM -0400, Brad L. Chisholm wrote:
>>> > You could also create a commitinfo trigger which returns non-zero, and
>>> > optionally displays a message indicating that check-ins are currently
>>> > disabled.  Since read locks can occur in normal use, this also allows
>>> > the users to distinguish between a mandated lockdown, and just a
normal
>>> > lock collision.
>>> >
>>> > -Brad
>>> >
>>> > On Tue, Oct 09, 2001 at 03:28:10PM -0400, Larry Jones wrote:
>>> > > [EMAIL PROTECTED] writes:
>>> > > >
>>> > > >I have set up a CVS as part of my project. At times I
>>want to
>>> > > > lock the CVS for check-ins .B

RE: How to lock CVS for check-in

2001-10-10 Thread Pyatt, Scott 

Is CVS/Entries available to the commitinfo script when the repository is on
a Unix server and the developer is working on an NT client (pserver)?  If
so, I can put something together.  

With companies like mine that have so many branches in order to support a
number of back and future releases, I really need to implement branch
locking to keep the developers from accidentally shooting themselves in the
foot (happened again today).  I'm just surprised that something as basic as
branch locking has not made its way into CVS yet.  That aside, CVS has been
a decent tool for us.

Thanks,
-Scott

-Original Message-
From: Shubhabrata Sengupta [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 10, 2001 7:54 PM
To: Pyatt, Scott; 'Brad L. Chisholm'; David Everly
Cc: Larry Jones; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: How to lock CVS for check-in


Wondering why this enhancement is needed in the commitinfo interface when
you can always get the branch information out of the CVS/Entries file which
is always available to the commitinfo script.

Thanks

Shubho

-Original Message-
From: Pyatt, Scott <[EMAIL PROTECTED]>
To: 'Brad L. Chisholm' <[EMAIL PROTECTED]>; David Everly
<[EMAIL PROTECTED]>
Cc: Larry Jones <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
<[EMAIL PROTECTED]>; [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, October 11, 2001 3:36 AM
Subject: RE: How to lock CVS for check-in


>"How to lock a branch?"  This seems to be the number one question posted to
>info-cvs.  I posted it myself two years ago.  Is there anyway this
>enhancement can get rolled into a future release of cvs (e.g., 1.12)?  If
>not, is the fear that it may break existing commitinfo scripts?
>
>Thanks,
>-Scott
>
>-Original Message-
>From: Brad L. Chisholm [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, October 10, 2001 1:15 PM
>To: David Everly
>Cc: Brad L. Chisholm; Larry Jones; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Re: How to lock CVS for check-in
>
>
>You can selectively lock branches, but only if the branch info can get
>passed to your commitinfo script.  We have "enhanced" the commitinfo
>interface locally to send additional parameters we find useful, including
>the branch info.  I'd be happy to send the diffs (commit.c), if anyone
>is interested.
>
>-Brad
>
>On Wed, Oct 10, 2001 at 11:57:25AM -0600, David Everly wrote:
>> Can I do a selective lock using this process, such that only certain
>> branches are locked?  What would my script look for if this could be
>> done?
>>
>> On Wed, Oct 10, 2001 at 12:59:46PM -0400, Brad L. Chisholm wrote:
>> > You could also create a commitinfo trigger which returns non-zero, and
>> > optionally displays a message indicating that check-ins are currently
>> > disabled.  Since read locks can occur in normal use, this also allows
>> > the users to distinguish between a mandated lockdown, and just a normal
>> > lock collision.
>> >
>> > -Brad
>> >
>> > On Tue, Oct 09, 2001 at 03:28:10PM -0400, Larry Jones wrote:
>> > > [EMAIL PROTECTED] writes:
>> > > >
>> > > >I have set up a CVS as part of my project. At times I
>want to
>> > > > lock the CVS for check-ins .But checkouts should not be locked. Is
>there a
>> > > > way to do this in the CVS. Could any one help me to resolve the
>issue.
>> > >
>> > > You need to create a read lock in each directory in your repository.
>> > > See the manual for technical details:
>> > >
>> > > <http://www.cvshome.org/docs/manual/cvs_2.html#SEC17>
>> > >
>> > > -Larry Jones
>> > >
>> > > Even though we're both talking english, we're not speaking the same
>language.
>> > > -- Calvin
>> > >
>> > > ___
>> > > Bug-cvs mailing list
>> > > [EMAIL PROTECTED]
>> > > http://mail.gnu.org/mailman/listinfo/bug-cvs
>> >
>> > ___
>> > Info-cvs mailing list
>> > [EMAIL PROTECTED]
>> > http://mail.gnu.org/mailman/listinfo/info-cvs
>>
>> --
>> [EMAIL PROTECTED]
>> V-Net:   622-3286
>> Phone: 1-719-535-3286
>> Pager: 1-800-724-3624 # 140-1311
>
>___
>Info-cvs mailing list
>[EMAIL PROTECTED]
>http://mail.gnu.org/mailman/listinfo/info-cvs
>
>___
>Info-cvs mailing list
>[EMAIL PROTECTED]
>http://mail.gnu.org/mailman/listinfo/info-cvs
>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-10 Thread Shubhabrata Sengupta 

Wondering why this enhancement is needed in the commitinfo interface when
you can always get the branch information out of the CVS/Entries file which
is always available to the commitinfo script.

Thanks

Shubho

-Original Message-
From: Pyatt, Scott <[EMAIL PROTECTED]>
To: 'Brad L. Chisholm' <[EMAIL PROTECTED]>; David Everly
<[EMAIL PROTECTED]>
Cc: Larry Jones <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
<[EMAIL PROTECTED]>; [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, October 11, 2001 3:36 AM
Subject: RE: How to lock CVS for check-in


>"How to lock a branch?"  This seems to be the number one question posted to
>info-cvs.  I posted it myself two years ago.  Is there anyway this
>enhancement can get rolled into a future release of cvs (e.g., 1.12)?  If
>not, is the fear that it may break existing commitinfo scripts?
>
>Thanks,
>-Scott
>
>-Original Message-
>From: Brad L. Chisholm [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, October 10, 2001 1:15 PM
>To: David Everly
>Cc: Brad L. Chisholm; Larry Jones; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Re: How to lock CVS for check-in
>
>
>You can selectively lock branches, but only if the branch info can get
>passed to your commitinfo script.  We have "enhanced" the commitinfo
>interface locally to send additional parameters we find useful, including
>the branch info.  I'd be happy to send the diffs (commit.c), if anyone
>is interested.
>
>-Brad
>
>On Wed, Oct 10, 2001 at 11:57:25AM -0600, David Everly wrote:
>> Can I do a selective lock using this process, such that only certain
>> branches are locked?  What would my script look for if this could be
>> done?
>>
>> On Wed, Oct 10, 2001 at 12:59:46PM -0400, Brad L. Chisholm wrote:
>> > You could also create a commitinfo trigger which returns non-zero, and
>> > optionally displays a message indicating that check-ins are currently
>> > disabled.  Since read locks can occur in normal use, this also allows
>> > the users to distinguish between a mandated lockdown, and just a normal
>> > lock collision.
>> >
>> > -Brad
>> >
>> > On Tue, Oct 09, 2001 at 03:28:10PM -0400, Larry Jones wrote:
>> > > [EMAIL PROTECTED] writes:
>> > > >
>> > > >I have set up a CVS as part of my project. At times I
>want to
>> > > > lock the CVS for check-ins .But checkouts should not be locked. Is
>there a
>> > > > way to do this in the CVS. Could any one help me to resolve the
>issue.
>> > >
>> > > You need to create a read lock in each directory in your repository.
>> > > See the manual for technical details:
>> > >
>> > > <http://www.cvshome.org/docs/manual/cvs_2.html#SEC17>
>> > >
>> > > -Larry Jones
>> > >
>> > > Even though we're both talking english, we're not speaking the same
>language.
>> > > -- Calvin
>> > >
>> > > ___
>> > > Bug-cvs mailing list
>> > > [EMAIL PROTECTED]
>> > > http://mail.gnu.org/mailman/listinfo/bug-cvs
>> >
>> > ___
>> > Info-cvs mailing list
>> > [EMAIL PROTECTED]
>> > http://mail.gnu.org/mailman/listinfo/info-cvs
>>
>> --
>> [EMAIL PROTECTED]
>> V-Net:   622-3286
>> Phone: 1-719-535-3286
>> Pager: 1-800-724-3624 # 140-1311
>
>___
>Info-cvs mailing list
>[EMAIL PROTECTED]
>http://mail.gnu.org/mailman/listinfo/info-cvs
>
>___
>Info-cvs mailing list
>[EMAIL PROTECTED]
>http://mail.gnu.org/mailman/listinfo/info-cvs
>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: How to lock CVS for check-in

2001-10-10 Thread Pyatt, Scott 

"How to lock a branch?"  This seems to be the number one question posted to
info-cvs.  I posted it myself two years ago.  Is there anyway this
enhancement can get rolled into a future release of cvs (e.g., 1.12)?  If
not, is the fear that it may break existing commitinfo scripts?

Thanks,
-Scott

-Original Message-
From: Brad L. Chisholm [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 10, 2001 1:15 PM
To: David Everly
Cc: Brad L. Chisholm; Larry Jones; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: How to lock CVS for check-in


You can selectively lock branches, but only if the branch info can get
passed to your commitinfo script.  We have "enhanced" the commitinfo
interface locally to send additional parameters we find useful, including
the branch info.  I'd be happy to send the diffs (commit.c), if anyone 
is interested.

-Brad

On Wed, Oct 10, 2001 at 11:57:25AM -0600, David Everly wrote:
> Can I do a selective lock using this process, such that only certain
> branches are locked?  What would my script look for if this could be
> done?
> 
> On Wed, Oct 10, 2001 at 12:59:46PM -0400, Brad L. Chisholm wrote:
> > You could also create a commitinfo trigger which returns non-zero, and
> > optionally displays a message indicating that check-ins are currently
> > disabled.  Since read locks can occur in normal use, this also allows
> > the users to distinguish between a mandated lockdown, and just a normal
> > lock collision.
> > 
> > -Brad
> > 
> > On Tue, Oct 09, 2001 at 03:28:10PM -0400, Larry Jones wrote:
> > > [EMAIL PROTECTED] writes:
> > > > 
> > > >            I have set up a CVS as part of my project. At times I
want to
> > > > lock the CVS for check-ins .But checkouts should not be locked. Is
there a
> > > > way to do this in the CVS. Could any one help me to resolve the
issue.
> > > 
> > > You need to create a read lock in each directory in your repository. 
> > > See the manual for technical details:
> > > 
> > > <http://www.cvshome.org/docs/manual/cvs_2.html#SEC17>
> > > 
> > > -Larry Jones
> > > 
> > > Even though we're both talking english, we're not speaking the same
language.
> > > -- Calvin
> > > 
> > > ___
> > > Bug-cvs mailing list
> > > [EMAIL PROTECTED]
> > > http://mail.gnu.org/mailman/listinfo/bug-cvs
> > 
> > ___
> > Info-cvs mailing list
> > [EMAIL PROTECTED]
> > http://mail.gnu.org/mailman/listinfo/info-cvs
> 
> -- 
> [EMAIL PROTECTED]
> V-Net:   622-3286
> Phone: 1-719-535-3286
> Pager: 1-800-724-3624 # 140-1311

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to lock CVS for check-in

2001-10-10 Thread Brad L. Chisholm 

You can selectively lock branches, but only if the branch info can get
passed to your commitinfo script.  We have "enhanced" the commitinfo
interface locally to send additional parameters we find useful, including
the branch info.  I'd be happy to send the diffs (commit.c), if anyone 
is interested.

-Brad

On Wed, Oct 10, 2001 at 11:57:25AM -0600, David Everly wrote:
> Can I do a selective lock using this process, such that only certain
> branches are locked?  What would my script look for if this could be
> done?
> 
> On Wed, Oct 10, 2001 at 12:59:46PM -0400, Brad L. Chisholm wrote:
> > You could also create a commitinfo trigger which returns non-zero, and
> > optionally displays a message indicating that check-ins are currently
> > disabled.  Since read locks can occur in normal use, this also allows
> > the users to distinguish between a mandated lockdown, and just a normal
> > lock collision.
> > 
> > -Brad
> > 
> > On Tue, Oct 09, 2001 at 03:28:10PM -0400, Larry Jones wrote:
> > > [EMAIL PROTECTED] writes:
> > > > 
> > > >            I have set up a CVS as part of my project. At times I want to
> > > > lock the CVS for check-ins .But checkouts should not be locked. Is there a
> > > > way to do this in the CVS. Could any one help me to resolve the issue.
> > > 
> > > You need to create a read lock in each directory in your repository. 
> > > See the manual for technical details:
> > > 
> > > 
> > > 
> > > -Larry Jones
> > > 
> > > Even though we're both talking english, we're not speaking the same language.
> > > -- Calvin
> > > 
> > > ___
> > > Bug-cvs mailing list
> > > [EMAIL PROTECTED]
> > > http://mail.gnu.org/mailman/listinfo/bug-cvs
> > 
> > ___
> > Info-cvs mailing list
> > [EMAIL PROTECTED]
> > http://mail.gnu.org/mailman/listinfo/info-cvs
> 
> -- 
> [EMAIL PROTECTED]
> V-Net:   622-3286
> Phone: 1-719-535-3286
> Pager: 1-800-724-3624 # 140-1311

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs