RE: How to lock CVS for check-in
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
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
[ 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
[ 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
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
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
[ 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
[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
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
[ 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
[ 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
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
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
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
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 .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
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
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. 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
