RE: A way to see who has checked out a module?
Am I correct in assuming that you are looking for a web based equivilent to the 'cvs editors' command? I don't know if there is such a tool, but I'm sure someone will be able to tell you if we can agree on the 'command line' option you originally referred to. Chris -Original Message- From: Steve deRosier [mailto:[EMAIL PROTECTED] Sent: Wednesday, 14 January 2004 10:25 To: Phil Labonte Cc: CVS List Subject: Re: A way to see who has checked out a module? Sorry, it looks like I misread your question. No I don't know of any tool to do this. Actually, I'm not sure it is even possible on the command line...who has what checked out isn't a relevant question in CVS. Using the various hooks for script running on cvs commands, you might be able to put together your own tool (if there is any hook run on a checkout even); a script that writes the user to a file on checkouts and removes the name from from the file on releases and then a web page that includes this info might be a way to do it. But, again I don't see how it would be useful. When I work on projects, I check out the module and check in any changes I make. When I'm done I usually just leave the module in my sandbox directory ignoring it untill I need to do something with it again, at which point I just issue a 'cvs up' command to get current. Right now I've got probably 15 modules checked out, but have only touched about 6 of them in the last 6 months (and am currently only actively working with 2 of them). - Steve Phil Labonte wrote: I use ViewCVS as well but there is no option to see a log of checked out files is there? If there is can you let me know where? Steve deRosier wrote: viewcvs - http://viewcvs.sourceforge.net/index.html It's what we use and we love it. - Steve Phil Labonte wrote: Is there a web add-on that we can use to see who has checked out a given module? I know you can use the command line but I have some users that would like to see who has checked out a given module, and I do not want to give them shell access to the box. ___ 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: cvs and gnats link?
The linkage we have in place between CVS and gnats is the following: a. in parts of our repository you have to enter a gnats PR and database into the log message b. if a gnats PR and database are in the cvs log message, the PR must be in a defined state for the commit to succeed c. the cvs log message is automatically added to the top of the fix: field in the gnats PR That is all we have. *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Schwenk, Jeanie Sent: Tuesday, 18 September 2001 1:12 p.m. To: CVSpost (E-mail) Cc: '[EMAIL PROTECTED]' Subject: cvs and gnats link? We had a bug that toasted some product (see many $$ here). Now management wants a formal system of notification, complete with reports and and appropriate sign off when changes take place. With absolutely nothing for a budget of course. This sweeping bureacracy change is to include a bug tracking system. I've been looking at GNATS and would like to know if CVS and GNATS can be linked. From a developer standpoint, it would be most convenient and less error prone to type the same information once rather than twice. I ran across a statement that ClearCase and GNATS could be linked but didn't find any evidence to support it. I'm also looking at Bugzilla and Jitterbug. What do you use? Any recommendations? Jeanie ___ 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 well does CVS handle other types of data?
But Greg, you say CVS is a source code management tool (really an ASCII text file management tool, given all the caveats you add) and the manual excerpt you quote says CVS is 'a version control system'. A version control system DOES NOT IMPLY source code management. A version control tool allows you to control and recreate versions. Merging is an added feature. For us, the biggest plus for CVS is that it will manage multiple files and directories (even if it doesn't version directories, we can manage that). We started using CVS after investing a lot of effort to reinvent it in a minimal form on top of RCS! You've already told people to use CVS (a version control system) for managing their source and then find ANOTHER version control system (or make their own) for managing binary (or non ASCII text) files. THey are saying that they already have a version control system in CVS and why should they need to operate two version control systems. You keep saying to find the screwdriver instead of using the hammer, but a. is it really a hammer for a screw? It is still being used for version control. The users have decided the 'merge' features are not important, it is the version control they want. b. where do they find out about screwdrivers? Are there any screwdrivers or only your hammer plus string and glue solution? Now you'll probably tell me to go and find a screwdriver as well! I generally find your posts interesting and informative, but on occasions you seem to be opposed to what everyone else on the list wants and your opinion is inviolate. *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: Friday, 13 July 2001 8:38 a.m. To: Peter Fox Cc: CVS-II Discussion Mailing List Subject: RE: How well does CVS handle other types of data? [ On Thursday, July 12, 2001 at 11:38:21 (-0400), Peter Fox wrote: ] Subject: RE: How well does CVS handle other types of data? Sorry my graphic people are the same people who are writing Delphi code. So, have someone put on a virtual graphics people hat! What's the problem here? That should make things easier, not harder! IMHO the people who say get your binaries out of my merging system are looking very much as CVS as a tool to control parallel development of source code. CVS becomes a technique for applying patches to a development thread. Yes, that's exactly what a source code management tool is. CVS is a source code management tool that assists users in merging concurrent changes to files, be they concurrent edits on the same branch, or not-necessarily-temporally-related changes on separate branches. A commit is literally the addition of a delta to a branch! All CVS does is keep track of branches and revision relationships in groups of source files. That's it. That's all. That's enough. IMHO the people who are saying I need to put binaries in CVS are looking at using CVS for managing a project. i.e. they want to be able to have a single repository that they have confidence stores all the items needed to produce a release. I hate to say this again, but RTFM: What is CVS? CVS is a version control system. Using it, you can record the history of your source files. [[]] What is CVS not? CVS can do a lot of things for you, but it does not try to be everything for everyone. CVS is not a build system. CVS is not a substitute for management. CVS is not a substitute for developer communication. CVS does not have change control CVS is not an automated testing program CVS does not have a builtin process model CVS becomes not just a developers tool but also an essential part of the release mechanism. It allows the developers, build people, system testers and customers to agree what they are looking at. Yes of course. CVS keeps track of branches and revision relationships in groups of source files. A project which produces products has many things more than just source files, and many more tools than just a source code control tool. It is the build system and the configuration management tools which give project managers the ability to reliably reproduce products from known sources. All CVS does is keep track of the related source code revisions necessary to produce such a reliable repeatable build. It is also a tool to enable
RE: How well does CVS handle other types of data?
Ah, So now you're suggesting RCS for 'binary' files and CVS for ASCII text files. Now a person who needs to manage 'binary' and 'text' files needs to develop a tool for managing versions of both (and the 'binary' files may be in multiple directories so we'd better add in a tool that works across different directories). Suddenly we're starting to need a tool like CVS! Wait and look at this, then comment. We need: 1. Ability to recreate a particular contour of file versions 2. Ability to work across multiple directories Greg suggests that people write their own tool to do this, however CVS (which is written on top of RCS, so how can it be good for binaries on it's own, but not underneath CVS) can already do this. CVS also allows you to merge text files. For some binary files a merge can be managed (e.g. word or framemaker documents), for others (e.g. gifs) it does not make any sense. Is merging of text files important? In Greg's world it is, in other peoples eyes it isn't. The CVS paper (cvs_paper.ms in the CVS source distribution) says: CVS (Concurrent Versions System) is a front end to the RCS revision control system which extends the notion of revision control from a collection of files in a single directory to a hierarchical collection of directories each containing revision controlled files. Directories and files in the CVS system can be combined together in many ways to form a software release. CVS provides the functions necessary to manage these software releases and to control the concurrent editing of source files among multiple software developers. The six major features of \fBcvs\fP are listed below, and will be described in more detail in the following sections: 1. Concurrent access and conflict-resolution algorithms to guarantee that source changes are not lost. 2. Support for tracking third-party vendor source distributions while maintaining the local modifications made to those sources. 3. A flexible module database that provides a symbolic mapping of names to components of a larger software distribution. This symbolic mapping provides for location independence within the software release and, for example, allows one to check out a copy of the diff program without ever knowing that the sources to diff actually reside in the bin/diff directory. 4. Configurable logging support allows all committed source file changes to be logged using an arbitrary program to save the log messages in a file, notesfile, or news database. 5. A software release can be symbolically tagged and checked out at any time based on that tag. An exact copy of a previous software release can be checked out at any time, REGARDLESS of whether files or directories have been added/removed from the current software release. As well, a date can be used to check out the EXACT version of the software release as of the specified date. 6. A patch format file [Wall] can be produced between two software releases, even if the releases span multiple directories. According to this ONE of the benefits of CVS is the 'concurrent editing of source files' and ANOTHER is patching that is 1/3 of the major features of CVS. Now whenever I've been involved in product decisions, we've listed our requirements, prioritised them and then listed our requirements that each product supports. Usually no product meets all our requirements so it is a matter of determining which product best meets our top requirements. As merging probably doesn't fit in anyones requirement list for graphical files, merging and patches are 'extras' from CVS, not a 'wrong tool' decision. Yes Greg, you've been involved with CVS for a lot longer than most of us. But your vision isn't the only one for the software and maybe it isn't the only one! This thread seems to have drifted alot and people are now being criticised for offering solutions to the original problem as if they are the ones who asked the problem! *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: Friday, 13 July 2001 12:09 p.m. To: Thornley, David Cc: [EMAIL PROTECTED] Subject: RE: How well does CVS handle other types of data? [ On Thursday, July 12, 2001 at 16:53:53 (-0500), Thornley, David wrote: ] Subject: RE: How well does CVS handle other types of data? Except that I'm not banging my head against the wall, and it doesn't hurt. I don't know about the rest of you, but I'm not having problems with the way CVS manages
RE: How well does CVS handle other types of data?
I will now try not to raise to the bait when Greg starts forth. I was raising some hypothetical situations and discussions, not describing our reuirements. Greg has now told me not to use CVS. We can make our own decisions thank you and it sounds like one day it wih be Gregs CVS and everyone else's CVS. Greg, you seem to have moved from following the full debate to attacking everyone who participates and has a different point of view. You seem to assume that any hypothetical example people give is their actual position and then attack it! According to the original author of CVS, merging was ONE OF SIX advantages of CVS, not THE advantage! In summary Greg is saying that if you don't want 'automagic' merging don't use CVS. Greg says that the -kb code has flaws, but rather than fix them, get rid of it completely, even though it is part of the RCS framework that CVS is built on top of! From man co: -kb Generate a binary image of the old keyword string. This acts like -ko, except it performs all working file input and output in binary mode. This makes little difference on Posix and Unix hosts, but on DOS-like hosts one should use rcs -i -kb to initialize an RCS file intended to be used for binary files. Also, on all hosts, rcsmerge(1) normally refuses to merge files when -kb is in effect. That's all from me. Good evening from your future, it will be a beautiful day on Friday (well it was here):)! *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: Greg A. Woods [mailto:[EMAIL PROTECTED]] Sent: Friday, 13 July 2001 4:51 p.m. To: Chris Cameron Cc: CVS-II Discussion Mailing List Subject: RE: How well does CVS handle other types of data? [ On Friday, July 13, 2001 at 13:50:34 (+1200), Chris Cameron wrote: ] Subject: RE: How well does CVS handle other types of data? We need: 1. Ability to recreate a particular contour of file versions 2. Ability to work across multiple directories Good. If that's all of your requirements then please go find something else to use other than CVS. I'm sure there are many other tools that fill those requirements. I've written some shell scripts for SCCS that might even fill the bill for you. You can find them on my FTP site in dotfiles.tar.* (in the enclosed file .kshsccs). I've even been planning on fleshing them out to include more CVS-like features and will be happy to do so under your explicit directions, for a small fee of course. CVS does more than you need and some of what it does can be orthogonal to your needs and may therefore cause you problems if you try to use it for only those two purposes and without taking into account its limitations. Greg suggests that people write their own tool to do this, however CVS (which is written on top of RCS, so how can it be good for binaries on it's own, but not underneath CVS) can already do this. If this isn't clear by now then you have a fundamentally flawed understanding of how CVS works and what features it provides (and which it _explicitly_ does not provide, not to mention those it _implicitly_ does not provide). CVS also allows you to merge text files. For some binary files a merge can be managed (e.g. word or framemaker documents), for others (e.g. gifs) it does not make any sense. Is merging of text files important? In Greg's world it is, in other peoples eyes it isn't. Anyone and everyone who uses CVS as it is intended to be used must believe that merging of text files is critically imporant to their use of CVS! You don't even have to know what a branch is to still need merging to work if you use CVS. You're trying so hard now that you've not only bent the truth beyond recognition, you're now torturing it to death! Now whenever I've been involved in product decisions, we've listed our requirements, prioritised them and then listed our requirements that each product supports. Usually no product meets all our requirements so it is a matter of determining which product best meets our top requirements. As merging probably doesn't fit in anyones requirement list for graphical files, merging and patches are 'extras' from CVS, not a 'wrong tool' decision. If you want to go off and write something that meets your needs, then please do so. In the meantime please try to at least accept the fact that CVS might actually be at odds with your needs (besides
RE: Sticky tags
*** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Eric Siegerman Sent: Thursday, 12 July 2001 7:22 a.m. To: [EMAIL PROTECTED] Subject: Re: Sticky tags --- irina sturm [EMAIL PROTECTED] wrote: I don't understand: if I am doing what you say, I am not preserving myself of integrating the other users' modifications before finishing with my own, but just doing the same as for file_1. To do this (i.e. make and commit changes without (yet) integrating other peoples' changes), you'd need to create a branch. In which case also I can't understand what the sticky [non-branch] tag is useful for. Not that much, really, IMO. I suspect that they weren't really designed into CVS, but came about as a side-effect of sticky-branch-tag support -- the code just lets you make *any* tag sticky. We use non branch sticky tags for preserving 'contours' through our code (e.g. release 1.0, integration build 2, etc.). This is very usefull for determining changes from one 'release' to another and also for ensuring that we can always deliver the same 'release'. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How well does CVS handle other types of data?
How do you KNOW you're pulling in the correct resource for the particular icon etc. Does each change in an icon result in a new resource file? How do you ensure that you can always exactly recreate a previous release or does 'exactly recreate' only apply to your source code? *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff King Sent: Thursday, 12 July 2001 8:51 a.m. To: Peter Fox Cc: [EMAIL PROTECTED] Subject: RE: How well does CVS handle other types of data? We keep resource files (for icons, toolbar bitmaps, and other images) outside of the repository. Instead of having to store the binary data in the otherwise text-based forms, we simply use Bitmap.LoadFromResource in the source to pull the images from the separately maintained resource files. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Strange dir behavior and Emptydir
Emptydir is a placeholder used in CVS for when directories which may not exist in the repository are created as part of the checkout process (if you follow what I mean), such as a -d in the modules file or -d on the command line. CVS needs a Repository file and places Emptydir in there. You are not meant to be able to add any files to a directory created as a result of this Emptydir behaviour. HOWEVER, there was a bug in the code. I submitted a patch for this which I believe has now been added to 1.11 (Larry can clarify this). Basically the code prevented you from adding files to a directory with an EmptyDir repository. BUT there was no code to stop a directory being added and once the directory was added, you could add files. Either upgrade your CVS version, or apply my patch, which should be in the archives somewhere. Once you've managed to create files (and by necessity directories) in EmptyDir in the repository, you're in the place of nightmares! Behaviour changes depending on what you actually do! The person who did the adds, will be able to use CVS etc. to control the files, but anyone else will not be able to see them! If you then manipulate the repository to put things where they belong, the original culprit will get different behaviour to everyone else until they do a clean checkout. Before I made the patch, I had a commitinfo script which sent me a high priority e-mail anytime anyone committed to EmptyDir! Then I could sort things out before it got too serious! *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Pyatt, Scott Sent: Friday, 29 June 2001 7:57 a.m. To: Info-Cvs (E-mail) Cc: Gupta, Neil Subject: Strange dir behavior and Emptydir When doing a checkout from the trunk, CVS creates directories in the workspace even if they are empty. You can prevent empty directories from being created by using -P to prune empty directories or if -r or -D are specified. Therefore, if you are checking out a branch using -r branch, empty directories are pruned. In the past when I've wanted to do perform some work to one of these empty directories, I simply do something like this: cvs co -r theBranch theModule cd parentDir cvs up -d theDir I've never had a problem with this until today. Today I do this and the cvs up -d theDir gives me the following message: cvs server: nothing known about theDir Obviously theDir is not the real name of the directory, but will suffice to illustrate my problem. The interesting thing is that theDir does exist in the repository (I checked to make sure) and there is active work in this directory on several other branches as well as on the trunk. I tried the following: cd parentDir mkdir theDir cvs add theDir For this example assume parentDir is /dirA/dirB/dirC. The command produced the following output. Directory /cvsroot/CVSROOT/Emptydir/theDir added to the repository Why did CVS create theDir under /cvsroot/CVSROOT/Emptydir instead of under /cvsroot/dirA/dirB/dirC which is where I was expecting it to get created in the repository. I've searched CVS documentation everywhere and can find no reference to Emptydir. What is this $CVSROOT/Emptydir? Is it possible that it is related to using an alias module defined in the $CVSROOT/modules? How do I get back to the behavior I thought I knew before? TIA, -Scott Scott Pyatt Release Engineering Manager Selectica, Inc. 3 West Plumeria Drive San Jose CA 95134.2111 www.selectica.com Direct: 408.545.2669 Main: 408.570.9700 Fax: 408.570.2167 See our Internet Selling Systems in action: http://www.selectica.com/iss_in_action/ ___ 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 avoid conflicts avalanche
Is this a symptom of your software not being adequately separated into 'core' and 'localised' sections? We try and separate out the common 'core' functionality which must not change from the 'localised' functionality which is needed for each customer. If there are a lot of merges and conflicts, it suggests to me that the different country releases aren't really 'standard' software. *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sergiy Sent: Tuesday, 26 June 2001 3:45 p.m. To: [EMAIL PROTECTED] Subject: How to avoid conflicts avalanche Hi, Our software has different modifications for different countries. Thus in our cvs repository we have the main development trunk, and country branches. When we cut a new major release on the trunk, we need to merge from the trunk to all country branches. These merges result in a large number of conflicts. It requires time and significant programming efforts to resolve those conflicts. One way to avoid this is to do interim merges regularly. The other way could be to pursue developers to use some script which automatically does the merge to country branches every time they commit to the trunk. But they often forget to follow such procedures, and apparently CVS doesn't have any way of enforcing this automatically. The question is, if anybody experienced similar problems and has them successfully resolved, what is the most effective solution to this problem, and whether CVS provides any means to support that? Thanks,Serg ___ 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: BRANCH LABEL FOR DIRECTORIES
So now you're saying that it could be included OOTB AND that you've proposed it in the past. But you've been arguing that this is a BAD IDEA (TM) and seem to continue that position later in the same e-mail! I'm just sitting on the sideline and observing this one, but you seem to be trying to have your cake and eat it! *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: Tuesday, 19 June 2001 9:04 a.m. To: CVS-II Discussion Mailing List Subject: Re: BRANCH LABEL FOR DIRECTORIES [ On Monday, June 18, 2001 at 15:18:16 (-0400), Noel L Yap wrote: ] Subject: Re: BRANCH LABEL FOR DIRECTORIES So why not have CVS do this work OOTB? You could. It's been proposed several times before. Nobody's stepped up to write the code. Even though I've also proposed it in the past, my proposal was in response to someone else's problem and of late I've not even had time to implement the solutions to my own problems, let alone anyone else's! ;-) It should be quite trivial to add such rename functionality to any of the more advanced font-ends to CVS (be they either stand alone clients, or wrappers that just call the existing command-line client). Even the handling of the manual parts of merging renamed/moved files could be done in the client and/or front-end. There's not even any need to do anything fancy -- just search back for magic rename comments in files that had no changes merged and if they are the result of a rename then go look (recursively) for the ancestor revision in the old file(s) and manually do the merge on the client side. Nothing at all needs to be changed in the repository structure to support such functionality. If people really want it then _they_ should build it! CVS is user supported software! How 'bout: Your company decides to change its name or goes through a merger and you're programming in Java? I'd say that people using CVS for Java (at least with traditional java development environments) are already on the verge of being in the land of the truly unsupported anyway. In any case, /why/ would it matter why anyone would do this? The fact is that it's a request commonly made. Your answer seems to be to deem that request as being wrong. People make stupid and idiotic requests of all kinds of things all the time. Only marketing departments ever seem to see any need to satisfy them. There's nothing wrong with telling someone that their request is wrong/inappropriate/out-of-place if that's the case. I thought most of us in the software world were supposed to be more in tune with doing careful requirements analysis and such. In the end, every product is market-driven -- if there's no need for CVS, it wouldn't exist. Sorry, I should have qualified that as mass-market (though I did qualify CVS as niche market). I think Greg has been saying that CVS is a niche product and that it shouldn't braoden it's horizons. So, if: 1. You have binary files, 2. You _ever_ need to rename files for the lifetime of your project, 3. You want to version directories, 4. You want to reuse a filename that's been rm'd in the past but with a different type, 5. Possibly others I can't think of right now, then don't use CVS. Well, not exactly 100% on all those points, but within reason. In this forum 99.999% of the FAQs that have no existing answer in context are from people who should not be using CVS in the first place (or who can't find anything better and are then uwilling to figure out how to use CVS properly). In fact there's obviously a very strong demand for something to fill the niche that CVS fits well into The only problem is that at least half the people in the world who are not in that niche seem to think that they should be able to use CVS for whatever hair-brained idea they've got too. If someone wants a tool with broader horizons than CVS then they should build it (and call it something else, of course ;-). If it eventually replaces CVS entirely then that's OK. If it doesn't then those in the niche where CVS fits will still have an appropriate tool to use to meet their needs. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED
RE: Removal of tagged files
It is scenario 1 and we're on 1.10.7. I'll look at getting appropriate updates. Thanks for the info. *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Eric Siegerman Sent: Tuesday, 12 June 2001 6:44 a.m. To: Infocvs Subject: Re: Removal of tagged files On Mon, Jun 11, 2001 at 11:46:29AM +1200, Chris Cameron wrote: We've had the experience of cvs allowing files to be removed from a non-branch tag! Do you mean by this: 1. cvs update -r release-tag file; cvs rm file 2. cvs tag -d release-tag file 3. something else? If (1), update your CVS. It prevents this at least from 1.10.8. If (3), please clarify... As for (2): You can't modify files on a non-branch tag, but you can remove! That you can't modify them isn't because that's been deemed a Bad Thing, but because it's simply impossible -- the underlying RCS doesn't permit you to modify an existing revision in-place. Deleting a tag clearly is possible. I can see your point that some shops might want to prevent just anyone (or anyone at all, for that matter) from doing it, but CVS is generally pretty lax about per-user permissions; it depends on underlying file-system permissions to give a coarse level of control, but that's about it. I believe there are patches floating around that claim to give you a finer-grained permission scheme (but whether they let you control this particular action, I wouldn't know). Search the list archives for references. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ 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: Crazy idea - replace RCS backend with ClearCase...!!!
Sorry to throw a spanner in the works, but from 1.10, CVS incorporates RCS as a set of libraries and doesn't call the external rcs commands. *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Julian Gosnell Sent: Wednesday, 23 May 2001 10:43 a.m. To: [EMAIL PROTECTED] Subject: Crazy idea - replace RCS backend with ClearCase...!!! OK - I'm mad, now here me out Imagine you work for a large company. They decide on a 'strategic' SCM - Clearcase - in which every project must live. They then task you with looking at OpenSource development methodologies and tools. Unsurprisingly, all of these use CVS - because it does the job and is free - in all senses of the word. I can look at forking each OpenSource project that I might like to deploy within my company (e.g. SourceForge, Tinderbox, Bonsai etc.), producing a Clearcase backend, and maybe merging (licences and project owners permitting) back my code, in the hope that it will continue to be maintained and I won't be left out on a branch, or I can consider something wierd : Tools using CVS for their SCM, ulimately as I understand it (I'm open to correction here), end up calling RCS. RCS has a nice small, closed set of functionality. I would be surprised if Clearcase could not replicate all of this... - So What is to stop me writing several wrapper scripts (e.g. ci, co, rcs etc...) which actually call clearcase to do the file-based version control ? This would be one piece of well defined work. Most well written CVS backends would continue to work oblivious to the fact that the implementation of the file versioning had changed. I would be happy since I could painlessly deploy OpenSource tools and work through CVS with them and my company would be happy because they would have all their source stuck into a repository which has cost them a small fortune. I guess what I'm asking is, Is the interface between CVS and a project in it's Repository completely described by RCS, or does CVS do things like go under the covers and parse the contents of RCS files ? What would the gotchas be ? Do you still think I'm crazy ? BTW - I work on two OpenSource projects using CVS in my own time, and try to advocate use of and contributing to OpenSource and FreeSoftware in my company, so if you fancy flaming me for wanting to rip-off everyone's hard work and put it to my own capitalistic ends, please think again. Thanks for your time, Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ 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: File permissions [make that directory permissions!]
Without contradicting any of Gregs comments on security, which have been aired in this forum too many times to count, I feel that Greg's last paragraph is the most relevant. What is the background to the original question? Is this an internal or external project? What are you trying to protect against? Malicious users or uses who may do potentially damaging operations without being aware of it? *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: Wednesday, 23 May 2001 10:44 a.m. To: Tracy Brown Cc: CVS-II Discussion Mailing List Subject: RE: File permissions [make that directory permissions!] [ On Tuesday, May 22, 2001 at 14:19:42 (-0700), Tracy Brown wrote: ] Subject: RE: File permissions [make that directory permissions!] I'm a little confused. For my user base, none have UNIX shell accounts. In the pserver password file: user:password:user_to_run_as i.e. bob:lsfdkuhsdf:pubcvs The $USER var will return the user (bob) and not the optional user_to_run_as (pubcvs) as noted in the above example. Thus, I can hold my users accountable to their modifications made in the repository. Where do you get that idea? There's only one user accountable for the repository and that's the user the pserver thing runs as. Any apparent accountability offered by pserver is only an illusion that cannot be verified. Accountability in Unix *requires* Unix user-ids for each entity that's to be held accountable. You cannot eat your cake and have it too. Note that because CVS is not a security tool and thus does not have any real security within it, it cannot do secure authentication and secure authorisation and it cannot prevent one fake user from making it look like some other fake user did something in the repository. CVS pserver has no accountability whatsoever. You are dreaming if you think otherwise. It also has no privacy whatsoever (unless you tunnel it through SSH, but that's rather pointless since you've got to create Unix accounts for SSH anyway). Without privacy the passwords, the code, etc., all passes over the network in the clear and without any protection from man-in-the-middle attacks (such as connection hijacking, connection spoofing, etc.). Trivial off-the-shelf tools will allow anyone with access to your network to do any manner of things to a pserver connection. With a tiny amount of additional work this might even include doing things like stuffing trojan code into your repository during a commit by someone else! As an administrator I really don't want to manage 100+ UNIX accounts just because I should trust them... that's a hassle. And we don't need to - we can obtain accountability without this silly hassle. You would rather administer fake accounts in some insecure application?!?!?!? Real unix accounts are most definitely *NOT* any kind of hassle! You're fooling yourself and focusing on the wrong issues. When you go to get a driver's license it's not just a photocopy of some master -- it's a unique document personalised to the person it is granted to. Note that you don't have to *support* full shell access to the server, but you do have to be aware that the possibility is there and that it cannot be prevented, pserver or not. (SSH+chroot might be able to restrict what parts and services on the server are visible and usable by the user, but otherwise don't change the equation w.r.t. the repository itself; and I personally would never use them in place of having a separate server.) If you're offering access to important files on your system then you really do want to create real individual Unix accounts for each and every entity you authorise such access for! With only fake pserver accounts you're providing all of the trappings (and hinding behind them) but none of the substance of real security controls. You are in fact implicitly trusting pserver users with what ammounts to shell access as the pserver user -- you just don't have any basis for that trust because you really cannot hold them accountable and you have not really authenticated them. Without using some external auditing process where the programmers are each individually required to re-verify the origin and intgrity of each of their changes the code in that repository could have been changed by anyone with IP access to the machine. If you don't want to add Unix user accounts for each real user then please don't fool yourself
RE: Triggers links to defect tracking systems
We use a commitinfo script to check for commit permission, a verifymsg script to validate the PR number and the loginfo file for putting the log message into our fault database. All this is done using pserver. commitinfo and verifymsg are run before the commit occurs and loginfo afterwards. *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jerry Nairn Sent: Friday, 11 May 2001 8:29 a.m. To: 'Tracy Brown'; [EMAIL PROTECTED] Subject: RE: Triggers links to defect tracking systems From: Tracy Brown [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 11:33 AM Mark D. Baushke wrote: While this is possible if you are using a local repository or the rsh/ssh transport, I don't know of any way to do it with the :pserver: method of interaction. The rcsinfo file template generation hook works great with :peserver: I haven't used this, but the documentation says that in client/server operation, the template is copied from the server at the time of checkout. Updates to the template on the server will not be reflected on the client until a new checkout is done. Jerry ___ 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: CVS problem
That was my first reaction as well. However IMHO this theory is incorrect. 1. I check out a file. 2. I build the .o file 3. I make changes to the file. 4. I realise I made a mistake in the changes, so I remove the file and do an update 5. make will now do an unnecessary rebuild of my .o file Only I can make decision as to whether the make needs to rebuild the .o file and the best way for me to make the decision is to manually remove the .o file if it needs rebuilding! This rebuild could have knock on effects throughout the rest of the developers sandbox. *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jerry Nairn Sent: Thursday, 10 May 2001 5:50 a.m. To: 'Chris Cameron'; Infocvs Subject: RE: CVS problem From: Chris Cameron [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 10:42 PM The checkout gets the correct timestamnp on the file. The first update gives bar.cc a timestamp which corresponds to the time you issued the update command. The second update give bar.cc the timestamp of the original checkin time of bar.cc That's the way it's supposed to work, to interact properly with make. Jerry ___ 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
FW: CVS problem
Greetings, One of our developers has reported the following behaviour from CVS. I think I've found in the update code where this behaviour, the question is whether there is a reason for this behaviour? Our developer expected the timestamp to revert to the original co timestamp. % cvs co foo/bar.cc % cd foo % ls -l % rm bar.cc % cvs update bar.cc % ls -l % rm bar.cc % vi CVS/Entries (remove the line for bar.cc) % cvs update bar.cc % ls -l The checkout gets the correct timestamnp on the file. The first update gives bar.cc a timestamp which corresponds to the time you issued the update command. The second update give bar.cc the timestamp of the original checkin time of bar.cc *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: reserved lock and other patches
Sorry about the reply format M$ won't let me change to a preferable format, but let's not go there! I've been off the air for a few weeks and have just caught up! When I incorporated Noel's edit patches into our CVS source (1.10.7) I modified sanity.sh so that it wouldn't choke on the new behaviour. I didn't add any checks for the new features. I can send you a sanity.sh diff if you want. *** Chris CameronOpen Telecommunications NZ Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Noel L Yap Sent: Thursday, 22 March 2001 12:34 p.m. To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: reserved lock and other patches My free time has run out again. The stuff I still need to get done are: 1. Update the documentation (since you volunteered and I don't have the necessary tools, I'll let you debug it :-) 2. Create regression tests. I still need a volunteer for this. I'll gladly communicate req's to such a volunteer. 3. Create two other small, unrelated patches. I'll do this myself, except the the docs and test cases. Thanks, Noel [EMAIL PROTECTED] on 2001.03.21 12:46:30 To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: Subject: Re: reserved lock and other patches "Derek R. Price" wrote: Noel L Yap wrote: I'd also want to see documentation updates (to cvs.texinfo) before I'd check this in. It looks like cvs.texinfo is easy enough to change, but can you tell me how I can test those changes? $ cd doc $ make info You know, if you don't have makeinfo /or tex installed, and can get all the pertinent information into the cvs.texinfo file, I can't imagine it wouldn't take me more than half an hour to fix errors and reformat it. Not that I'd want to, but if that's your stopper... I'd still need the separate patches and test cases, of course. Derek -- Derek Price CVS Solutions Architect http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- I've never made a mistake in my life. I thought I had once, but it turned out that I hadn't. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. ___ 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: problem with co -d xx -n : bug or feature?
Sorry, I'm on the road at the moment and can't check my e-mail often, or the
CVS repository at all! What you're describing seems very similar to the
patch I downloaded from cvshome.org (or it's previous incarnation) a year or
two ago. If you can wait 3 weeks, I can check our repository when I get
home. Otherwise, someone else may be able to help. As I said previously,
there is (was?) a patch at one time to fix a bug similar to this.
***
Chris CameronOpen Telecommunications NZ Ltd
Product Manager IN Product Management
[EMAIL PROTECTED] P.O.Box 10-388
+64 4 495 8403 (DDI) The Terrace
fax: +64 4 495 8419 Wellington
cell: +64 21 650 680New Zealand
Life, don't talk to me about life (Marvin - HHGTTG)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Haefelinger, Wolfgang
Sent: Friday, 2 February 2001 12:03 p.m.
To: '[EMAIL PROTECTED]'
Subject: RE: problem with "co -d xx -n" : bug or feature?
Hello,
'down-nailed' my problem (see below) to next few lines
in file ~/src/modules.c (around line 533). I included
the #ifdef and #endif lines - and voila, cvs behaves as
expected.
#ifdef HAVE_MAJOR_HACK
/* XXX - XXX - MAJOR HACK - DO NOT SHIP - this needs to
be !pipeout, but we don't know that here yet */
if (!run_module_prog)
goto do_special;
#endif
dir = where ? where : (mwhere ? mwhere : mname);
/* XXX - think about making null repositories at each dir here
instead of just at the bottom */
make_directories (dir);
if ( CVS_CHDIR (dir) 0)
{
error (0, errno, "cannot chdir to %s", dir);
spec_opt = NULL;
err++;
goto do_special;
}
Two questions remain:
(a) after all, what does the above 'XXX - XXX' comment
mean and where will cvs fail now?
(b) my naive assumption about an (ampersand) module was,
that a module is something like an abbreviation for
a (possible) large list of arguments to cvs, e.g.
writing the ampersand module
am mod1 mod
and executing
$cvs co am
is exactly equivalent with
$ cvs co mod1 mod2
or, in other word, my assumption was that an argument
identified as 'module' gets expanded by its definition
but the result of this expansion is evaluated then as
if I had typed it manually on the commandline.
But this is not the case: my assumption is that there
are two evaluation procedures, one for modules and one
for 'files' and my question is just: why?
Bye,
Wolfi.
-Ursprngliche Nachricht-
Von: Chris Cameron [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 2. Februar 2001 12:39
An: 'Haefelinger, Wolfgang'; [EMAIL PROTECTED]
Betreff: RE: problem with "co -d xx -n" : bug or feature?
There used to be a patch available at cvshome to fix a
similar problem in
the modules file. I cannot remember the exact details, but
we installed the
patch. AFAIK it has not been incorporated into the main CVS
tree. Sorry I
can't give you any more details, but I'm out of the office,
visiting sales
offices in the Americas, so can't get at our CVS repository
to give you more
details.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Haefelinger, Wolfgang
Sent: Friday, 2 February 2001 7:53 a.m.
To: '[EMAIL PROTECTED]'
Subject: problem with "co -d xx -n" : bug or feature?
Hello there,
here's my problem: defined an "ampersand module"
in $CVSROOT/CVSROOT/modules and got a problem when
checking out the module using checkout options "-d"
and "-d" and want to know whether this is a (known)
bug or a feature. That's what I have and what I did
on
$uname -a
SunOS intra-dev 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra-2
$cvs --v
Concurrent Versions System (CVS) 1.10.7 (client/server)
My repository contains the directories "mod1" and "mod2".
Want to checkout them both with a symbolic name. There-
fore I added the line "am mod1 mod2" to the modules
file:
$ cat $CVSROOT/CVSROOT/modules
am mod1 mod2
That's pretty fine since
$ rm -rf am
$ cvs co am
$ ls am
mod1 mod2
does exactly what I want. Even better,
$ rm -rf xx
$ cvs co -d xx am
$ ls xx
mod1 mod2
let's me checkout the modules in another directory. That's
wonderful, wow!
BUT, trying also option -n to prevent any additional checkout
script from beeing triggered behaves unexpected:
$ rm -rf *
$ cvs co -n -d xx am
$ l
RE: problem with co -d xx -n : bug or feature?
There used to be a patch available at cvshome to fix a similar problem in the modules file. I cannot remember the exact details, but we installed the patch. AFAIK it has not been incorporated into the main CVS tree. Sorry I can't give you any more details, but I'm out of the office, visiting sales offices in the Americas, so can't get at our CVS repository to give you more details. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Haefelinger, Wolfgang Sent: Friday, 2 February 2001 7:53 a.m. To: '[EMAIL PROTECTED]' Subject: problem with "co -d xx -n" : bug or feature? Hello there, here's my problem: defined an "ampersand module" in $CVSROOT/CVSROOT/modules and got a problem when checking out the module using checkout options "-d" and "-d" and want to know whether this is a (known) bug or a feature. That's what I have and what I did on $uname -a SunOS intra-dev 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra-2 $cvs --v Concurrent Versions System (CVS) 1.10.7 (client/server) My repository contains the directories "mod1" and "mod2". Want to checkout them both with a symbolic name. There- fore I added the line "am mod1 mod2" to the modules file: $ cat $CVSROOT/CVSROOT/modules am mod1 mod2 That's pretty fine since $ rm -rf am $ cvs co am $ ls am mod1 mod2 does exactly what I want. Even better, $ rm -rf xx $ cvs co -d xx am $ ls xx mod1 mod2 let's me checkout the modules in another directory. That's wonderful, wow! BUT, trying also option -n to prevent any additional checkout script from beeing triggered behaves unexpected: $ rm -rf * $ cvs co -n -d xx am $ ls mod1 mod2 The modules are checked out in the working directory and not as beeing told in the subdirectory "xx". BUT-BUT, on the other side, $ rm -rf * $ cvs co -n -d xx mod1 mod2 $ ls xx does the right thing. Ok, I'm much too stupid to understand why 'cvs' behave in this way, therefore I ask you, what's going on here. If this is a bug, I'm willing to fix it. Thanks, Wolfi. _Wolfgang Haefelinger voice: 069-263-16582 email: [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
Commitinfo behaviour
I know that commitinfo takes regular expressions to determine which script to run on each part of the repository. I've always (assumed I guess) thought that the regex started from CVSROOT. I've just observed behaviour which doesn't match this! Can anyone tell me how this is meant to work (is it a bug or expected behaviour). What I saw was: commitinfo: bbb/* script1 . aaa/* script2 . In the working directory was the structure aaa/ccc aaa/ddd/bbb aaa/eee During the commit script2 was run in aaa/ccc aaa/ddd and aaa/eee, but sript1 was run in aaa/ddd/bbb! *** Chris CameronOpen Telecommunications NZ Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: merge/diff GUI tool
On Wednesday, November 29, 2000 9:21 AM, Howard Zhou [SMTP:[EMAIL PROTECTED]] wrote: Hi, CVS Users, I am wondering if there is any GUI based diff/merge tool in the public domain, which can work with CVS? tkdiff. Sorry I can't remember where I downloaded it from. From memory it came with tkcvs. *** Chris CameronOpen Telecommunications NZ Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Ampersand module question
On Wednesday, November 29, 2000 10:22 AM, Laine Stump [SMTP:[EMAIL PROTECTED]] wrote: Laird Nelson [EMAIL PROTECTED] writes: I'm curious about ampersand modules. Once a regular module (containing another module via the "" construct) is checked out, does that module actually *know* that it contains the contained module? If my modules file says something like this: frobnicator frobnicator caturgiator ...and I do this: cvs checkout -P frobnicator ...then I get this (as expected): frobnicator/somedir frobnicator/caturgiator/someotherdir ...but now if I do this: cd frobnicator; rm -rf caturgiator; cd .. ...and then do this: cvs -q update -d -P -A ...then caturgiator does not reappear, suggesting that frobnicator's CVS directory does not record what the modules file engineered to happen. Correct. there isn't enough info about submodules in the upperlevel CVS directory to bring it back, and cvs update ignores the modules file. The only way to set this back up would be to re-checkout the project or checkout the caturgiator module directly at this level. I believe if you do cvs checkout from above the toplevel of an existing work directory, and it will update what's already there, and add anything new that it finds in the modules file. It won't *remove* anything that was taken out of the modules file, though. Is that by design? It seems more likely it was just an accident of implementation. The entire modules file concept doesn't seem very well thought out to me; more like an afterthought tacked on one rainy afternoon... This seems to be (on my quick look) an artifact of the files in the CVS directory. Entries contains the directories (and files) which have been checked out. Entries will have a D line for caturgiator. However CVS does an update by recursing into each directory in the current directory and doing an update there. In this case caturgiator doesn't have a directory so it can't be recursed into. CVS then goes into the repository in the location specified in Repository and tries to recreate files and directories that are in Entries, but not visible in the current directory. In this case caturgiator is not in the Repository location, so can't be updated. I guess the short answer is not to delete caturgiator once you've checked it out. It seems to me that the intention of the modules file was to allow you to perform several checkouts at one time, using an 'alias' instead of having to remember all the repository locations. ******* Chris CameronOpen Telecommunications NZ Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: No space left on device error during cvs status/update
On Thursday, November 02, 2000 9:40 AM, Robert Bresner [SMTP:[EMAIL PROTECTED]] wrote: [EMAIL PROTECTED] wrote: You write: Filesystemkbytesused avail capacity Mounted on /dev/dsk/c0t0d0s0 962582 830683 3564996%/ assuming /tmp is part of this device, then if your project is larger than 17.8 Megs your probably running out of space on /tmp. Why? Does CVS copy an entire project to /tmp before performing the likes of an update or status on my NT client? If this were the case, then ALL of my areas should fail, but only two of seven are failing. swap 1866405488 181152 3%/tmp Does this mean that the swap partition is mounted on /tmp??? Sure looks that way. I don't know much about swap spaces and mounts or, for that matter, setup of unix boxes. Can't solve your other problems, but this looks like a Solaris box. On Solaris, /tmp uses the swap partition. This df is showing that the swap space is mounted as /tmp. Therefore as more swap space is used, less space is available for /tmp AND this can change dynamically as the system is running! *** Chris CameronOpen Telecommunications NZ Ltd Senior Solution Architect IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: access rights to branches
On Wednesday, November 01, 2000 1:43 AM, Laird Nelson [SMTP:[EMAIL PROTECTED]] wrote: Shem Mazur wrote: I have a CVS user who continues to checkout modules or update files from the wrong branches. Can I restrict her ability to update from particular branches or main trunk? What the various other replies were trying (somewhat unhelpfully :-)) to tell you is no, not with CVS out of the box. With its commitinfo mechanism you can't get access to either (a) the new revision number prior to the commit taking place (a feature that sure would be nice to have) or (b) whether or not the user supplied a -r switch to the commit command. If you could get either (a) or (b) then you could reliably block commits onto a branch. There was a patch posted to this group a while ago, to add revision information to the rest of the information passed to commitinfo. Check out the following at cvshome.org for more details: http://www.cvshome.org/cyclic/cvs/dev-commitinfo.txt http://www.cvshome.org/dev/patches/commitinfo These both seem to be pointers to the same patch, but I haven't confirmed this. This patch will require changes to all your commitinfo scripts. *** Chris CameronOpen Telecommunications NZ Ltd Senior Solution Architect IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Visually Viewing Branches and Tags
On Wednesday, October 25, 2000 9:05 AM, Matthew Hahn [SMTP:[EMAIL PROTECTED]] wrote: Hello, Does anyone know of a tool or program that parses through an RCS file or even through a CVS repository and outputs a graphical (ASCII graphics is plenty graphic) tree-like structure of CVS branches and tags. Thanks. WinCVS and tkCVS both give this functionality on a per file basis, but only for checked out files. I'm not sure about jCVS as its a while since I looked at it. *** Chris CameronOpen Telecommunications NZ Ltd Senior Solution Architect [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
On Tuesday, August 08, 2000 6:14 PM, Justin Wells [SMTP:[EMAIL PROTECTED]] wrote: On Mon, Aug 07, 2000 at 02:11:13PM -0400, Greg A. Woods wrote: The *ONLY* secure way to use cvspserver is to rip out the current crap in the implementation that requires it to run as root and then to run it only as a non-privileged unique user-id which is given permission to read (and only read, i.e. it must be through group ownership) the CVSROOT/passwd file. So, if I do that, how do I get access control lists? Currently the only reason why I have to run pserver as root is so that I can hand out write access to my repository on a module by module basis. Core developers get to write to every module, but some developers are only permitted to write to one or two modules. I do this by putting people into different unix groups. If there is some other way I can do this, without having to rely on unix groups, then I don't have to run pserver as root--and that *would* be a big improvement. We use a commitinfo script to control who has commit priviledges to which parts of the repository. Our pserver runs as a special user (under inetd) with virtually no permissions except the ability to run cvs. *** Chris CameronOpen Telecommunications NZ Ltd Senior Solution Architect [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: CVS pids and the pids of its kids
On Thursday, August 03, 2000 11:57 AM, Laird Nelson [SMTP:[EMAIL PROTECTED]] wrote: TC wrote: He is probably tring to do some stuff with the commit loginfo scripts they hide in $TMPDIR/cvs-serv[pid] (server.c) if script he is in is calling out to get the parent process id he's not going to find the right cvs-serv[pid] dir with the contant he is expecting ... We have a winner. So is it then true in general (I am almost 100% sure that it is) that in between the commitinfo/verifymsg scripts getting executed and the loginfo script getting executed some other program in the system could come along and grab a PID, thus making the delta between the loginfo ppid and the commitinfo ppid be greater than 3? That is, the fact that I'm seeing nothing grabbing a pid inbetween the fork and exec calls doesn't mean that something COULDN'T grab a PID at that point. SO I really shouldn't rely on the delta being 3 at all, should I. I think this behaviour would depend on the load on the system. If your server is not being used as a multi user system and is lightly loaded, you would probably see this behaviour. On a heavily loaded system, anything is possible! Then again, if this is Linux, I don't know how similar to the commercial flavours of Unix it is in this regard. *** Chris CameronOpen Telecommunications NZ Ltd Senior Solution Architect [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: Checking branch for commit
On Friday, July 28, 2000 9:45 PM, Marc Poinot [SMTP:[EMAIL PROTECTED]] wrote: I have to check the commited branch, but the commitinfo actually gives nothing else but the file name. The loginfo has more infos, but it cannot make the commit fail. Thus, I have modified the src/commit.c file with these three lines: Sorry if this is late, but there was a patch posted at one time to pass version information to commitinfo. This would allow you to determine that the commit was occuring on the branch. I can't find or remember the patch :(! *** Chris CameronOpen Telecommunications NZ Ltd Senior Solution Architect [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: CVSROOT/passwd enhancements
On Wednesday, May 24, 2000 7:40 AM, Larry Jones [SMTP:[EMAIL PROTECTED]] wrote: I'm considering making some enhancements to the CVSROOT/passwd file format and I'd like people's opinions: First, I'd like to interpret "*" in the password field as "the system password for this user". That would allow people who are not concerned with network security to use system passwords along with user mapping. For example, one could have a CVSROOT/passwd that looked like: john:*:cvsadmin lisa:*:cvsadmin bill:*:cvsuser anne:*:cvsuser instead of having to give everyone separate CVS passwords or copy their system passwords into CVSROOT/passwd and then having to worry about keeping them in sync. Second, I'd like to interpret "*" in the username field as "any system user". That would allow even more simplification -- for example: *:*:cvsuser could be used to allow any system user to run CVS; or *:asdfghjklqwer:nobody could be used to allow anyone who knows the password to run CVS. An interesting side-effect of these changes is that the SystemAuth config option would no longer be needed: *:* is equivalent to SystemAuth=yes, and *:x (or any other impossible password) is equivalent to SystemAuth=no. This has the added advantage of keeping all the password-related stuff in one place. We went to the password file because cvs running as any user except root couldn't read the shadow file to verify passwords. This would not change the logic of your changes, but it could reduce the applicability. ******* Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: Keyword substitution of tags?
On Tuesday, May 23, 2000 2:44 AM, Keith Refson [SMTP:[EMAIL PROTECTED]] wrote: I'm sure this must be a common question, but it doesn't seem to appear in the cvs FAQ. How can I (semi-?) automatically maintain a text string identifying the project release version number? One way which occurred to me would be to substitute the text of the release tag, but there doesn't appear to be a keyword to do this --(only the RCS ID which isn't what I want at all). How about the $Name:$ keyword? It expands to the tag, WHEN the tag is checked out. *** Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: Emptydir
On Friday, May 12, 2000 8:36 AM, Nestor Amaya [SMTP:[EMAIL PROTECTED]] wrote: You should be careful when adding files/dirs, as it has happened to me that the files got placed in "Emptydir" instead of where I expected. For some reason, if a module defined as dir2 dir1/dir2 is defined, and then I isssue the command "cvs co dir2/dir3", for some reason, "dir2/CVS/Repository" points to Emptydir, and not dir1/dir2 as I would expect. Beware. I posted a patch a while ago to prevent this happening. I believe that this patch has since been incorporated into the latest CVS build. ******* Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: Selection of branches for commit
On Tuesday, May 09, 2000 12:46 PM, Wade Stebbings [SMTP:[EMAIL PROTECTED]] wrote: Thank you! I swore I saw this done before with stock CVS in a previous life. By inspection of your perl code, it tells me the CVS/Entries file gets copied to the temporary directory on the server side for a given request, and subsequently available for the commitinfo script to read. This is exactly the bit of information that is needed in order to do this. To be sure I understood this, I looked in the CVS sources and found the server.c server_write_entries() function, and there it was. And I had already gone and reluctantly modified CVS to do what I thought it was lacking (instead the lacking was my failing memory). It also gave me an appreciation and a hint for how CVS was once split into its client and server halves. I hadn't looked at server.c, I was working in commit.c, tag.c, rtag.c, etc. Like Marc Poinot, we also have the desire to create a branch control mechanism. Our system is written in Perl and back-ended by a MySQL database. It is not completely done, and now I need to retro fit some changes in order to use stock CVS. A little extra work, but I'm much happier to follow stock CVS. There was a patch posted a while ago to change the information passed to commitinfo scripts to include the ORIGINAL branch number. This may solve your problem and may be something for a future version of CVS. *** Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: multiple repositories.
On Thursday, April 13, 2000 6:03 AM, Gary Pinkham [SMTP:[EMAIL PROTECTED]] wrote: I put #!/bin/sh /bin/cvs cvs --allow-root=/usr/local/cvs1 --allow-root=/usr/local/cvs2 --allow-root=/usr/local/cvs3 --allow-root=/usr/local/cvs4 pserver Don't pass cvs as a parameter to cvs and it should work for you. The line should be: /bin/cvs --allow-root=/usr/local/cvs1 --allow-root=/usr/local/cvs2 --allow-root=/usr/local/cvs3 --allow-root=/usr/local/cvs4 pserver into cvs.sh then I added cvsserve stream tcp nowait root /etc/inet/cvs.sh into inetd.conf... when I try to do a cvs login I get the following "cvs [login aborted]: unrecognized auth response from ape: CVS commands are:" If I execute the cvs.sh from the command prompt I get the "CVS commands are: blah blah blah"..SO I was figuring that I needed to code the line different in the script then I would in the inetd.conf file... I have no idea GaRy Dave Sherohman wrote: On Wed, Apr 12, 2000 at 11:20:50AM -0400, Gary Pinkham wrote: Could someone point me in the right direction for setting up a shell script for inetd to call since I have 4 repositories and can only fit three in inetd... I basically did /bin/cvs cvs --allow-root/usr/local/cvsroot (blah blah blah) pserver... But this does not work... So I'm guessing that I'm supposed to have some other command Your problem is simply that inetd doesn't like commands longer than 30 characters. All you need to do is put your '/bin/cvs cvs --allow-root/usr/local/cvsroot (blah blah blah)' command into a shell script and call the script from inetd. ******* Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: Trouble making a connection to a CVS server
On Wednesday, April 12, 2000 12:54 AM, Jay Corrales [SMTP:[EMAIL PROTECTED]] wrote: Hello, I am having no luck connecting the cvs client to the server. The cvs server gets kicked off by the internet daemon on our SunOS 5.7(=? Solaris 2.7) while servicing port 2401 requests. I check the process list and see the following line: solaris2% ps -efl | grep cvs 8 S root 16263 155 0 41 20?278? 05:24:59 ? 0:00 cvs -td /usr/local/cvsroot --allow--root=/usr/local/cvsroot pserver However the client never passes the authentication state. For example if I try: telnet solaris2 2401 After connecting, I send any text (for example "foo" followed by return). CVS does not respond at all; instead the telnet session hangs without feedback. solaris2% cvs -version Concurrent Versions System (CVS) 1.10 `Halibut' (client/server) ... solaris2% cat config # Set this to "no" if pserver shouldn't check system users/passwords #SystemAuth=no # Set `PreservePermissions' to `yes' to save file status information # in the repository. #PreservePermissions=no # Set `TopLevelAdmin' to `yes' to create a CVS directory at the top # level of the new working directory when using the `cvs checkout' # command. #TopLevelAdmin=no solaris2% Are you running the pserver as root or another user (in the inetd.conf file)? Solaris uses a shadow file to store passwords and only root has read access (by default) to this file. So if pserver is running as root and SystemAuth=yes (the default) everything works fine. But if pserver is running as another user, it cannot read the shadow file and therefore cannot authenticate the password. In this case, you have to create a password file in CVSROOT. ******* Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: Trouble making a connection to a CVS server
On Wednesday, April 12, 2000 11:01 AM, Jay Corrales [SMTP:[EMAIL PROTECTED]] wrote: The internet daemon does run the process as root. Also I tried to connect with both SystemAuth set to "yes" and "no" within the CVSROOT/config file. Thanks, -Jay What is the line in your inetd.conf? -Original Message- From: Chris Cameron [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 11, 2000 1:33 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Trouble making a connection to a CVS server On Wednesday, April 12, 2000 12:54 AM, Jay Corrales [SMTP:[EMAIL PROTECTED]] wrote: Hello, I am having no luck connecting the cvs client to the server. The cvs server gets kicked off by the internet daemon on our SunOS 5.7(=? Solaris 2.7) while servicing port 2401 requests. I check the process list and see the following line: solaris2% ps -efl | grep cvs 8 S root 16263 155 0 41 20?278? 05:24:59 ? 0:00 cvs -td /usr/local/cvsroot --allow--root=/usr/local/cvsroot pserver However the client never passes the authentication state. For example if I try: telnet solaris2 2401 After connecting, I send any text (for example "foo" followed by return). CVS does not respond at all; instead the telnet session hangs without feedback. solaris2% cvs -version Concurrent Versions System (CVS) 1.10 `Halibut' (client/server) ... solaris2% cat config # Set this to "no" if pserver shouldn't check system users/passwords #SystemAuth=no # Set `PreservePermissions' to `yes' to save file status information # in the repository. #PreservePermissions=no # Set `TopLevelAdmin' to `yes' to create a CVS directory at the top # level of the new working directory when using the `cvs checkout' # command. #TopLevelAdmin=no solaris2% Are you running the pserver as root or another user (in the inetd.conf file)? Solaris uses a shadow file to store passwords and only root has read access (by default) to this file. So if pserver is running as root and SystemAuth=yes (the default) everything works fine. But if pserver is running as another user, it cannot read the shadow file and therefore cannot authenticate the password. In this case, you have to create a password file in CVSROOT. ******* Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: CVS Question
On Wednesday, March 22, 2000 6:40 AM, Russell A Hoffman [SMTP:[EMAIL PROTECTED]] wrote: Hi, I was wondering if anyone could help me out with a CVS question I had? Well, what I'm trying to do is manage a fairly large website using CVS. I've managed to successfully import and test checking it out (can you tell I'm a newbie? :), but now I'm wondering what to do to keep the original website files up to date. For instance, the repository is in /cvsroot/html, and the original files are in /home/httpd/html, and I'm wondering how to keep the original files "in-sync" with the cvs (updated) version? I'm probably not wording it right, or not explaining it correctly, but I'm just hoping someone out there will be able to decipher what I'm trying to say, and let me know if/how this can be done ;) This is described by cederqvist in the loginfo section. I posted the excerpt from our loginfo file that does this job last week (from memory). ******* Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: CVS server access over the Internet
On Monday, March 20, 2000 3:08 PM, Keogh, Greg, HiServ/AU [SMTP:[EMAIL PROTECTED]] wrote: Hello from Melbourne Australia, Our new United Kingdom development group using WinCVS 1.0.6 is getting the login error 'Unknown host techssna' (that's the name of our Solaris server down here). We know they can access techssna via telnet and ping, so we're puzzled where the 'Unknown host' message is coming from. I don't want to bother this group with our networking problems ... Here's my real question: We know it's fine to use CVS on a LAN, as we do in our Melbourne office, but is it valid to try and access a CVS server across the Internet? I just want to check that we're not trying to do something conceptually wrong or impossible with CVS. I'm not a networking person, but I was under the impression that there would be no distinction between using CVS over a LAN or over the Internet, so long as the routing and security is setup correctly or course. Yes it is technically possible, we are currently establishing the same via a WAN, rather than internet. I'd suggest that it is your network that needs to be tidied up. I don't know what access mechanism you are using, but whatever it is, you need to make sure that it is open at your fire walls. *** Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: Unix to Dos filtering
On Friday, March 10, 2000 11:33 AM, Karen Baldwin [SMTP:[EMAIL PROTECTED]] wrote: Hi; just discovered this group. Help! I have a question very similar to that first asked within this thread. We've been using CVS exclusively on Solaris/Unix until now. We are now porting to NT. We intend to have a single source repository on a Solaris machine, which will be accessed by users on BOTH the NT and Solaris nodes. We'll be using Samba as the cross-platform file access mechanism. Until now I speculated that maybe the proper thing to do is to employ the cvswrappers file. specifically, using the -f option to invoke 'unix2dos' when a checkout is performed from the NT side, and to invoke 'dos2unix' when a checkin is performed from the NT side. When a checkin/checkout is done from the Unix side, we'd (somehow?) preclude those utilities from being run. Is this unrealistic? Is this a naive approach, doomed to failure? Is there a preferred approach that's been found to work by others who've 'been there' already? I think the historical consensus for this scenario is to use CVS in a client/server mode and let the client sort out line terminations. We use WinCVS as a Windows/NT front end and CVS in pserver mode on our Unix server. *** Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: How do I do cvs rtag for an ampersand module?
On Tuesday, March 07, 2000 12:24 PM, Karr, David [SMTP:[EMAIL PROTECTED]] wrote: I work with two different applications in CVS. One has a module specification that uses aliases to specify several subsystems. The other uses the "ampersand" rule. So when I do a checkout of the first system, that just creates subdirectories in the current directory to represent the various subsystems. When I do a checkout of the second system, that creates a top-level directory in the current directory, and creates subdirectories in that directory. For example purposes, call the first system "foo" and the second system "bar". There are subdirectories "foo1", "foo2", "foo3", "bar1", "bar2", and "bar3". The modules file entries for these might look like this: --- # Foo system foo1 -d foo1 some/complex/path foo2 -d foo2 some/other/complex/path foo3 -d foo3 some/where/else foo -a foo1 foo2 foo3 # Bar system bar1 -d bar1 some/miscellaneous/place bar2 -d bar2 some/other/strange/place bar3 -d bar3 some/place/else bar bar1 bar2 bar3 We've been using "cvs rtag" to make version tags for the first system, and I'm just starting to set up version tags for the second system. For the first system, we do "cvs rtag FOOKIT_01 foo". This works fine. For the second system, I tried " cvs rtag BARKIT_01 bar", and it gave me the following: cvs server: cannot make path to bar: Permission denied cvs server: cannot chdir to bar: No such file or directory What am I doing wrong, or what information do I need to track this down? In my experience you can't use rtag with ampersand modules as rtag 'acts directly on the repository' and there is no direct mapping that rtag can interpret. We solve this problem by checking out the head of bar and using tag on that. *** Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: new guy - hopefully easy questions
On Friday, March 03, 2000 12:41 PM, Michael R. Salazar [SMTP:[EMAIL PROTECTED]] wrote: Dear CVS listers, I'm a new user of CVS and I have, what I hope, are easy questions. I have a rather large code that multiple users will be editing. Each user will need the entire code for their improvements. So, branching seems to make sense in this situation. My ideas are: 1.Have a centralized repository where each user can branch out of and create their own repository with the whole code in it. Why do you want to do this? Why couldn't each user (if this is really necessary) have their own branch inside the one repository? Or is your definition of repository different to everyone elses, and this is what you are trying to do. 2.After the individuals make their improvements, then they may update the centralized repository. If each user has a branch, then they could merge the changes into the main trunk. I don't want a repository that each user has access to and is being updated often by the individual users, because each user needs the whole code and this senario seems that it would create alot more problems with users attempting to commit their improvements while other users have checkout earlier editions. Thus, if each user had their own repository and checkout and commited as necessary, this wouldn't be a problem. The problem will come when the users attempt to update the centralized repository, but this won't be that often. Does this make sense? If so, please help with the following: How will you resolve the issue of one person's changes altering the behaviour of common material so that everyone else should get the updated files? By using the concurrent mode of operation (without everyone on separate branches), using good communicaiton between workers (e.g. cvs watch) and frequent updates, you can get everyone to work together as a team on one repository. 1.What are the commands for creating branches out of a repository? You create a branch with a 'tag -b' command and then check it out with a 'co -r' command 2.How does one update a repository with another repository? Can't do this, but I suspect it is not what you really want to do. As you all can probably tell by these questons, don't assume too much in your answers. If possible, please provide the necessary commands and a brief description. The architecture on which I am running is SGI Irix 6.5. I'm using CVS version 1.9 What is the problem you are trying to solve? It seems that you have decided 'how to skin the cat' and now want some assistance. If you describe the problem you have, people may be able to offer alternative means of 'skinning the cat' which fit in with the way CVS works. As other people have suggested, upgrade to 1.10.8 *** Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: running CVS as root or not?
On Tuesday, February 29, 2000 7:49 PM, [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] wrote: Hi! I am using CVS 1.10 with pserver on AIX 4.3 The system administrator at my site prefers not to run cvs as root. In /etc/inetd.conf we got "cvspserver stream tcp nowait cvsowner /usr/local/bin/cvs cvs --allow-root=/usr/local/newrepos pserver" note the use of "cvsowner" instead of "root". What are the pro/cons of running CVS as root/a user account? The repository is owned by the "cvsowner" user. From my experience of doing the same thing there are three things to be aware of: 1. if you are not running as root, the system passwords cannot be accessed (if they are in a shadow file and I assume from what I have seen here that AIX is similar). This means that you have to create a CVSROOT/passwd file which should NOT be under CVS control. 2. once you use a CVSROOT/passwd file, the required format changes between 1.10 and 1.10.7 (I'm not sure which version changed the format). The format you will need to use is: user:password:cvsowner 3. once you are running as cvsowner, any loginfo, commitinfo or taginfo scripts may need to be modified to take the $USER cvs variable as the 'id' and 'whoami' commands will return cvsowner. Those are the only issues I am aware of. We also set the repository permissions to 2755. ******* Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: Configuring WinCVS
On Thursday, February 17, 2000 5:42 PM, Animesh Das [SMTP:[EMAIL PROTECTED]] wrote: Hello all, We have a single server stores the CVS items for our project(A) as well as another(B). Project B is already using WinCVS as the front end. We too decided to use WinCVS for project A. But we found some problem. In the server's /etc/inetd.conf file, a line (containing settings) is added to make project B settings in the server. When we try to add another line for project A, it gives problem. Is it so that, only one project can use WinCVS from one server? You obviously aren't familiar with Unix/Linux. Project A and Project B settings must be on the same line in inetd.conf. You need to specify multiple --allow-root settings in the entry, as described in Cederqvist. *** Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: cvsignore problem
On Friday, February 18, 2000 5:30 AM, Jiann-Ming Su [SMTP:[EMAIL PROTECTED]] wrote: I'm getting the following message when I try to checkout: cvs server: cannot open /root/.cvsignore: Permission denied cvs [server aborted]: can't chdir(/root): Permission denied The obvious question is why is it searching in /root? I do not have any environment variables for CVS set to /root. Sorry if this is FAQ, but I couldn't find it in the FAQ or the web site. Thanks for any help. This seems to be a common question lately. You are apparently using Linux and this OS sets the $HOME environment variable for processes spawned by inetd. If you search the archives for this list you should find some suggestions as to how to deal with the problem. Should this question be added to the Faq-o-matic and/or manuals? *** Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: Why does CVS treat removed files so specially?
On Thursday, February 17, 2000 11:43 AM, |}avid (opeland [SMTP:[EMAIL PROTECTED]] wrote: Why does CVS treat removed files in such a special way? To be more specific, consider the following example: ls CVS/ blah.c main.c blah.h cvs tag -F some_tag T blah.c T main.c T blah.h [ make changes in blah.c ] [ make changes in blah.h ] cvs remove -f main.c cvs commit -m '' 1.2 --- blah.c 1.2 --- main.c 1.2 --- blah.h cvs tag -F some_tag T blah.c T blah.h Note that main.c DOES NOT get tagged. Even if you 'cvs tag -F some_tag main.c' it does not get tagged. You can ONLY tag the new (dead) revision, via 'cvs tag -r 1.2 main.c', which is cumbersome, because not all files in a source tree are on the same revision. You can also do 'cvs tag -r HEAD main.c', but this doesn't have the correct behaviour on a branch. Sorry, I'm a bit confused why do you want the removed file tagged? It no longer exists! It isn't part of some_tag because you removed it. The point of tags is to be able to recreate your source tree as at a particular point in time. If you remove a file it is no longer part of the tree, therefore you don't need it. If you still need it don't remove it and all will work correctly. Internally CVS will place the file into the Attic. That way any tags which included the file can still be checked out, but this file is no longer a default file for that directory. also, doing commands like 'cvs log' and 'cvs stat' (with no file arguments) do not produce output for removed files. It is removed, why should the log and stat still care about it? A diff with the previous tag will show that it is gone and the log message should record why it was removed, so a future developer can understand what happened. If you add main.c again in the future, the Attic version will be resurrected and all your revision history from before the rm will be restored. This makes it extremely difficult to do ANYTHING in batch mode with CVS and I can think of no explanation for it (other than convienience while coding CVS features/throwback to RCS). What types of things in batch mode? Can anyone think of a reason why CVS behaves this way and if others think this actually a bug? AFAIK that is the way it is designed to work. I haven't seen any other complaints. It is quite logical to me! At the very least there should be an option to cvs that says "Run the command on removed/dead revisions" That is a possible option, but why? ******* Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: Why does CVS treat removed files so specially?
On Thursday, February 17, 2000 2:49 PM, |}avid (opeland [SMTP:[EMAIL PROTECTED]] wrote: Essentially, I am version controlling a website. As such files, assets, etc. get added and removed. On our live site, all files are checked out with the tag 'live'. So you are using a constant 'sliding' tag to mark the stable point of the web site. Have you tried the following sequence remove the live tag remove dead files add the live tag Or do you have to have a constant tag? On our intranet we use the main trunk as the stable version. We make changes on a branch and merge them to the trunk when they are stable. The 'auto update' script in loginfo then does a 'cvs update' in our intranet directory to 'activate' the changes. In short, I think that a reconsideration of your needs may give you a model which fits in with CVS's functionality (and give you a better process, e.g. how do you know what version was the LAST stable version?) *** Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: Enhancement suggestion
On Wednesday, February 16, 2000 2:21 AM, Jan Serak [SMTP:[EMAIL PROTECTED]] wrote: But I imagine a new kflag (not compatible to RCS but useful for files that cannot be changed in length by CVS), e. g. -kvp (to express our goal to refuse migration from CVS to PVCS ;-) Checking in and out of file with -kvp flag would: * NOT expand $Keyword$ * expanding $Keyword: Value $ count length of the old Value and cut the new one (if longer than) to the length or right pad it with spaces (if shorter than). Aren't these exclusive? Or do you mean If Keyword is NOT expanded, do not expand But if Keyword is expanded keep the same string length. Are you sure the tool only checks for length and not content as well? There is the user responsibility to reserve enough space for possible growth of the value of keyword. And here are the base questions: should I do thing described above? Can this be useful for anybody else? Is there an interest to this new functionality? Other comments to my idea? The -ko and -kb do this type of thing with slight differences. -ko will generate the existing keyword expansion and not re-expand -kb will work as -ko and prevent line feed conversion. *** Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
RE: CVS File Locking
On Wednesday, February 16, 2000 7:52 AM, Greg A. Woods
[SMTP:[EMAIL PROTECTED]] wrote:
[ On Tuesday, February 15, 2000 at 09:56:42 (-0600), David Thornley
wrote: ]
Subject: Re: CVS File Locking
I don't believe it is designed to do that. It's freely available
open-source software, and I've never met anybody in the community
that wanted to force somebody to do development in one specific
way before. You may want it to do that, but that's a different
statement.
The fact that CVS was indeed designed to force concurrent development
been discussed in detail on this list and is clearly evident both in the
original CVS-I scripts and documentation, as well as in Brian Berliner's
paper. You can believe what you will, but those are the facts.
Besides, there are things that cannot be developed concurrently,
since they are unmergeable, for good reasons or bad.
CVS is not designed to work with un-mergable files. Period.
If you want to add more merging support to CVS (i.e. to diff3) for
different types of files then that's an entirely different story than
advocating locks. The former is entirely within the design goals of
CVS but the latter is entirely without.
These have
to have some form of lock. (From experience, I think "cvs watch on/
cvs edit" is adequate locking, and hard locks would be no better
in practice. Others have different opinions.) I assume it is your
position that CVS should not be used in such cases.
No, they do not. For those very few files for which a merging algorithm
cannot be developed "cvs edit" and friends are far *MORE* than
sufficient for *ALL* purposes CVS should ever be put to use for. Even
they are over-kill in my opinion.
I've been trying to stay out of this debate, but haven't you (Greg) just
jumped on someone who argued your point of view?
David said "From experience, I think "cvs watch on/cvs edit" is adequate
locking, and hard locks would be no better in practice. Others have
different opinions"
Then Greg said "No, they do not" and then went on to agree with David ("For
those very few files for which a merging algorithm cannot be developed "cvs
edit" and friends are far *MORE* than sufficient for *ALL* purposes CVS
should ever be put to use for"). Aren't you in VIOLENT agreement here?
It may not be possible, but can people climb down from their lofty peaks
and talk rationally about this. I'm trying to follow everything, but the
flame-war seems to be overtaking any rational debate.
***
Chris CameronOpen Telecommunications NZ Ltd
Software Development Team Leader
[EMAIL PROTECTED] P.O.Box 10-388
+64 4 495 8403 (DDI) The Terrace
fax: +64 4 495 8419 Wellington
cell: +64 21 650 680New Zealand
Life, don't talk to me about life (Marvin - HHGTTG)
