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?
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 determin
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 dat
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
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: 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: 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 sho
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
Removal of tagged files
We've had the experience of cvs allowing files to be removed from a non-branch tag! You can't modify files on a non-branch tag, but you can remove! Has anyone else experienced this, or submitted a patch? IMHO it doesn't seem to be logical to prevent modify, but not remove (after all it is a special kind of file modification!). ******* 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: 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 reposit
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: "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
Recursive update
I haven't tested this, but can anyone tell me the expected behaviour of cvs update -dlP i.e. create missing files and directories; don't recurse; prune old files and directories Does the 'don't recurse' command stop recursion into newly created directories? Put another way, will this command correctly create a new directory structure and its files? I'm trying to improve the performance of an automatic update script, which currently recurses through a large (and growing) directory structure, so the commit takes a looong time! ******* 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: problem with "co -d xx -n" : bug or feature?
If anyone is still interested, I located the information in our CVS source.
This diff is against 1.10, but it is only a couple of lines to change. It
is a patch to allow & and -d to be used in one line in the modules file
(like Cederqvist says you can!). We downloaded the original patch from the
CVS web page
[ccameron@helios:/home/users/ccameron/CVS_src/src] cvs diff -r1.2 -r1.1
modules.c
Index: modules.c
===
RCS file: /CVS/CVS_src/src/modules.c,v
retrieving revision 1.2
retrieving revision 1.1
diff -u -r1.2 -r1.1
--- modules.c 1999/03/26 05:14:21 1.2
+++ modules.c 1999/03/26 04:58:29 1.1
@@ -376,14 +376,12 @@
*/
char *dir;
- /*fix for combining & with cvs -d options*/
- do_special_only:
/* 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 out;
- dir = where ? where : (mwhere ? mwhere : mname);
+ dir = where ? where : mname;
/* XXX - think about making null repositories at each dir here
instead of just at the bottom */
make_directories (dir);
@@ -505,11 +503,6 @@
modargv += optind;
if (modargc == 0)
{
-/* NHR if there are special options, then handle them
- with the code that handles the case when there are nothing
- but special options */
-if (spec_opt !=3D NULL) goto do_special_only;
-
error (0, 0, "modules file missing directory for module %s",
mname);
++err;
goto do_module_return;
[ccameron@helios:/home/users/ccameron/CVS_src/src]
On Saturday, February 03, 2001 12:39 AM, Chris Cameron
[SMTP:[EMAIL PROTECTED]] wrote:
> 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]
> >
> > __
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.
>
> > -Ursprüngliche 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 Sy
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
Import and commit
Does anyone know of any patches which may be available to force an import to do the precommit checks as specified in commitinfo? *** 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: 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: "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: loginfo question
On Friday, June 09, 2000 9:45 AM, Olaf Meding [SMTP:[EMAIL PROTECTED]] wrote: > Can someone explain why CVS does not send an email notification to both john > and olaf? In either case, I commited a file in test/dir1 (see below). > > Is there a way to fix this? I would like one person to get notifications > for all sub-directories and the other only for a specific sub-directory. > > Below are lines from my loginfo file. > > * case 1 * > ^test* bla "%s" john > ^test/dir1* bla "%s" olaf # why does olaf not get and email? > > * case 2 * > ^test/dir1* bla "%s" olaf > ^test* bla "%s" john # why does john not get an email? > The first match is used in all the info files (Cederqvist section C.3). We use a loginfo script to control who gets e-mails (you can add on extra parameters to be passed to your script). *** 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 access using SSH
On Thursday, June 08, 2000 4:59 AM, Sheldon Samuels [SMTP:[EMAIL PROTECTED]] wrote: > Well, I now get a different set of errors, although I'm not sure if this is from SSH >or CVS. Here is what I've done. > > 1) I created a batch file (sshx.bat) and placed the proper SSH command inside of >the batch. The SSH command is as follows: > > ssh -v projectname.sourceforge.net -l username > > 2) I then set my CVS_RSH=sshx.bat > > 3) Now when I run "CVS UPD" I get the following response: > > SSH Version 1.2.14 [winnt-4.0-x86], protocol version 1.4. > Standard version. Does not use RSAREF. > Pseudo-terminal will not be allocated because stdin is not a terminal. > ssh_connect: getuid 0 geteuid 0 anon 0 > Connecting to panjasource.sourceforge.net [198.186.203.44] port 22. > Connection established. > Remote protocol version 1.5, remote software version 1.2.27 > Waiting for server public key. > Received server public key (768 bits) and host key (1024 bits). > Host 'panjasource.sourceforge.net' is known and matches the host key. > Initializing random; seed file c:\home/.ssh/random_seed > Encryption type: idea > Sent encrypted session key. > Received encrypted confirmation. > Trying RSA authentication with key 'smskeys' > Received RSA challenge from server. > Sending response to host key RSA challenge. > Remote: RSA authentication accepted. > RSA authentication accepted by server. > Requesting shell. > Entering interactive session. > -bash: Root: command not found > -bash: Valid-responses: command not found > -bash: valid-requests: command not found > This may be too late and you may have solved the problem, but aren't the last three commands part of the pserver protocol? *** 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: cvswrappers
On Saturday, May 27, 2000 9:09 AM, Derek Scherger [SMTP:[EMAIL PROTECTED]] wrote: > I'm just looking into using cvswrappers to do some simple cleanups on > some of our files on checkin (using the -t option) but there's a line in > the html documentation that makes me think I'm SOL: > > The cvswrappers file > > > ... The `-t'/`-f' feature does not work with > client/server CVS. ... > > Say it ain't so! This would be great for doing things like stripping > ^M's introduced by silly Windoze editors, running indent to format > source, etc. except that we're using client server cvs. > > Is this documentation correct? Is there any way to do something similar > to the filtering available with cvswrappers that will work in client > server mode? > > -- If you REALLY want to do this, you could use the commitinfo file to trigger a script or program to do this. The *info files work fine in c/s mode, except for the absence of user interaction. *** 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: 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: Displaying the tagged versions
On Tuesday, May 09, 2000 1:17 PM, Malcolm Fernandes [SMTP:[EMAIL PROTECTED]] wrote: > What I'm trying to do is set this up as a one-step process without having to run > additional steps to query the repository. Since the repository is getting tagged > at the time, it should know the revisions of the files that it is tagging, and > that information could be easily displayed if an option was specified. > This information is available to the taginfo scripts. We log all tagging to a log file that can be reviewed later. ******* 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: pserver & solaris hanging problem
On Saturday, April 29, 2000 12:26 PM, Anya Sophe Behn [SMTP:[EMAIL PROTECTED]] wrote: > > pserver 1.10 & Solaris 5.7 problem. > > inetd.conf: > cvspserver stream tcp nowait root /usr/local/bin/cvs > > cvs -t --allow-root=/usr/local/cvsroot pserver > > /etc/services: > cvspserver 2401/tcp > > CVSROOT/passwd: has valid crypted passwd & user > > Behavior: > telnet servername 2401 > hangs. > cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/cvsroot login > hangs. > > If I change the inetd.conf so cvs has no options, then > cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/cvsroot login > says there is no cvsroot defined. > What do you mean by 'no options'? You should always have the --allow-root option in pserver mode! We are running pserver on Solaris (2.6/5.6) and have been for the last couple of years! *** 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: Linking CVS repositories to other CVS repositories
On Friday, April 14, 2000 8:10 AM, William K. Gibson [SMTP:[EMAIL PROTECTED]] wrote: > > I need to know the best way to create links in CVS repositories. > > Specifically, can I construct links such that a module can be linked within > another module and be checked out as a subdirectory. > > Here is an example of my situation. Say I have two modules, A and B. Both > modules reside in their own seperate repositories in the CVSROOT. I have > another module C containing a subdirectory C'. Within C' is source code that > I wish to share amongst A and B. Can I simply create a link to C' in A and B > and expect C' to be checked out as a subdirectory of A or B? > > If so, where do I create the link? Do I checkout A, and create a link to > $CVSROOT/C/C' then add and commit the link? Will this work? Am I off my nut > for wanting to do this? > We use the '&' module feature to do this type of thing, along with the -d option in the modules file. If you do something like _moduleA-d srcA ModuleA _moduleB-d srcB ModuleB _moduleC-d srcC ModuleC moduleA -d moduleA &_moduleC &_moduleA moduleB -d moduleB &_moduleC &_moduleB a cvs co moduleA will give a directory structure moduleA/srcA moduleA/srcC a cvs co moduleB will give moduleB/srcB moduleB/srcC You cannot checkout two modules into one directory, and you can't create an empty directory (e.g. srcC) and then checkout a & module that inserts a file into the directory, you need to do things the other way around. If you had another line _moduleAmakemakefiles/moduleA/makefile you would have to make the moduleA definition moduleA -d moduleA &_moduleAmake &_moduleC &_moduleA Any other order and the moduleA repository will be set as 'Emptydir' and it won't work correctly. *** 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 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: Access to CVSROOT/passwd mapped username
On Wednesday, April 12, 2000 5:24 AM, Rodent of Unusual Size
[SMTP:[EMAIL PROTECTED]] wrote:
> Rodent of Unusual Size wrote:
> >
> > As I understand it, the USER variable is set to the username of
> > the server-local user actually accessing the repository. In the
> > case of a pserver-accessed repository, with usernames mapped
> > through the CVSROOT/passwd file mechanism, this will typically
> > be the value of the third field in the matching entry in the
> > CVSROOT/passwd file.
> >
> > So.. is there any way to get the *remote* username? The one that
> > was mapped to the local one? The one that matches the *first* field
> > in that entry?
>
> A little experimentation reveals something (I find) confusing.
> CVSROOT/loginfo contains a line like this:
>
> DEFAULT $CVSROOT/CVSROOT/foo $USER %s
>
> The Perl CVSROOT/foo script, however, shows different values for
> $ARGV[0] (the $USER above) and $ENV{"USER"} (the actual environment).
> The former is the remote (client) username I want, whilst the
> latter is the local (server) username.
>
> It looks as though whatever does the expansion of $USER is using
> an internal table, not the environment, since the admin-file
> expansion of $USER differs from the value in the environment table.
>
> I haven't yet gone to the sources to track this down; it's with CVS
> 1.10.2. Can anyone else confirm/deny the behaviour I'm seeing?
> Am I nuts, or missing something obvious? Or is there really an
> overloading of the variable named USER?
There is indeed overloading of the USER variable. From memory this is
documented in Cederqvist, but I can't remember where. This caught me for a
while as well (I went as far as creating a patch to fix this behaviour)!
***
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: 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: Writing shell scripts that use CVS / Automatic checkout
On Wednesday, March 15, 2000 3:18 AM, Mikael Grave
[SMTP:[EMAIL PROTECTED]] wrote:
> Hello,
>
> I am currently writing a small Shell script that will log into my CVS
> respository and will issue a checkout. This script is intended to be
> called every 10mn by a crontab.
>
> Since "cvs login" does not have a command line option to pass the
> password, I was wondering if there is a simple trick to run "cvs login"
> automatically? I have tried things like:
>
> echo "x" | cvs login
>
> But it does not work (the password is not taken from the buffered stdin
> I guess).
>
You only need to login once. After that the password is stored in a
lightly encrypted format in your home directory. So if you do a manual
login, you shouldn't have to worry about it again.
> My original purpose was to perform an automatic checkout (in a test bed)
> every time someone was doing a commit. Doing this with "commitinfo" did
> not seem possible since "cvs commit" recursively commit all modified
> files, if 100 files are commited at once, I don't want commitinfo to
> launch 100 checkouts (maybe should I simply run one "update" per
> "committed" file?). So I decided to go for a crontab (not as good, user
> may have to wait 10mn to see their changes published in the test bed).
>
> Any help or trick are welcome. I guess my problem is quite common. Hope
> my questions are not too stupid :)
>
Well, the other way to do things, as described in cederqvist, is to use
loginfo, not commitinfo.
loginfo only runs after the commit succeeds and cederqvist gives an example
of how to use it for an automated checkout. In our loginfo file we have
the following line to do this (excuse any mailer wrapping, this should be
on one line):
WWW/* ($CVSROOT/CVSROOT/cvslog.sh ${USER} ALL %{};(cd /WWW ; sleep 5; echo
`pwd` Updated by ${USER}-`date` ; /usr/local/bin/cvs -nq update -d ;echo
- ; /usr/local/bin/cvs -q update -d ;echo
=====)>>$CVSROOT/CVSROOT/LOGS/WWW_update.log
2>&1 &)
***
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: Modules Question
On Thursday, March 09, 2000 4:54 AM, Chris Hirsch [SMTP:[EMAIL PROTECTED]] wrote: > Hey All... > > I'm trying to set up a modules file for my project and I'm confused. First > of all is there any place I can go to get real-world info, tips, tricks, > etc on setting up module files? > > My question is this. I have a project that I want to be able to check out > either in its whole or check out various sub-modules instead. > > Here is how its laid out (any other suggestions for this are more than > welcome): > > /src >/pages >/tsd >/src >/inc > /pages > /tsd > > My goal is if you check out a sub-module, say tsd then you will get a > simlar structure of /src/tsd and /src/inc/tsd but if you check out other > modules too it will fit nicely and just add it to the /src structure. Like > above. My problem is that for the life of me I can't figure out how to do > a modules file for this or if its even possible or feasable. Any > suggestions or recommendations you have would be GREATLY appriceated! > > BTW this is sort of what my modules file is looking like: > > Src -d src src/src > Inc -d inc src/inc > src &Src &Inc > > PagesSrc -d pages src/pages > PagesInc -d inc/pages src/inc/pages > pages &PagesSrc &PagesInc > > IOS &src &pages > We've found that the trick to doing this correctly is to include a -d on the ampersand modules, and include another level of indirection. So your modules would look something like: _src -d src src/src _inc -d inc src/inc _pages_src -d pages src/pages _pages_inc -d inc/pages src/inc/pages _tsd -d tsc src/tsc project -d project &_src &_inc &_tsd &_pages_src project_src -d project &_src project_inc -d project &_inc project_tsd -d project &_tsd project_pages -d project &_pages_src &_pages_inc Only modules without the _ at the start are publicly notified modules. This will give a checked out structure of project/src project/inc project/pages project/inc/pages BUT you must check out the project_pages AFTER you have checked out something into inc, otherwise CVS will record a Repository of Emptydir for inc and you will then not be able to check out files to inc! *** 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: Using CVS for a website
On Tuesday, February 29, 2000 4:39 AM, Ben Leibig [SMTP:[EMAIL PROTECTED]] wrote: > Which manual, can you point me to a URL? > > On Fri, 25 Feb 2000, Noel L Yap wrote: > > > There's an example of this in the manual. The gist is to use a loginfo script > > to do the checkout. Be sure to do the checkout in the background so the script > > doesn't deadlock. > > The one that comes with CVS! It is in the documentation directory as either postscript or texinfo. ******* 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: newbie question: help someone!
On Tuesday, February 29, 2000 4:14 AM, [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] wrote: > I keep getting the following error when I try to commit a file: > > cvs commit write_shared_memory.c > Warning: cannot open display > cvs [commit aborted]: Logfile verification failed > > Whats wrong? and how can I fix this? Someone has configured your repository with a loginfo script which is trying to open an X windows session somewhere and failing. I'd suggest you contact your repository administrator. If this is you, contact your predecessor and look in CVSROOT/loginfo or CVSROOT/commitinfo for some scripts to do some tricky things. ******* 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: Import revision number question
On Monday, February 28, 2000 3:20 AM, Henrik Wahlberg [SMTP:[EMAIL PROTECTED]] wrote: > If I use this command to initially check in a directory tree: > CVS import -d -m "V301 Import" HHO hw V301 > > All the files on checkout appear vith a revision number of 1.1.1.1 > > How do I get it to be 1.1, or in other words, not calling this for a branch on a nonexisting root? > The revision 1.1.1.1 is a special 'magic' version created as an artifact of your import. When you check out these files and commit, they will automatically be made revision 1.2. Normally in CVS you can ignore the internal revision numbers. *********** 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 Saturday, February 19, 2000 5:41 AM, Greg A. Woods [SMTP:[EMAIL PROTECTED]] wrote: > [ On Friday, February 18, 2000 at 17:58:35 (+1300), Chris Cameron wrote: ] > > Is this a bug? A tag -F will move an existing tag, maybe it should check > > in the Attic and remove the tag from any files which contain the tag? > > That's a good idea! I.e. if the tag exists (on the current branch?) in a > removed file (i.e. removed on the current branch), then the tag sould be > removed too if the tag would be moved to the head. That does mean not > removing the tag unless either '-f' was specified or a removed file was > explicitly specified on the command-line. > > This fix might even be a sufficient solution to Dave's problem too! > I'd like to propose that the behaviour be implemented only for a move or delete of a tag WHERE files are not specified (i.e. cvs tag -d or cvs tag -f NOT on cvs tag -f file.c). In these cases, the tag operation should check through the Attic for any files containing the specified tag and remove it. My argument for doing this is that if you are moving a tag, or deleting a tag, any files which have been removed from the current directory should have the tag removed, otherwise it is not possible to do a cvs co -r xxx yyy and get exactly what you tagged as you could get some Attic files as well. Any feedback would be appreciated, otherwise I'll start looking at the code involved. *** 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 Saturday, February 19, 2000 6:32 AM, |}avid (opeland [SMTP:[EMAIL PROTECTED]] wrote: > Not to continue to harp, but: > > > No, you're not exactly right and what you're missing is perhaps a > > critical facet that will help your understanding of this issue. "We" > > (i.e. CVS) define tagging to mean which revisions of which files are to > > be grouped together (perhaps for a release, or to mark a milestone, > > etc.). I.e. the two go together: revisions + files. > YES. I consider the removal of a file as a new revision of that file. So does > CVS. I simply want it to apply to concept of tagging, stat, and log to the > head revision of removed files just as it does to non-removed files. In other > words, removing a file is NOT a special case. > > As explained in my previous email, removing the tag does not work and I > actually DO want to tag the removed version. This allows me to use CVS to > support our workflow and development process. > > We are NOT doing multiple lines of development, but enacting a process WORKFLOW > which says that files are in a different state at different times. Whether or > not the file is present or not doesn't (and shouldn't) matter. > If a file is removed how can it be in any state? If I understand you correctly, you want to preverve the state of the files and are using the tag for this. Have you looked at the state parameter for this? Then you can have a single tag (e.g. release-1-2) and change the state to indicate where the file(s) are. This is discussed in Cederqvist. > (To recap, I have a moving tag that I use to indicate which revision of a file > is in which state of workflow). So, if have dev/stage/live tags, and the dead > revision is tagged as dev and as stage, but the previous (non-dead) revision is > tagged as live, that is the state where the client is approving a change that > involves REMOVAL of that file. > > If I had removed the tags, as you suggest, the file would be removed from live, > and this does not support our process. > Now I'm confused. You say that you want to remove the file (presumably so that it is no longer a current 'live' file) and then say that if you remove the tag "the file would be removed from live, and this does not support our process". So what do you want to do with the removed file. You don't want it to be shown in your HTML tree, but you don't want it removed. > > > I find it hard to believe that the > > > implementors INTENDED to have cvs commits not affect removed files. > > > > Now I'm really confused. A moment ago you were talking about tags. Now > > you you say "commits". > > I meant to say "cvs commands". My bad. > > > Actually if there is a tag then yes the removed file might be checked > > out or exported at the wrong time. You definitely do not want to ever > > tag "dead" revisions -- doing so puts the repository into an undefined > > state and no guarantees can be made about what might happen as a res ult. > Not that I've seen. It seems to work exactly as I want it to. It's just that > to tag the dead revision, I have to run a different command than I do to tag a > non-dead revision. This is inconsistent and I see no need for it. > > > I think your understanding of the temporal structure of the repository > > is not quite up to speed yet. Once/if you understand how CVS works across > > time perhaps you'll understand why "dead" revisions can never be tagged. > > I'm not sure why you insist that dead revisions "cannot" be tagged and that > doing so will put the repository in an "unstable" state. I have empiricly seen > that this is not so. CVS uses the Attic to retrieve tags from previous (historical) versions. The head of the main trunk is only the files in the main directory. The only time you will work on files in the Attic is when you extract a historical tag, or you are working on a branch and create a file which only exists on the branch (in this case the file is kept in the Attic and dead on the trunk). Dead revisions contain tags which were created before the file was labelled as dead, in order to allow the recreation of a previous tag of the directory. Any tags you place in the main directory and manually on a dead revision will cause the files in the main directory AND the Attic to be delivered to you when you do a 'cvs co -r live'. Is this what you want or do you only want the files in the main directory? *** 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 Friday, February 18, 2000 3:53 PM, |}avid (opeland [SMTP:[EMAIL PROTECTED]] wrote: > The difference I have is subtle. > > Most everyone on the list defines tagging a file as indicating which files you > want to group into a release. > > I define tagging a file as indicating which revisions of files you want to > group into a release. By tagging a dead revision, I am saying "Include the > removal of this file into the next release". Since my files are HTML pages and > images, this makes sense. For source code, it doesn't so much, and I think > that is everyone's problem with it. I think everyone is in violent agreement with you, except that a removed file is no longer in the revision. If you check out a tag, you get only the tagged files. If you remove a file there is no 'revision of files you want to group into a release'. You removed it. Therefore you don't want to group it into a release. I see that you are trying to automate the update of a set of html pages and your automated script says to check out the 'live' tag. Your problem is that moving the 'live' tag doesn't move the tag on the dead files. Is this a bug? A tag -F will move an existing tag, maybe it should check in the Attic and remove the tag from any files which contain the tag? With this functionality, I believe your problem would be solved. I may look at this next week, if I have time! *** 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: 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: 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: 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: 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)
RE: symbolic links in repository?
On Wednesday, February 16, 2000 5:48 AM, [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] wrote: > Are there any gotchas in adding symbolic links to a CVS repository > file structure? I'm trying to set up cvs for Java development, and > I'd like a structure like the following: > snip > > Will cvs freak out if the same directory/,v files are commited or > locked by users accessing them from different symbolic link > directories? (Different Root, same ,v) > With CVS 1.10, symbolic links function correctly in the repository. There were problems on earlier versions. > > > (EXPLANATION: > > I'd like to use symbolic links because I'm more comfortable setting up > the repository once, so that a single checkout gets all necessary > files, rather than what I'm presently doing, which is > > cvs checkout projects/NiceServlet > cd NiceServlet > cvs checkout core/com > > which is also fine, and I know it works, but you have to do it for > every subdirectory (I'm using several different Java packages), so it > turns into > > mkdir com > cd com > mkdir purpletech > cd purpletech > cvs checkout core/com/purpletech/utils > cvs checkout core/com/purpletech/servlets > cd .. > mkdir othercompany > cd othercompany > cvs checkout othercompany/com/othercompany > > which is a big pain in the neck.) Why not use nested/composite modules in the modules file? Then you could have a modules file like: _corecom-d core/com core/com _NiceServelet -d . projects/NiceServelet _OtherJava-d Other projects/OtherJava NiceServelet -d NiceServelet &_NiceServelet &_corecom OtherJava -d OtherJava &_OtherJava &_corecom Now checking out Nice Servelet will give you: NiceServelet/ NiceServelet/core/com This may not be quite what you want, but you should get the idea from this. *** 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)
