Re: "Triggers" & links to defect tracking systems
"Mark D. Baushke" wrote: > > > > > Hi, > > Is there any facility in CVS to add hooks for customized actions? > > For instance, requiring a Bug Number when you check in a file, > > verifying that bugnum against your defect tracking system, etc. > > It is possible to do some integration of Bug Number and a defect > tracking system by having the rcsinfo template provide a form for you > to fill in the bug number and haveing the verifyinfo trigger used to > validate that the log message provided by the user has a valid bug > number or other information. > What I was thinking of doing was using the loginfo hook to check the checkin comment to see that there is a PR number, and then verify that this is a valid PR with checkin approval (we've been having problems with some people checking in stuff without permission, and I'd rather put at least one tooth into the "don't do that" message). Does anybody foresee a problem with that? > I am not aware of any othters, but it might be desirable for the > commitinfo step to be able to prompt the user for information such as > the bug number or other information in order to better catch typos in > a bug number earlier. 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. > And here I'm just getting the shop on pserver. Fortunately, I'm not looking for interactivity, just compliance. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: P on Update?
Chris Edgington wrote: > > The CVS client documentation talks about the meaning of various letters returned > on an update command, like U for update, M for merge, C for conflict, but the > doc does not mention what the P stands for. Looking at the source, it looks like > it stands for patch. What does it mean to the end user - is there any different > between the effects of an Update or Marge versus a Patch? > Actually, M doesn't stand for Merged in the update output, but rather Modified. If you change a file and update the directory, it will show up as M even if there are no changes in the repository. There is no difference to the user between U and P, it being internal to CVS. Having different letters here is (I think) something of a wart. AFAIK, U means the whole file was sent from the repository, and P means a patch was sent. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reserved checkouts.
Richard Sharp wrote: > > Members Equity Email System > But I do need to use reserved checkouts - I have examined the issues for and > against and have decided on reserved checkouts. Some of our files will not > be able to be merged as they are graphic files etc. Any ideas ? > You don't need reserved checkouts in CVS, for the very simple reason that a CVS checkout is not the same thing as a checkout in a locking system. In a locking system, a checkout typically gets a local copy of the file and locks it; in CVS, a checkout gets a local copy of the file and sets up the metadata for it. What you want is some way of controlling who's working on the file at any given time, and the CVS way to do that is to set "cvs watch on" all files that you want to control, and ask the developers to use "cvs edit" to unlock them. This isn't strict locking, but rather advisory. Having worked with both, I can testify that strict locking doesn't stop people from working simultaneously on a file and blowing away other people's changes, and advisory locking seems to work as well as strict. So, add your binary files with -kb (or use cvs admin to put that on later), make sure there is a "cvs watch on" on all of them, and instruct your developers on the correct procedure. Violation of that procedure should be treated as any other act of sabotage. (Noel Yap wrote some patches to put teeth into the watch/edit process, and these can be found at the RCVS project at Sourceforge, last I looked. These patches were written against an earlier version of CVS, so use with caution.) -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Converting from ext to pserver
I am now working on a belated move from the ext access mode over NFS to pserver. What I would like to do, if I could, is ban ext access altogether, or at least find out if it is happening so that I can stop it. Is there any way I can turn off non-pserver access, or detect it when it happens? (I can't remove accounts from the CVS server at this time, meaning that it would take some time and some good reasons and likely some money to do so.) Is there anything else I should watch for during the conversion? -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Diff between update and checkout/commit
Nigel Morse wrote: > > So why is it called checkout? It's more of a copyout or retrieve coz it > doesn't actually checkout anything > Because in CVS the checkout is what gives you the ability to check in? It copies out the data and also puts the necessary metadata in the CVS directories. I would think that export would be a closer analog of a copyout or retrieve. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Xdelta and CVS
"Greg A. Woods" wrote: > > [ On Thursday, April 19, 2001 at 11:16:31 (+0200), Maarten de Boer wrote: ] > > Subject: Xdelta and CVS > > > > We are using CVS, for several projects, with great pleasure. > > We now have the need to store and track revisions of large > > binary files (audio analysis data). Because we are already > > familiar with CVS, and use it with clients on various > > platforms, we would like to use CVS for this data as well. > > That would be a "not-very-smart" thing to do. CVS does not in any way > meet your requirements for that kind of data. > More accurately, it meets requirements in a rather bad way, using a lot of disk space and offering little benefit you wouldn't get by gzipping and backing up the data regularly. CVS exists to allow concurrent development involving incremental changes to files. Is this useful on the analysis data? > > Obviously, storing all revisions entirely will not be very > > efficient. The data is pretty straigthforward, and the > > differences between versions could be extracted very well > > with Xdelta. So Xdelta integration in CVS seems to be the > > solution. > > Sure, but if you do that then you'll be off using an incompatible branch > variant of CVS that has no hope of ever being integrated back into the > main variant of CVS that uses standard RCS files for storage. Note also > that you cannot change what is considered to be "the main variant of > CVS" unless you convince the majority of CVS users to give up on RCS as > the sole repository file format either. > Um, what's so sacred about RCS file format? I realize that file formats are to be changed only with caution, but since the entire functionality is internalized into CVS (as of 1.10, I believe) there is no reason why it cannot be changed for a good purpose. > > The second idea is just plain wrong in claiming that it would not change > the CVS repository format since it would, by definition. RCS uses > "diff" and only "diff" for delta storage. What it really proposes is to > change RCS. > No, what it proposes to do is to replace RCS. I thought that the essence of CVS was something other than its file format. > Overall what that web page fails to note is that introduction of such a > drastic change to the repository data structures would make any such > repository incompatible with any normal RCS-only version of CVS, and > indeed incompatible with RCS itself. > Perhaps the web page author considered that it would be obvious to the intended reader (i.e., somebody considering development work on CVS). In any case, I really don't care about compatibility with RCS. RCS is on my list of stuff I never want to use again, not that far below COBOL. > BTW, that web page also fails to give full justice to the size of the > project. If you're really serious about something along these lines > you'd be INFINITELY better off if you simply started a new design for a > versioning tool and wrote it right from scratch. > I'm not all that familiar with CVS internals (not having had to mess around with it like I did Gnats), but it seems to me that we're talking about changing the repository format, nothing else. If this is a really large project, then CVS is very badly designed. (Now, test and validation would be time-consuming.) There is the obvious need for both-way conversion programs, but after that I think the Xdelta version would see fairly rapid acceptance. (How rapid depends partly on how effective the merging was, which is to say whether two changes in a file can be merged to produce another useful file. This would obviously depend partly on the file format, and I'm not an authority on common binary file formats.) > > > I am well aware of the fact, that CVS has not been designed > > to deal with large binary files, and that some people would > > consider it undesirable to add such functionality. I think > > it is worth the try though. As this is an important issue > > for our project, I can spend some time on this. > > You've obviously been blinded by your situation. What you're proposing > is somthing new and entirely different which may have a command-line > like that of CVS, but which would otherwise not be CVS. Calling it > "CVS" would be wrong. > Given a copy of CVS, and a copy of XCVS, with the ability to use both but not examine repository format or source code, could you necessarily tell the difference? If properly implemented, it seems to me that the changes could be mostly invisible. Given that this could be a plug-compatible replacement to everybody but the admins, why would it be new and entirely different? -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Xdelta and CVS
Maarten de Boer wrote: > > Hello, > > Obviously, storing all revisions entirely will not be very > efficient. The data is pretty straigthforward, and the > differences between versions could be extracted very well > with Xdelta. So Xdelta integration in CVS seems to be the > solution. > Could be. > The webpage > http://www.cvshome.org/cyclic/gallery/xdelta-dev.html > looks very optimistic, so I was surprised to find out that > I could hardly find any other references to Xdelta and CVS, > let alone a patch or (starting) implementation. > The page you have mentioned is a set of suggestions for people who might have the interest, ability, and time to work on integration of CVS and Xdelta, not a description of any work going on. In order for this implementation to appear, somebody's going to have to do it, and from the tone of the page it's going to be some outside volunteer. If you have the interest, ability, and time, you could do it. (I'm not sure I have the interest, and I know very well I don't have the time.) Note that the page listed three projects of increasing order of size, and using Xdelta to reduce repository size would apparently fall under the third project. > I am well aware of the fact, that CVS has not been designed > to deal with large binary files, and that some people would > consider it undesirable to add such functionality. I think > it is worth the try though. As this is an important issue > for our project, I can spend some time on this. > CVS uses diff in different ways. One is to keep the revision history files relatively small, and one is to merge changes. I looked at the web pages to see if there was some Xdelta correspondence to diff3, and apparently I'd have to go to Sourceforge, which is down at the moment. If Xdelta can create binary diffs and apply them to other files, in order to merge changes, and these merges result in something useful enough times to make the capability worth having, then it would seem to me to be an extension of the CVS philosophy. It would still mean changing the RCS format, and that may be a problem. If Xdelta provides its own archive file format, it is unlikely to be compatible with RCS, and it would be necessary (at the very least) to have some means of telling CVS what sort of file it was to access. Ideally, it would make it possible to version the file type, which is not currently possible. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
Jerry Nairn wrote: > > Also worth mentioning in this thread is the fact that most of the files > generated by InstallShield and the associated tool, Package for the Web, are > ordinary text. > Jerry Yes, that's what I was told, and that's one thing that makes me unwilling to zip everything up and store it in binary. I'd *much* rather store the text as text. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs server not translating line endings correctly
Larry Jones wrote: > > It's up to the client to convert from the local line ending conventions > to the cannonical LF-only format before sending the file to the server > (for non-binary files; binary files never undergo conversion). If you > use a Unix client to checkin DOS files, you will not get the correct > conversion. Likewise, some clients have configurable line ending > conversions and configuring them incorrectly will cause the same problem > (I think WinCVS falls into this category, but I'm not sure; and I have > no idea whether cygwin does or not). > >From my experiences with cygwin using Samba, yes it is a problem, and one which I will hope to solve this month by going client-server. BTW, this will leave a bunch of ,v files in the repository with the ^Ms on them. If I were to run some sort of ^M-removing script on them, should they be perfectly usable afterwards? Are there things to watch for that I wouldn't notice immediately after running it (I figure I back up and test immediately)? -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
Rob Helmer wrote: > > Don't check files or directories that have spaces in the names > into CVS. It'll cause nothing but trouble. > I was just asked a question about InstallShield. I'm not personally familiar with what it does, but apparently it creates a set of files of which many have spaces in their names, and it apparently cannot be set to do this as a matter of routine from pre-existing source. If there was an InstallShield script we could use, I'd say we keep the sources under CVS control and not worry about the InstallShield stuff. That apparently is not the case. There are too many filenames to make it practical to manually insert underscores instead of spaces. This being That Operating System, I don't know if it's easy to automate this process, like it would be in Unix. Not that this would be the ideal solution, since it would entail creating the files, mangling the names, checking them in, checking them out, unmangling the names, and sending to the user. I don't know if WinCVS handles this well. Nor do I know how it handles merging between branches, which in our setup depends partly on tag naming conventions, and therefore is not straight out-of-the-box CVS. The half-assed solution we're adopting right now is to zip the files into a zip file without spaces in the file name, but there's plenty of reasons why this is suboptimal. Does anybody have any suggestions? There are reasons why we're using CVS, so I'd rather not hear why I should drop it in favor of something unspecified. Diatribes against proprietary Intel-based operating systems are unnecessary, unless they contain something amusing I haven't seen (or said) before. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvswrappers - any better suggestions ?
"Greg A. Woods" wrote: > > [ On Monday, April 2, 2001 at 09:56:28 (-0500), David H. Thornley wrote: ] > > Subject: Re: cvswrappers - any better suggestions ? > > > > Philosophically, this seems to be a Platonist approach to > > software tools, and you're in a community of Aristotelians. > > No, you Aristotelians are invading a community where you don't belong. > Y'know, it can be really difficult to figure out whether you're surrounded by Platonists or Aristotelians. > > Funny, but around here the paint cans come with their own opening tool They do? I've always used the screwdrivers. (Am I buying my paint in the right places?) > Indeed the reason there are people prying versions of binary files out > of their CVS repositories is because people generally do just choose to > use the first thing that drops into the palms of their hands instead of > taking the time to find the right tool for the job. Unfortunately in > the more virtual world of software engineering people are incredibly bad > at making even roughly correct estimates in how much time they might > save, or how much more productive they might be, by choosing the first > tool that appears in front of them instead of doing a proper analysis > and searching for the right tool. > Here's the situation I'm looking at. We do most of our work in conventional programming languages like C++ and Java and Perl, and these work very well with CVS. We use HTML for some documentation, and that generally works well (although I have little experience with CVS storing the abominations you get when saving as HTML from Word). We have things like release branches and patch branches. What this means is that CVS works very well for most of the stuff we do. On the other hand, there is stuff mixed in there that is not source code. One example would be image files for the HTML. These files are most conveniently located in the same directory as the HTML files, and in some cases source files. This means that we have three choices. 1. Continue to use CVS, accepting the problems with binary files. 2. Use a combination of CVS and some other system that handles binary files better. 3. Switch to another tool entirely. Realistically, (2) isn't going to fly. CVS and the other system would have to be too closely intertwined, and nobody wants to learn another SCM system. This leaves (1) and (3). The problem with (3) is that CVS is very good for most of what we do. We need things like branches and concurrent development, and the fact that it has been working for a long time with few problems. Our source code is the company's most valuable asset (not counting people). Reliability and confidence are good things for this. If we were to go to another system, we would not have the same trusting feeling, and would go through a learning curve. I'm not saying we're going to use CVS forever, but any replacement needs to have much the same features as CVS or productivity is going to take a real hit. So, if somebody can point to a SCM system that has the same reliable reputation, doesn't cost too much, and does the same sorts of things, I'm listening. Otherwise, in a world where none of the tools exactly match my needs, I'm going with what seems to me the best choice, and right now that's CVS. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvswrappers - any better suggestions ?
"Greg A. Woods" wrote: > > [ On Sunday, April 1, 2001 at 08:26:32 (-0800), Gianni Mariani wrote: ] > > Subject: RE: cvswrappers - any better suggestions ? > > > > Your discussion below exposes a perspective which is about as far off from > > my own as you can get. I will go as far to say that your goals are > > You people just don't get it. CVS adheres to design principles that are > completely contrary to your requirements. You CANNOT succeed with it > given your current goals! It's irrelevant how many users have made the > wrong choice and are using CVS despite the fact that its design is > contrary to their goals. A wrong choice is wrong no matter which side > you look at it from. > Nope; CVS adheres to design principles that are at least somewhat compatible with our requirements. The fact that people are using CVS for the management of binary files implies that somebody can do it and be successful. Nor do I understand why this is inherently a wrong choice. I can understand why it would be the wrong choice under some given circumstances, but I have a great deal of difficulty with moral absolutes in open-source software. > Please go find some other software to abuse, and hopefully this time > you'll choose some non-free software and you'll be able to pay it's > maintainers to change their design if it doesn't happen to fit your > goals! Maybe you'll be lucky and you'll choose some non-free software > that has a significant "market share" too. > Philosophically, this seems to be a Platonist approach to software tools, and you're in a community of Aristotelians. What this means is that I believe we don't have archetypes of programming tools, in which CVS is judged on its similarity to the archetype of program source control systems, but a whole lot of existing tools, which are judged on certain criteria (philosophically more accidental than essential) such as usefulness. I apply this sort of philosophy for other tools, also. I don't wonder about how screwdrivery a screwdriver is, but rather how easily it turns screws and how durable it's likely to be. Given a paint can, I don't go to the hardware store and buy a tool to open paint cans, I pry off the lid with a screwdriver. It isn't designed to open paint cans, is not intended to, and is not sold for the purpose. I would assume it's harder to remove a lid without bending it with a screwdriver than with a specially designed tool (with a screwdriver, you have to pry gently around the lid). However, I have screwdrivers and a place to put them. I don't want to buy and store a special paint can lid opening tool. Heck, I don't even want to write to tool manufacturers and tell them that they need to make screwdrivers more paint-can-lid compatible. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update
"Derek R. Price" wrote: > > Eric Siegerman wrote: > > > On Wed, Mar 21, 2001 at 02:54:18PM -0500, Derek R. Price wrote: > > > Rui Cordeiro wrote: > > > > > > > Is there any option to tell to the cvs update to ignore the files that are in >the repository but not in the working directory. > > > > I want to update, in one step, only the files that I have checkout. > > > > > > Don't pass '-d' to update? > > > > That'll prevent fetching of un-checked-out directories, but I > > know of no way to prevent the fetching of un-checked-out files > > within a directory that *is* checked out. > > Yeah. What he said. :) > Without actually bothering to find out myself whether this would work or not, how about cvs update * ? The * should expand to a list of files in the directory (which may of course be too long to feed into the command-line arguments), and so the update should apply only to the existing files. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to avoid propogation of changes
[EMAIL PROTECTED] wrote: > > At any given time, we have multiple releases of our software under > development. Each release has it's own branch, with the latest release > being developed on the trunk. We propogate changes downstream by doing > merges from each release branch to the immediate downstream release > branch. > > Here is the problem: What if we make a change that we don't want > propogated downstream. Does any one know of a good way to accomplish > this? > Um, don't propagate it? Seriously, CVS doesn't move propagate changes by itself, so you must have some sort of mechanism to do so. This means you've got to figure out how to optionally disable it. To give an example, we maintain _MERGED tags on our branches, so BRANCH_3 would have an associated BRANCH_3_MERGED tag. We have a Perl script that will merge from a branch to, say, head. It merges everything from BRANCH_3_MERGED to BRANCH_3, and then moves BRANCH_3_MERGED. This means that the way to avoid propagating a change is to move BRANCH_3_MERGED past it, and this is indeed what we do (I've got a Perl script for that, too, for consistency, and it's pretty short.) -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: *some* files get checked out readonly
John Klassa wrote: > > I've looked through the FAQ, but don't see an answer to this question. > > I've got a whole subdirectory (for example) in which some of the files > *always* get checked out and updated read-only, while others don't. Might there be a "cvs watch" set on the files that are checked out read-only? I don't know offhand how to tell without looking at the repository. Try "cvs watch off " on one of the files that get checked out read-only and on one of the other ones and see if there's a difference in output. (From here, right now, I'd rather not experiment on my repository to find out.) -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checkout - do not get local copy
Hynek Syrovatka wrote: > > Hi, > how can I do it under CVS? I know this feature from Perforce or SourceSafe. > Thanks, > Hynek > The first thing we need to know is what you want to do. In CVS, a checkout *is* getting a local copy, along with the metadata CVS needs. In some source control systems, a checkout means getting exclusive permission to change something, but not CVS. In CVS, the default method of operation is for people to make changes concurrently and to merge the changes, and this works very well in some important domains, particularly the software development environment it was created in. If you need to have something like reserved checkouts, you need to use the "cvs edit" and "cvs watch" commands. It is my experience that systems with hard locks have no advantages over systems with soft, or advisory locks. I've seen changes overwritten in both. Finally, one of the main ideas behind CVS was to give everybody their own copy of the repository to work with, and so the system is built around the idea of local working copies. If a source control system that pretty much requires local working copies and is designed for concurrent change is unacceptable for you, you might want to investigate other options. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvslines opinions?
Chris Sharpe wrote: > > What are everyone's opinions of cvslines to handle parallel > development of multiple branches? > > I wonder why none of the CVS web sites seem to reference it (eg. > cvshome.org or cvsbook.red-bean.com)? > > Cvslines info: >http://www.floating.co.uk/netapp/technology/freeware/cvslines/ > And then do a google search to actually find the thing. It hasn't been updated since '97, and is not available at its own site. Those seem like reasons not to mention it. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Looking for *real* docs
Chris wrote: > > Howdy, > > I'm trying to write some code to allow you to browse a repository. Crucial > to this is thorough documentation of how to query the repository for name & > message information (through using 'log', I guess), as well as > documentation for the output of such commands, so I can parse it. I've read > man pages for rcs, rlog, and cvs, along with additional online material > including the Perdeqvist (sp) thingee, and I can't find anything, or even a > reference to what I'm looking for. > I looked at the output for "cvs stat -v" and picked out the lines of output that contained information I wanted, and made Perl regexps that would extract it. Nothing fancy. I didn't, and don't, know of a better way to do this. As far as I know, there is no defined way to read this information. This way suffers from the possibility that a future revision will change the output (AFAIK, there are no guarantees anywhere that this will not happen), but I'm the guy who recommends when to install new versions, and evaluates them, so I figure I can always change the scripts to accomodate any changes. > There are several add-on tools that do this, and I could plow through their > source if need be, but I'd rather not - I'd rather read what the > tool-makers read, whatever that is. > Reasonable question, but the answer is that you've found all the documentation I have. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [OT] bug tracking systems
schmolle wrote: > > >GNATS > > The last thing I heard from the GNAT-annouce list is that it's maintainers are not >maintaining it anymore. Unless that has changed, the project is as good as dead. > That was true for several months, but they seem to have found somebody interested, and so there seems to be forward motion. The big problem I had was that the apathy hit while they were working on a complete rewrite of Gnats. I had installed 3.113 because of Y2K issues, but this broke some things people wanted (like the Emacs interface) and I was hoping to upgrade to 4.0 sometime soon. 4.0 is still not ready enough for me to recommend for the company (actually, I'm waiting for 4.1), so we're still using what I had intended as a temporary solution. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 2 "how to <> in CVS" questions
Mark O'Brien wrote: > > Okay, here's what I would like to do. > > Short: Create and automated baseline/build/package system, that executes > after being given bugs that have been fixed. > Thanks. This makes things easier. > Detail: > > 1) Need to have CVS ask for bug number prior to checkin. Validate the number > with the bug track tool, get the state of the bug and branch to be fixed on. > Then validate the state (is the bug in a dvlp state or is it in a > test/closed state?) and the branch (make sure the bug has been fixed on the > correct branch). Then allow or disallow checkin. > I don't think there's anything built-in that will allow this. You can get the file name, with commentinfo, or the log message with loginfo, but not both, and I don't know that either can reliably get you the branch. > 2) Either before or after checkin, somehow associate the validated bug > number with the version of the file in a way that will allow 3). Yes, a > dvlpr can and the bug number, but what if the number is typed wrong, what if > the dvlpr leaves it out. > The developer can always mistype the bug number. Aside from checking that it's valid, and possibly that the bug track tool thinks this file is one that might reasonably be altered, I don't think there's much you can do about that. You can reject if the developer leaves it out entirely. You can do this with loginfo. > 3) Given a tag for the previous baseline A (tag on all files that represents > the last build), and bug numbers completed since last build, construct > baseline B from A by adding file changed for the given bug numbers. Parsing > each ,v file or a cvs log output to find bug numbers and than figure out > version numbers is not all that attractive. > I've parsed cvs output before, and, yes, it isn't all that attractive. However, I don't know of another way to put such information on a CVS entry. I think what you're going to have to do is write wrappers for CVS that will do the CVS processing and keep track of the external information some other way. This means that you've got to keep your developers from using "cvs ci" directly, somehow or another. Possibly the wrapper can set some sort of flag that commitinfo can test for, and abort the checkin if it's being done directly. > You right, maybe I can't do what I want with CVS. But I don't have a choice, > I have to automate the process, make it robust and have to use CVS. > You can use CVS inside the tool, but you're going to have to wrap functionality around it. I don't see any other way. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: FW: Website development
"Atkinson, Chip" wrote: > Thanks for the information. One thing that I've encountered is the need to > take very tiny steps with web development some times. Part of this is > because browsers aren't like compilers. Things like > blah blah blah > get rendered differently than > > > blah blah blah > > > Icky stuff like that means that if you wrote the entire page at once you may > end up having to re-do the entire thing after you see how it's rendered by > the browser. > This is getting off-topic, but how much control do you have over the people who are going to access this? If this is a purely internal web page, and you know everybody's going to use the same version of Netscape or Internet Explorer with pretty much the same settings, then it makes sense to consider the exact difference between the renderings of the above. Even then, odd stuff like that may change for the worse any time your company upgrades equipment or browser versions. If this is for external use, then people are going to use mostly Netscape and IE, but of all different versions and option settings. Some people will be using a different browser, such as Opera, iCab, WebTV, Lynx, old AOL, whatever, and you may wish to consider them. So, for external use, you can't possibly know how the reader's browser is going to render the HTML. It depends on browser, version, settings, window size, and possibly other thing. About the best you can do is write mostly standard HTML and look at it in a few setups and see that it looks reasonable in each. > I guess to summarize, I'd like to avoid having to force people to > drastically change the way that things are done in order to use CVS. > Understandable. It does sound as though CVS is a bad fit for what you're doing right now and how you're doing it. Whether this means using something else or changing the process is a judgment call. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 2 "how to <> in CVS" questions
Mark O'Brien wrote: > > I didn't what to get into the why's of what I ask. But it is to automate the > SCM baseline/build/package process. See inline for more info below. > The problem is that people ask "How do I do this?" when it is difficult or impossible to do exactly "this", or perhaps unwise for some reason the person hasn't considered. If we know what somebody's trying to do in a more general sense, we can be more helpful. > > On Thu, Feb 15, 2001 at 09:06:20AM -0500, Mark O'Brien wrote: > > > I am trying to figure out how to implement an automated process > > in which, > > > just prior to checkin approval, the branch is verified. Then > > after checkin, > > > the bug number is attached to that new file version. > > In this case, we've got a vague description of stuff that CVS probably doesn't do. We don't know what you mean by verifying a branch. We don't know exactly what you mean by attaching a bug number, and CVS doesn't make it easy to attach a specific piece of information *after* checkin. > I would like every file version to be mapped to at least one bug or > requirement number. Multiple revisions for the same bug fix is not a > problem. > It seems to me that having the bug or requirement number in the checkin comment will satisfy that. What you can do for that is write a loginfo program that will check the comment to see that it has either a bug or a requirement number, and return nonzero if it doesn't. With that, you can enforce the idea that every checkin comes with the number, and it will be associated with the rev and be reachable by "cvs log". This has the property that it doesn't happen without the checkin happening, so it has similar semantics to "after checkin". > > If you trust your developers enough to write code, then they should be > > smart enough to do something like add a line of comment to the commit > > message, like "BUG #123" and you could have something on the backend that > > will notice this in the message, and mark the bug as fixed in the bug > > tracking system. > > Comments are useless to SCM, they are purely for develpoments benefit. If > SCM is looking at comments to determine what to include in baselines/builds, > then serious process improvement is needed. > And we're back to talking past each other. What is it that you need? Do you need to be able to recreate baselines and builds (always a good thing)? Tag them! That's the CVS way. So, are you asking how to automatically add a tag with the bug or requirement number? That's something CVS won't do by itself, so you'd have to write wrappers and get your developers to use them instead of the raw CVS commands. But why would you want all of those tags? Particularly since they can't say what they are. Suppose file foo.c has two known bugs, one with a bug number of 1000 and one with a bug number of 1001. The second bug is easier to fix than the first, so on Monday somebody checks in the fix for 1001 while it takes until Wednesday to check in the fix for 1000. If you then have two tags, BUG_1000 and BUG_1001 on the file, what are they good for? They don't represent individual fixes, since BUG_1000 has the fixes for both 1000 and 1001. They represent a series of fixes, but don't come in an obvious order (particularly if mixing bug and requirements numbers). Any attempt to update to BUG_ is going to get an unknown collection of changes, which is not what SCM is about. And, if you're not going to use it to update to, why is it any more useful than a comment? I'm sorry, but I'm making no sense of what you're saying, and so I can't possibly help you. If you tell me in low-level detail what you want, I can probably tell you it can't be done in CVS (since that's true of most of such questions). If I understand what you're trying to accomplish, I might be able to come up with something appropriate. Perhaps you could provide a use case? -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: questions on cvs locking
Yuhe Liu wrote: > > Mike, > > I understand that's the way CVS was designed for multiple > developers. However for some reasons, we want to have the > reserved checkout on the files been updated. The file types > we have include text code, word documents, executable binaries, > package libraries, etc.. Most problems came from the word > documents and libraries. I can understand the word document problem (there are very good reasons not to use this as a saving format, but almost everybody does it anyway because it's convenient), but the executable binaries and package libraries puzzle me. Either you can rebuild these from source, in which case you don't need them under source control, or you got them from somewhere else and your developers shouldn't be arbitrarily changing them. Well, there's other alternatives, but they're rare these days. The cvs edit command does not lock > the files. It does only send a notifying message to those > who set a watch on the files. However, many developers do > not check their mail boxes often enough to catch the message. > If there were multiple messages on the same files, that would > be very confusing. > Can you get your developers to check their mailboxes more often? Besides, I'd think they'd be able to figure out that somebody was working on a given file and coordinate, even given multiple messages. (I'd hope so, anyway.) > Anyway, is there a way that we can set up an automated lock on > the files using command `cvs edit`? > Not without doing some serious rewriting or switching to another system. Have you looked at Noel Yap's patches at the Renegade CVS project on Sourceforge? He's added some functionality to the "cvs edit" system which makes it closer to being a lock. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: questions on cvs locking
Yuhe Liu wrote: > > Hi, > > We are using CVS for CM. It came with a problem that multiple developers > were updating > a same file. Although cvs provides lock/unlock commands, it seems not > convenient. > Why do you consider this a problem? I'm serious. In practice, the CVS way of letting several developers update a file and merging the results works very well, at least in some domains. Why wouldn't it work for you? The alternatives seem to me to be either that only one developer works on any file at one time, which can cause intolerable delays in getting things done, or more than one does, and one of them has to manually merge the changes. > > Is there any solution? > CVS has "cvs watch" and "cvs edit" commands so that developers can find out who's working on what. It doesn't stop anybody from violating whatever process you've got, but if your developers are deliberately violating process you've got a much bigger problem than concurrent vs. serialized development. I've seen problems with conflicting changes with a locking source code system. In fact, the old trick of writing "See me if you're working on this - David" on the master listing (back when I worked in an environment with master listing books) worked at least as well. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strict Locking for checkouts
[EMAIL PROTECTED] wrote: > > I need to stablish a strict lock on each checkout on my repository, > and then, when a user try to checkout a locked file, I need to denie > access. > Why? What are you trying to accomplish by this? As it stands, CVS won't do what you say you need to do. Since CVS has been around for quite a few years, it would be reasonable to think that was by design. > 1- How can I automate the strinct locking creation? I cant not rely on > users for this, I need some automated method to lock on each checout. > Write wrapper scripts and tell the users to use those? One problem here is that CVS has no operation that really corresponds to a locking system's checkout. You could look at "cvs edit" and "cvs watch". You can force all checkouts to be of read-only files, and tell the users to use "cvs edit" to change the permission. In my experience, strict locking will buy you precisely nothing over good communications. Writing "I'm working on this, let me know if you need to - David" in the master listing book worked even better than having SCSS locks. > 2- As I see rsclock only works for checkins.. how can I do to make > this work on checkouts? In my implementation a user can not checkout a > file if another user is working on it. > Why not? In some systems, there is a distinction between checking out a file, thereby getting a copy and sole permission to change that file, and some sort of copy, which gets a copy and no permission to change the file. In CVS, there is no such distinction. If you really want to stop people from getting copies of files other people are working on, then try some other system, because CVS won't work for you. Simply, CVS was designed to get away from this sort of restriction. The idea of merging changes together without locks has proved very successful on many projects. Why would it not work on yours? -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Trying to set up cvs + ssh + mac client
Dave Camp wrote: > > One of the Mac distributions has a set of MPW tools which implement the > command line interface. However, don't remember which distribution it was. I > do remember I could not figure out how to get it to work. > MPW (Macintosh Programmer's Workshop) is something of a command-line shell for the Mac, and is available for free from somewhere on www.apple.com (www.developer.apple.com?). It wouldn't surprise me to find a CVS client for it. The downside is that MPW is rather odd, and takes a while to learn. If you're going to be a serious Mac programmer, it might be worth your while to learn it (although in that case you might as well buy Metrowerks Codewarrior and not bother learning MPW), but if you're not going to use it heavily it's a long learning curve that isn't going to help you much anywhere else. > There is a development version of MacCVSPro that supports ssh. MacCVSPro can > be found at <http://www.maccvs.org/>. They have moved the source tree to > SourceForge, but due to some sort of snafu you cannot access it yet. If you > check the MacCVSPro list archives at eGroups.com, you should be able to find > the link to download a pre-built copy of the build that supports ssh. > I'll check that out. (That SourceForge is having snafus is not news, unfortunately, but I expect them to straighten things out reasonably quickly.) What sort of SSH implementation does it have? As I mentioned, the free SSH software I've found for the Mac is SSH 2, not SSH 1, and SourceForge (and presumably other places) want SSH 1. > I hope that helps... > Sure does. Thanks. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Trying to set up cvs + ssh + mac client
> Matt Munz wrote: > > Hi All. > > Feel free to rtfm me on this. I'd be happy to read a manual that > *clearly* addresses this issue. If you know about one, please let me > know. > So would I. > Back in the real world, any answers to the following questions > would help a lot... > > Is there a command-line cvs client for mac? > There are, I believe, three Mac clients, and AFAICT none of them are "command-line" in the usual sense. MacCVS, the one I've decided to go with, does allow a command line to be typed into a dialog window. Since Macs do not have a system command line, I don't know what else you would be referring to. > Can a mac connect to a cvs server using ssh w/o using port > tunneling? > I'm working on that, but haven't gotten anywhere yet. There is also a lack of Mac SSH free software, NiftyTelnet and MacSSH being the only ones I know about. Both of these use SSH 2, whereas Sourceforge says they only use SSH 1, so I have a bad feeling about being able to use Sourceforge The problem would be getting the client to use ssh, and the MacCVS method selection is in a pop-up menu. So, you can check out the Mac clients on cvshome.com and MacSSH on macssh.com. The config instructions for MacSSH include how to do a tunnel, but I haven't set it up yet. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Secure remote CVS
We have a lot of source code that needs to be kept secure. Right now, we're using a LAN protected from the outside world by a firewall, and that seems to be working. Now we'd like to be able to use CVS over considerably longer distances, securely. I recommended setting CVS_RSH=ssh, and was told that the users then had to type in their password for every file being transferred, and that is more typing than they're willing to put up with. We're not about to use straight pserver, for security reasons. There has got to be a way to log into a remote server securely, but I don't know enough about the networking involved. Any pointers? -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Spaces added ... and line endings in general
be able to continue dealing with it in the same way, no matter > which platform's CVS was subsequently used (ignoring the *extremely > rare* case of platforms with null-terminated lines, record-based file > systems, etc) > Right. There are people who would have problems if this were the default (or, worse, only) behavior of CVS. As long as they don't have to use the proposed behavior, they should be OK. However, why do we need to record the original line-ending format? If we're working multiplatform with text files, why does it matter? If I write half the files in a program with Emacs on my linux box, and the other half with Alpha on my Mac, why do they need to be segregated? I'd think that the choices for a file would include either that it is to preserve all standard line endings, or that it is to interpret all three of the most common ones as line endings. Leave it at that. I don't even know if it is necessary to keep this on a per-file basis. > I know there are a lot of people very rabidly against doing anything > like this to CVS. However, the fact that it comes up so often > indicates that it should be seriously considered. I know it's not > something that should just be slapped in in a weekend, but it also > shouldn't be completely condemned just because a 100% wonderful > solution isn't immediately obvious. > The significant thing is whether this would benefit a large enough group of people to make it worth doing as some sort of option. I think it would, but I'm not volunteering to do the coding on it. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Spaces added ... and line endings in general
James Lyon wrote: > > ES> How should a *single* CVS executable "accept/deal with" all of > ES> the following, which it *must* do if it's to defend itself > ES> against the kinds of abuse you want to throw at it? > ES> - Unix format: > ES> - DOS format: > ES> - Mac format: > ES> - Files in which some lines use one of the above conventions, > ES> and some use another (because you edited a DOS-format file in > ES> vi on a Unix box, and didn't religiously type the ^v^m's) > ES> - Unix-format files that contain s as actual formatting > ES> characters -- perhaps even at the ends of lines, for doing > ES> overstriking, so looking specifically for is unsafe > ES> - Record-oriented formats which use length words and have no > ES> terminator at all. This is old mainframe stuff -- dying, but > ES> alas not dead yet. (For an example, see below.) > On the dinosaur I worked on for over a decade, lines were terminated by two character's worth of binary zeros. (They're retiring it now, but its use did overlap the CVS era by quite a few years.) > The request was to handle only the line-terminated approach, and not > the record-orientated approach. > That was a request. It isn't the only possible request. Since it is a request to change CVS, it has to be looked at globally. > You just treat *any* *or* as a line terminitor with the > single *exception* that any that is found immediately following a > is skipped without treating it as a line terminator. > Which violates the fifth case above. I don't know how often \r is used for formatting, but the fact that it's got its own escape sequence in C suggests that somebody's probably using it for something - or at least that's a possibility you've got to consider. In short, this is a change that has the potential to really screw up somebody's files somewhere. I don't think this is something to do lightly. > This simple algorithm is *very* effective except when a "formatting" > is used with something following it other than an . But > that's logically ambiguous anyway and so you have to tell "it" what to > do with such situations. > Um, no, that's not logically ambiguous. In a Unix text file, the \r is very well defined. If you don't know whether it's a Unix text file or not, then you've got an ambiguity problem. > Having said all that, the real answer is to use utilities like > unix2dos and dos2unix to make sure your files are fixed before using > them in the particular environment... so the problem is evaded in the > first place. > Right. Alternatively, if you know your files do not contain embedded \ns and \rs, you can run a filter to make sure the files have the right line-ending conventions. This is something that should be done on a local basis, since you can be sure of your own file contents but not everybody else's. (And in reply to an earlier email: a three-l lllama is in fact a pretty bad fire in Brooklyn.) (Explanation for those who need it: in the US, fires are often measured in number of alarms, where a one-alarmer is a routine fire, and a five-alarmer is catastrophic. In the traditional Brooklyn accent, "three-alarmer" would be pronounced much like "three-l lama". I suppose this is what I get for trying to use a accent- and jargon-based joke in an international forum.) -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Connecting to a CVS-server on port *2402*
Donald Sharp wrote: > > >From my recollections, aix only had somthing listed at port 2401 > in /etc/services. It wasn't being used( unless you happen to be > using that service, and as I recall it was something very esoteric ). > I would recommend just changing your /etc/services to > point at cvs at port 2401 > IIRC, it was something to do with printing in a cluster, which could be vital to some sites. You could complain to IBM. They might listen, but I don't see them doing much about it. They are the people that did this in the first place. (On the other hand, looking at /etc/services on the AIX box I've got access to, it does list writesrv 2401/tcp # Temporary Port Number so maybe IBM would be willing to move it to a non-reserved port number. In a later OS version.) The issue with 2401 is not that the server can't be changed to another port with some quick config file changes, but that the clients know that 2401 is the right port. (Similarly, I don't know what uses writesrv, and that would be practically impossible to change locally.) > > Port 2401 is officially registered to CVS -- you really ought to fix > > your AIX box so that it isn't misusing a reserved port. > > There are reasons I don't like AIX. This is one of them. It flunks "Plays well with others". -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multi-user working directories
[EMAIL PROTECTED] wrote: > > Maybe I didn't explain things completely. With the Open Software model, the net > result of a development is a set of source code. In a closed system, we must > ship executables created from the source. (I'm not making any statement here as > to either model being better so everyone put those flamethrowers away...). > I don't see why this affects anything. Why would the need to compile before shipping affect source control? > In our case, everyone does have their own "sandbox" to develop source. But at > some point, the resulting software changes must be put together in to a release > to be sent to customers. The area I'm talking about is this. We can't send 10 > different sandboxes to the customer, we need to send a single set of executable. > This one "official release" copy is responsible for creating that final copy (or > in this case fixes to it) to be sent to a customer. > Right. So, you need some way of keeping an official release copy up to date. What do you ship? We tag everything before we ship, so we can export a controlled copy. (Too many things change too fast to expect a consistent version otherwise.) You may do things differently, and may want to ship the head branch. I don't know, and it really doesn't matter. The Cederqvist et al. manual has a brief section on keeping a checked- out copy http://www.cvshome.com/docs/manual/cvs_18.html#SEC171 and while this refers to loginfo it seems to me you might do something with taginfo, to check out files into a standard location when they have tags that are moved. This looks like a job for a Perl script to me. It seems to me that > It could be said that whomever makes a fix should build everything and ship it. > We're talking about thousands of source files that can take upwards of 6 hours > to compile, not to mention the 300Mb of resulting object code. It would be > somewhat wasteful to recreate all this for every fix we ship. > And yet this is what we do. We have several people whose job it is to ship what the client needs. They maintain their own exports and compile and ship. However, if you have an automatically checked-out version, then you can presumably have several people who can make and install the source code. It seems to me that that would solve your problem. Alternately, have a special username that is used only to maintain the master source files. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multi-user working directories
[EMAIL PROTECTED] wrote:
>
> We're using CVS client/server with :pserver:.
>
> We are about to turn our product source over to support. Up until now, a single
> person has been maintaining the "official release" working file set. After the
> transfer, we would like to have multiple people doing updates and various other
> CVS functions with these "official release" set of working files.
>
Why? Why have one "official release" set of working files that
everybody changes? Is there any reason why you can't have a
copy of the files for each individual person?
CVS was designed to allow developers to work on their own copies
("sandboxes"), and so what you're trying to do runs against
one of CVS's goals, and it's no wonder you're having problems.
What I would suggest, knowing only what I do now, is to give
everybody their own copy of the files, to modify as needed,
and to maintain an official release set separately. It is possible
to set CVS up to automatically maintain a completely up-to-date
version, if you like, or you might prefer to split official
releases into branches, or at least to tag them at a known working
point.
If there is a problem with what I've suggested, please tell us
what it is.
--
David H. Thornley Software Engineer
at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Free CVS Host ?
Dirk Ruediger wrote: > > Hi Reto, > > > Is there a service similar to sourceforge.com which provides a free > > CVS repository for personal development projects ? > > And what's your problem with sourceforge.org that you are looking for > another service? I',m shure you can use it for your own projects too. > Or you simply set up your own repository, if you want real privacy ;-) > Well, right now Sourceforge seems overloaded, and I'm not sure that putting even more projects on it is a good idea. The other disadvantage with Sourceforge, to me, is that it is necessary for the developers to use ssh, and AFAICT that is not an option with a Macintosh client. That's why I got my own very-low-end Linux box to host my own repository on. Works very nicely, and didn't cost much. I already had the Ethernet setup in my home office. (Note: this is in reference to my activities outside of work; CES does run a much more professional shop than I do at home.) -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Comparison between CVS and ClearCase
"Pikus, Nikolay" wrote: > > Hi > > We are going to insert CM system to our company. > > May be somebody can send me comparison between Rational ClearCase and CVS > (with WinCvs). > > Thanks > > Nikolay > In November 1999, there was a long discussion here about Clearcase vs. CVS. I saved about 45K of it and sent it to my wife (her workplace was considering how to go at the time - I don't remember exactly what they did but it wasn't CVS), and I could send it to you personally if you wanted (*not* to the list). The discussion did continue after I stopped saving it. Alternatively, you could look at the http://www.egroups.com/messages/info-cvs archive and see what you can find. There's going to be a certain CVS bias to what was written, but somebody apparently already recommended a ClearCase vs. competition website (which didn't come up for me) so that's likely from a ClearCase bias. It should even out, more or less. The general attitude was that CVS was a lot cheaper. It didn't do some of what ClearCase did - IIRC, managing directories was a big win for ClearCase - but most of the important stuff. There was some disagreement over the administrative demands. One person thought that CVS cost about as much as ClearCase when you factor in administrative costs, but most of us CVS admins have not had nearly the trouble he reported. There was some debate over how much of an administrative burden ClearCase was. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Proposal to fix CVS binary file implementation
.
>
This seems to be fairly common, like it or not (and I know you don't
like it). In my experience, "cvs watch" and "cvs edit" do everything
that's needed to handle the development of nonmergeable files.
> Now what about the scenario when you go to merge two branches together
> and there are conflicting changes in binary files, but where both
> changes must be retained? Suddenly your difficulties are twice as large
> and twice as hard to fix.
>
Twice as large and hard as what? You've got the choice of using
one binary or the other, or creating a new one. Is there a
better system around to do this?
> What about the scenario where your repository has been around for a
> while and you find that users are beginning to want to re-use
> now-removed filenames, but with different attributes (eg. suddenly a
> file becomes a binary)?
>
That happens now. I tell the users that it isn't going to work.
> The can of worms opened up by binary file support just gets deeper and
> wider the more you look at it.
>
Not unless you insist on being able to do everything with binary
files that you can with program source files, and in that case
I don't think you'll ever be satisfied. If you're willing to
make a few compromises, then there can be greater or lesser
support for binary files without changing all that much.
> While CVS as it stands has several features which make it generically
> attractive for general-purpose revision control, it cannot be stated too
> many times that CVS is *NOT* a general-purpose revision control system
> -- it is specifically a system *DESIGNED* to handle the special case of
> file formats which can easily be merged automatically with simple
> unix-style diff; and which as a result means it can specifically target
> the needs of those who must work in environments where concurrent
> editing must be allowed and encouraged. This DESIGN implies that it has
> constraints on its operation which prevent it from being a truly general
> purpose tool.
>
Unless you count language systems, there is no such thing as a
truly general purpose tool, and even with them we use special-purpose
tools for certain purposes. There is no reason inherent in the
design why CVS could not be made to handle other needs, to a
greater or lesser extent. In some cases, this would involve
undesirable code bloat for no proportionate gain, but that's
an argument to make on a case-by-case business.
It is unreasonable to say about a tool, "It does everything I want
it to do, and therefore should do nothing more." It is reasonable
to argue individual issues ("Should your text editor contain
a text adventure and newsreader?"), but that is precisely what
you are not doing in that paragraph.
> Therefore if you do not like the DESIGN of CVS, and by definition the
> constraints it imposes on the resulting product, then DO NOT USE CVS,
> regardless of whatever other features it has which might make it
> attractive to you!
>
I carry a Swiss army knife in my pocket. It has numerous design
constraints that effectively make sure it is not a great tool for
anything. However, it will do for many purposes requiring a tool,
and carrying it means that I frequently have a mediocre tool for
the job right at hand, which can be much preferable to having the
right tool in the bottom of the toolbox in another room. By
your reasoning, since it isn't the ideal tool for anything I
shouldn't carry it.
> I.e. if you want to handle binary files in a revision control
> environment then I strongly suggest that you'll be much further ahead if
> you simply take the ideas you like from CVS and start from scratch with
> a new design for a revision control system that is capable of handling
> the binary files you seem to need to handle.
>
Um, no.
If the CVS code base will do what somebody wants to do with some
modification, then I suggest that that person will be much better
off modifying the existing code rather than starting to build
a version control system from scratch. I'd hoped we'd gotten
beyond the "everybody makes their own tools" idea long ago.
> Of course if you throw away the silly idea of trying to support binary
> files in CVS with an RCS-format repository, and instead focus on
> extending CVS and the RCS file format definition it uses such that a
> file type can be specified on a per-revision (or at least per-branch)
> basis. Also devise an extension that allows deltas to be defined with
> byte or (multi-byte) character offsets instead of line offsets. You can
> then design tools which can do logical difference comparisons of
> variants and merges of changes with specific knowledge of these file
> types. THEN you'll have a more powerful revision control system tha
Re: Is the group still alive
[EMAIL PROTECTED] wrote: > > There haven't been any messages in almost two weeks -- is anyone > still here? > Yup. The volume has not been high, but there have been at least several messages a day. (Usually, I restrict my replies to the info-cvs address only; since you do not seem to be getting these messages right now, I'm including you in the header.) > In case there is , is it possible to see what has changed in a > project/module *since* a certain date? Things can be checked out *as > of* a certain date, but I really want to see the opposite -- what has > been committed since a date, or what has been committed since a Tag. > If you mean what changes have been made in a file since a certain date, I'd use cvs diff -D 2000-01-01 -D now -u foo.C to see the changes since the beginning of the year (the -u is because I like the unidiff format, and has nothing to do with selecting a period of time). If you're asking for a list of the actual checkins in a period of time, I'd do a "cvs log" and look for the appropriate changes myself (i.e., "vgrep" the log). -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: locking a file
[EMAIL PROTECTED] wrote: > > I have aproblem that a user can unlock (cvs admin -u) a file locked > by other developer. Is there a way to prevent this behavior? > p.s > I'm using cvs 1.11 on Linux > Some people will say that the problem is that you're using cvs admin -l to lock files, instead of using CVS for concurrent development as it was intended to be used (or using the "cvs edit" and "cvs watch" commands that are all that should be necessary for locking - if they aren't, fire your developers). However, for Unix (which I am going to assume unless told otherwise), if there is a group called "cvsadmin", then members of that group, and only members of that group, can use the "cvs admin" subcommand (except for the "-k" option). (This is according to the manual in texinfo form that should have come with your distribution.) Therefore, if you create a "cvsadmin" group, and include developers, and not users, then the developers can abuse the "cvs admin -l/-u" facilites without interference by the users. If you've already got this group, you've obviously put developers and users on it. If not, then it isn't any sort of added security problem to give developers permission to do what they already can do. If you aren't the sysadmin, then, talk to the sysadmin. Adding a group, and adding members to the group, is fairly easy. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multiple developers in one work area
"Parand T. Darugar" wrote: > > Everything I've read suggests that doing what I want to > do is frowned upon in CVS. My choices are to go with RCS > and not get the benefits of CVS, which I'm loathe to do, > or to build a very simple file locking mechanism alongside > CVS. I'm half way through doing the latter, which will > undoubtedly curse me to hell for breaking the CVS model. > It seems to me that you've already forfeited much of the benefit of CVS by not having the option of individual workspaces. At this point, CVS looks to me something like using a screwdriver as a chisel: it can work, and if you don't have a real chisel it can be the best thing to do, but it isn't going to work as well as a real chisel (if such a thing exists for your case). > A general question to the CVS gurus: it seems a central > assumption of the CVS model is that each developer can > individually build and test the project. This seems limiting. > Is this an understood limit within the model, or am I missing > the whole idea? > I wouldn't describe it as an assumption so much as a goal. CVS is very good at taking large shared projects and allowing each developer to have his or her own copy to experiment and test with. If this isn't going to work, for some reason or another (I've seen some pretty good reasons and some pretty bad reasons), then one of the main reasons for using CVS no longer applies. The thing to remember is that CVS was not intended as the only source code system, but as one that allowed developers to do concurrent development without stepping on each other's feet. It's sufficiently good at various things that people keep applying it in other circumstances (I, for example, put a CVS repository on my Linux box at home, to support single-person development), but I find it difficult to consider that a fault. I think that the correct thing for you to do is to try to find an appropriate tool or adapt a somewhat inappropriate one, and that is what you are doing. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS question
Vinh Pham wrote: > > That's a good idea. Unfortunately, that means we have to get into the > whole cvs watch on/off, cvs edit things. For me, it maybe OK but most of > my co-workers are not software-oriented. Adding that level of complexity > may not work well for them. I've been advising people to use the command > cvs status | grep Need. > However, this doesn't work with newly added file. Do you have any other > ideas? I wonder whether adding an additional flag to the status command > would be a good feature to add (if nothing equivalent existed yet.) > This is not exactly intuitive, but the best way I've found is cvs -nq update which lists what would happen if cvs did do an update. The -n means "Don't do anything!" and is useful if you are just looking for the output of a command, and -q suppresses some lines I don't find useful. It will list files, one line per file. If the file begins with a ?, cvs knows nothing about it (and it isn't in .cvsignore). If it begins with U, somebody's added it. If it begins with a P, somebody's changed it. If it begins with an M, you changed it; if somebody has checked in a change, you'll get a message about the changes being merged. If it begins with a C, then your version is incompatible for some reason with the version in the repository, usually because both you and somebody else have made conflicting changes. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkouts control
[EMAIL PROTECTED] wrote: > > Hi all > > I am new to CVS and CM but am responsible now for managing a small > repository in my company.I have no one experienced in this field to > ask these questions. > I have a question in general about configuration management.Is it > necessary to document check outs from a CVS repository?Will it serve > any purpose? will it make keeping track of releases,tags,branches etc > more easy?is it a good practice to allow uncontrolled check outs to > all developers in a project?If someone can advice on this ,I will be > grateful. > I see no obvious reason to keep track of checkouts. In CVS, a checkout is just getting a local copy of the repository, with no implications about checking in. There are a lot of anonymous CVS sites that allow anybody to check out from their repository. If you're looking for a way to track who's planning to change what, the watch/edit facilities should work well. Look up "cvs watch" and "cvs edit". Basically, if you have a watch set on files, then you will be informed whenever somebody issues a "cvs edit" command. If you have "cvs watch on", then all checkouts and updates of the files will be read-only, and this will be a reminder to "cvs edit" before working on the files. (Yes, the developer can change permissions by himself or herself. If you can't trust somebody to follow basic procedure, fire that person.) -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: incorrect return code on vms...
Donald Sharp wrote:
>
> This makes no sense to me( I'm not saying your wrong ). I just
> don't fully understand what you are trying to say here...
>
I have been unclear.
> Comments inline
>
> > In Unix, for example, the null pointer value is all-bits-zero,
> > zero is a successful program exit code, and other values are
> > various sorts of errors. Following this, in C, 0 (cast to
> > pointer type) is a null pointer value, and 0 is an exit code
> > that represents success.
>
> Where does it cast the exit code( in this case a int ) into
> a pointer?
>
Nope. This was intended as another example of the way the C
system handles certain things behind the scenes, to allow
standard-conforming programs to be executed on systems that
do not conform to the Unix assumptions.
> Here's my test program:
>
> int main( void )
> {
> exit( 5 );
> }
>
> in the debugger:
> (gdb) disassemble main
> Dump of assembler code for function main:
> 0x10538 : save %sp, -112, %sp
> 0x1053c : mov 5, %o0
> 0x10540 : call 0x20634
> 0x10544 : nop
> 0x10548 : ret
> 0x1054c : restore
>
> this is the exit program?
> (gdb) disassemble 0x20634
> Dump of assembler code for function exit:
> 0x20634 : sethi %hi(0x12000), %g1
> 0x20638 : b,a 0x205ec <__DTOR_END__+4>
> 0x2063c : nop
> 0x20640 : sethi %hi(0x15000), %g1
> 0x20644 : b,a 0x205ec <__DTOR_END__+4>
> 0x20648 : nop
> 0x2064c : sethi %hi(0x18000), %g1
> 0x20650 : b,a 0x205ec <__DTOR_END__+4>
> 0x20654 : nop
> 0x20658 : nop
>
Which is how it is implemented there. This is not a completely
portable program, as the meaning of exit(5) is implementation-
defined (so that the implementation is required to pick
a meaning and document it).
On all Unix systems I know of, the exit() function passes a
numeric value straight back to the operating system. On a VMS
system, it can't do that with exit(0).
> >
> > On some platforms, all-bits-zero is a valid pointer, and there
> > is some other invalid pointer. This does not break working
> > code, as the C system simply translates (void *)0 (or whatever)
> > to the appropriate pointer value.
>
> I don't understand this either. Now suppose the null pointer
> on a system is 0x01. How does the c standard distinguish this between a 0
> or a 1 as a return code?
>
As a return code to malloc()? On any conforming implementation,
int *ip;
ip = malloc(10 * sizeof(*ip));
if (ip == 0)...
is a valid way to test if ip received the null pointer from its
call to malloc(). In this case, ip is a pointer variable, and
therefore 0 has to be cast to a pointer value, which in this
case would be 0x01. (Just like, after "int i; double d;...",
"if (i < d)" requires that the value of i be converted to a
double for purposes of comparison.)
There are restrictions. The 0 has to be a constant integer zero,
not a variable set to zero. It is not necessarily all-bits-zero,
and therefore memset() and calloc() don't necessarily produce
null pointers.
What happens is that the C standard says that an invalid pointer
value will compare equal to a constant integral zero, and such
a zero will convert to the canonical invalid pointer value, and
so any implementation has to do whatever it needs to make this
true.
> My missunderstanding centers around the conversion to a pointer.
> Why? This makes no sense, it's a integer, why convert it to
> a pointer?
>
Because 0 is defined that way, basically. It might have been
better if C had started without 0 being used as the null
pointer value, but rather some sort of symbol (like "NULL" or
"nil") that could perhaps be #defined to the proper value.
It would have saved a great deal of confusion down the road.
(The same applies to exit status. There would be much to be
said for just having "EXIT_SUCCESS" and "EXIT_FAILURE" as portable
values to exit with, but by the time C was codified it was too
late.) There's lots of things about C that are the way they
are because things that seemed like good ideas at the time
got used in many megabytes of source code widely distributed
before people realized they weren't very good ideas after all.
--
David H. Thornley Software Engineer
at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: incorrect return code on vms...
"Derek R. Price" wrote: > > Larry Jones wrote: > > > Noel L Yap writes: > > > > > > Hmmm. How does diff-utils deal with this situation? > > > > I don't think diff-utils is interested in running on non-Unix/Posix > > systems. CVS is (although it doesn't quite succeed just yet). > > Still, where's the harm in returning only EXIT_SUCCESS & EXIT_FAILURE on > systems that require that and a little more information on systems which > support it? Because any system that requires it is broken. I doubt that catering for individual broken systems is high on anybody's priority list (except somebody who works on that system). More specifically, the proposal seems to be catering to hypothetical broken systems, and I really don't think that is a good idea. If we have a specific broken system in mind, then we can look at it and figure out what it needs in detail - and any system that runs a C compiler that conforms neither to the standard nor to older Unix code is likely to have problems in more than one detail. We're talking about a few lines in configure.in, maybe one > in acconfig.h, a line in system.h, and a single line in main. I'll do > the work, or what Donald hasn't done already. > Redefining constants that should be defined in the standard headers, even with #ifndef guards, is not good practice. In my experience, it removes error messages that occur, and should occur, if a required header is omitted, or if the header is defective. (Of course, I am much stickier about standards conformance than some people. I think it promotes portability and understandability to write conforming code, and not to cater to non-standard systems without specific reason.) > Derek > > P.S. run.c already seems to non-portably _exit() with bash's 127 when > it can't exec a program. > Now, that should be fixed. CVS is supposed to be portable, and any main() should return only EXIT_SUCCESS or 0 (which are interchangeable) and EXIT_FAILURE. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: incorrect return code on vms...
Donald Sharp wrote: > > On Fri, Dec 01, 2000 at 09:47:52AM -0600, David H. Thornley wrote: > > > > > > Donald Sharp wrote: > > > > > > If the return codes for a program are reversed on vms, > > > such that success = 1 and failure = 0, then cvs would > > > always exit with a failure on vms systems. Attached > > > is a patch to fix this problem. > > > > > Assuming that VMS has a conforming C compiler, this is not > > a problem. The C system interprets both 0 and EXIT_SUCCESS > > as successful exits, and EXIT_FAILURE as a failure exit. > > These are defined in . > > You missunderstand what I did. This has nothing to do > with the c compiler. It has everything to do with what > cvs returned as a exit code. The vms system( according to > the ChangeLog ) interprets return codes from programs as follows: > 0 - Program failed > 1 - Program Succeeded. > No, it has to do with what happens between the writing of the C program and the status return to the operating system. That is where the C compiler comes in. In Unix, for example, the null pointer value is all-bits-zero, zero is a successful program exit code, and other values are various sorts of errors. Following this, in C, 0 (cast to pointer type) is a null pointer value, and 0 is an exit code that represents success. On some platforms, all-bits-zero is a valid pointer, and there is some other invalid pointer. This does not break working code, as the C system simply translates (void *)0 (or whatever) to the appropriate pointer value. Similarly, on some platforms, 0 is the failure exit, and the C system simply translates appropriately. > Original code did this: > > exit( err ? EXIT_FAILURE : 0 ); > > Within cvs err is set to 0 for program success and >0 for failure. > In other words, the program is completely correct here. That is perfectly good code according to the standard. > stdlib.h on vms should set EXIT_FAILURE to 0. Therefore the > above exit() code will always return 0 on vms. I assumed that EXIT_SUCCESS > would be set to the correct thing. Hence: > If stdlib.h on vms sets EXIT_FAILURE to 0, it is not a conforming C compiler, and, as I said, you should find a better one or gripe to your vendor if you run into this problem. 0 is, by definition in the Standard, a successful value. If the exit() function has something like "return !exit_value" in it, it will pass the correct value to the operating system. (This is platform-specific code, of course, which the standard libraries pretty much have to be.) EXIT_SUCCESS may be set to 0, or it may be set to some other value the system finds convenient. However, EXIT_FAILURE may not be set to 0. > exit( err ? EXIT_FAILURE : EXIT_SUCCESS ); > > I #defined EXIT_SUCCESS in system.h ostensibly for old sun boxes > see the comment above the EXIT_FAILURE line in system.h. > If this is catering for pre-standard compilers, then my only problem with it is that people should get standard C compilers if they want to compile code on multiple platforms. > If vms isn't setting EXIT_FAILURE or EXIT_SUCCESS then we > need to fix the #defines in system.h to do the right thing > on vms. > If doesn't set EXIT_FAILURE or EXIT_SUCCESS, the C compiler (with libraries) probably has other problems also. I just don't see how, in December 2000, I can advise using compilers that do not try to conform to an eleven-year-old standard. > Also we should not be returning 0, we should be using EXIT_SUCCESS > in the code in main() in order for the right thing to be done... > Returning 0 is the right thing. So is returning EXIT_SUCCESS. Returning anything else would be the wrong thing in a program expected to run on several different platforms. (It could be the right thing to do for a platform-specific program, which CVS is not.) > Having said all that I bet this is a moot point in a lot of respects. > Is anyone even using VMS? > I heard that DEC has dumped all support for the Vaxen, but that VMS still runs on Alphas. Some people are still using it, and are presumably happy with it. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: incorrect return code on vms...
Donald Sharp wrote: > > If the return codes for a program are reversed on vms, > such that success = 1 and failure = 0, then cvs would > always exit with a failure on vms systems. Attached > is a patch to fix this problem. > Assuming that VMS has a conforming C compiler, this is not a problem. The C system interprets both 0 and EXIT_SUCCESS as successful exits, and EXIT_FAILURE as a failure exit. These are defined in . If the operating system has other conventions, and many have, then the C compiler needs to create code that will change the exit status appropriately. In this case, it should transform 0 to 1 and whatever it uses as EXIT_FAILURE to 0. In other words, do what it takes to make ISO standard C work on the system. If CVS is telling VMS that it fails when it in fact succeeds, then the C compiler is bad, and likely has other failings as well. Find a better compiler, or pester your vendor to conform to the standard. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: locked files
Thomas Olausson wrote: > > > This topic has been discussed numerous times and I still haven't seen an > > absolute need to use "cvs admin -l". > > Well, some people don't trust that if someone gets a conflict when > trying to merge, that the resulting file will be OK, because of human > errors. > I don't trust people to do the right thing when merging manually. Given a shop of reasonable size and activity, somebody's going to be working on program X when it needs to be fixed Right Now. How are you going to handle that? CVS model: Make the quick fix, person doing the long-run development merges in the change, accounts for it, life goes on. Locking model: There are several possibilities. I've seen them. 1. Somebody makes the quick fix, by getting the program lock. Person doing the larger development keeps interim copy of program, and checks it back in without the quick fix. 2. Somebody makes the quick fix, and the person doing the larger development hand-merges it in incorrectly, creating a new bug. 3. Somebody makes the quick fix, and the person doing the larger development recreates the changes on top of the newly fixed version, inaccurately. 4. Quick fix is made and hand-merged in without program assistance. In a case like this, locking is useless. What you need in a case like this is communication. I've worked in a shop where we wrote "Please see me" on the listings in the listings books if we were going to make a change. That worked. We had less problems with conflicting changes than we did in the place where we used SCCS and locked. > Locking stalls development, but encourages that one person does some right > without disturbance from others. > As long as you can guarantee a lack of disturbance, this works. I don't see that this is a realistic guarantee. When (not if) you have two conflicting changes to a file, often because it's being modified (and is not yet ready to use) and it needs a quick change, you need either communication or a reliable merge process. CVS' merge process isn't entirely reliable, but it's very good, and as long as people keep an eye on what's going on in programs they're working on it's a very good solution. CVS can also provide a means of communication, with its edit and watch facilities. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout via tagname, then can't add
Kris Herrald wrote: > > I am having some problems and can't seem to find the answer anywhere. > Hopefully, you can help. > > Summary > I want to checkout files based on a nonbranch tag name. Based on these > files I will be creating new files. These new files will need to be > added, then committed, and finally tagged. I can't seem to get these new > files added to the repository. The error message I get is: "cannot add > file on nonbranch tag 'tagname' " I definitely do not want to create a > branch, I am not trying to set a branch tag. I want to use a plain, main > trunk, tag name to do my checkout. > If you are not trying to create a branch, exactly what are you trying to do? You are apparently trying to take a previous version of the file, modify that version, and save it as...what? Where is the new version of the file going to go? It apparently isn't going to be in the main trunk, since there's a divergence. It has to go on a branch somewhere. CVS does not support versions of files floating around, unrelated to anything else. > Detail Commands > 1. cvs checkout -r tagname htdocs > 2. creating new files in the same directories that were originally > checked out > 3. cvs update -A filenames (this was an attempt to remove the sticky > tag) > 4. cvs add newfiles > 5. error message occurs: "cannot add file on nonbranch tag 'tagname' " > That seems a bit odd. cvs update -A should not only remove the sticky tag, but update to the head of the trunk. If this is acceptable, then you should just add everything on the trunk and retag it there. If it is not, then you need to put the revision on a branch. > Can you not checkout via nonbranch tag and then add files to it- even if > you do an update -A > No. CVS supports the changing of files along defined tracks, which can be the trunk or a branch. Remember that, while the users should be concerned with tags and not revision numbers, CVS has to have revision numbers. What revision number should the file as modified have? -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Duplicate messages
FWIW, I also subscribe to the gnu Gnats mailing list, and just got a couple of pairs of emails from there. I'd suspect gnu rather than egroups. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: why wast time to write a FAQ?
Tobias Weingartner wrote: > > I'm going to agree with this wholeheartedly. *Most* of the FAQ's asked here > are of the form "Why can't I, or How do I, do 'locking', etc". If those > people had bothered to read the manual, they would have (with even half an > IQ point) noticed that CVS advocates a copy-merge conflict resolution method, > and we would not have had their questions in this forum in the first place. > And people are going to continue to ask these questions. We have the choice of continuing to explain why copy-merge is a reasonable way to go, or to have some sort of canned answer. > To give an example of a project where a FAQ is not really "sanctioned", have > a look at OpenBSD. Their man-pages have had sigificant work done to them. Real documentation is good, although time-consuming (and I'm not volunteering at this time). > Most of the time when somebody asks a FAQ (yes, OpenBSD has a FAQ, but it is > quite tiny in comparison to most other OS FAQ's out there) the usual response > is one of 'man question(1)', where question refers to the man-page where the > needed answer is documented. > I'm unfamiliar with the usual OpenBSD questions, but I would assume that some questions are asked rather often and some less often. In that case, it might make sense to have a FAQ on the order of: Q. My system A. man fnord(3) Unless the documentation is absolutely superb, and likely even then, there are going to be tricky points that people miss, or overlook, or get wrong in adapting the instructions to their system. These tricky points can be gathered together into a FAQ, which can give a quick answer and reference the manual. > The FAQ in OpenBSD is used more to document errata and other things that > should get fixed, and should already be fixed given an ideal world. That's one use for a FAQ. Q. My system... A. Yup, that doesn't work yet. If you want to work on it > With time, people will recognize the manual as the authoratative piece of > information (other that this list of course, :-) ) on CVS, and will consult > it without us needing to use the cluestick every time somebody posts on > this list... > Um, you have more faith in human nature than I do, Toby.
Re: CVS, Proxies, and Firewalls -- Oh My!!!
Mike Friemann wrote: > > The company that I work for has two offices in the US. We decided to > look into CVS so that both offices would have access to the same > source repository. > > The server sits out on the web and the clients are behind a firewall. > We can get WinCVS clients to connect to a CVS server just fine as long > as we don't have to go through a firewall. With a firewall we seem to > connect to the server, but then we get, "Connection reset by peer". > All I had the SysAdmin do was open the port on the firewall for > outgoing. > Since you're using WinCVS, I assume you're using the pserver connection. This means that the sysadmin needs to open 2401 for outgoing connections. If you were using ssh, you'd presumably open 22. Now, pserver is not secure, so you might want to see about using ssh (which some people on this list claim is easy) or running some sort of secure socket connection for port 2401. > I've looked all over the net for a solid step by step instruction > document on connecting to a cvs server through a firewall and I cannot > find one. > I would assume that it's a matter of firewalls differing. The documents refer to what you need to use CVS. If you've got a firewall, you should have a sysadmin who is able to manage it, and the docs will tell you that pserver is on port 2401. (Note: AIX seems to use 2401 for something different, so if you're working on AIX you may have additional problems.) > I don't even remember the official docs mentioning anything about a > firewall entering the picture. > They also don't describe how TCP/IP works, or how to hook up an ethernet LAN. Again, if you've got a firewall, you should have somebody who knows how to let specific ports through. If you're using pserver, you need to open 2401 for outgoing connections. If your sysadmin doesn't understand that, you have more problems than we can help with.
Re: CVS revision number problem
pei1 wrote: > > Dear Sir / Madam: > > We decided to bring the major revision number up to 3.1 so I did > > a command: > > cvs commit -m "Change major revision number." -r 3.1 > This is almost certainly the wrong thing to do. It is best to leave the revision numbers alone, using them only as identifiers. If you want to list files as revision 3.1, the right thing to do is to assign a tag: cvs tag REV_3_1 or some such. Any reference to a group of files should be to a tag, not to a revision number. > The wierd thing is: > > Some files are updated to 3.1, but there are files which still > > stay at old version number. And I checked and there seems no > Were some of the files changed, and some not? Without looking at the docs, I'd expect changed files to be committed with the specified rev number, and unchanged files to be left untouched.
Re: CVS for Lawyers?
Duncan Kinder wrote: > > Hi. > > I am interested in the topic of version control, not for software > development, but for the production of other documents, such as legal > documents or editing for online publications. > CVS works best on text files separated into lines, as these allow it to store the changes efficiently. If you can define a change as removal of certain lines and addition of certain other lines, and two changes to the same file that do not directly conflict can probably be applied together, then CVS is useful. So, whether CVS is useful depends on the type of files you use. If you use .doc files or some other binary format, then CVS is no more than a manager that can be used for on-line backup and restore. If you use a text-based formatting tool like LaTeX (or other TeX) or *roff, then CVS should be able to manage your documents very nicely.
