RE: CVS and Jar files: Should you import Jar into the Repository? Why or why not
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 06, 2002 3:11 PM > To: [EMAIL PROTECTED] > Subject: RE: CVS and Jar files: Should you import Jar into the > Repository? Why or why not > > > [ On Wednesday, March 6, 2002 at 14:21:56 (-0600), Thornley, > David wrote: ] > > Subject: RE: CVS and Jar files: Should you import Jar into > the Repository?Why or why not > > > > I still fail to understand the problem. > > What's to UNDERSTAND? CVS manages source files which are diffable and > patchable. Other things manage other kinds of files. You > tie all these > things together in whatever overall build and release management > processes and procedures you will need for all but he most mundane of > projects. There are apparently even already tools that make > short work > of tying these things together for Java JAR files! > What's to understand? Simply, why I should not control some binary files with CVS. So far, for all your rhetoric, you have failed to actually tell me any specifics about a problem. Further, CVS manages source files that are not diffable and patchable. I've done it. Other things also manage these sorts of files, but CVS will do it. CVS doesn't do as well with these files as with (say) C source files, but this isn't a cause for alarm. > > > Simple directory naming schemes are almost infinitely better! > > > > In what way is a directory naming scheme, or named > tarballs, infinitely > > better? > > It has all the features and capabilities necessary to fulfill your > requirements for keeping many revisions of binary files, and > it has none > of the drawbacks of CVS. > I can keep many revisions of binary files in CVS. Granted, a large file with lots of changes will have a very large ,v file eventually, and this may be an issue, but it isn't necessarily the case, and indeed I haven't run into such a case. The files that cause the most performance issues in our repository are large text files with lots of revisions. Now, it may be that CVS would have problems with large and frequently changed files, but not all binary files are like that. If I kept *.o files in the repository, I'd expect problems. As it is, the problems caused by the binary files I've got (both at work and at home) are less troublesome than the problems caused by the sorts of files CVS is supposed to handle. > > In order for it to be infinitely better, I'd need to be causing > > infinitely hard problems by keeping binaries under CVS control. > > Unless you can securely isolate all your non-diffable and > non-patchable > files in modules separate from your source files, and unless you can > ensure all your CVS tools (client, server, etc.) properly handle all > aspects of binary files, and unless you can securely > implement policies > stating how those modules containing binary files are to be used and > manipulated, you cannot safely use CVS in general to track > revisions of > binary files. > Why not? I call them "-kb" on creation. That seems to have protected them just fine. I have had no, repeat no, cases of file corruption. > However even a simple naming scheme "just works". That seems to be > infinitely better to me! > Although you have notably failed to provide what I asked for, namely something in the way of use cases to show problems in using CVS to store binaries, I'm going to discuss possible ways in which such schemes can fail. Suppose we have one master directory, with subdirectories specifying branches and subdirectories below these specifying dates. We will assume that these directories are executable and readable for all the developers, and writeable for an administrator. What sorts of things can go wrong? 1. Somebody can make a change and fail to notify the administrator, or the administrator can be out or otherwise occupied and fail to record a change. This can mean a missed change, or a misdated one. (Note that this can be partly alleviated by allowing the developers to add files to the repository. I'd be scared that they'd misname or overwrite something. One thing CVS does is ensure that, unless somebody has direct repository access, they are limited in what they can do, and cannot, unless they use "cvs admin" (which you can restrict with OS groups), lose any versions. They can lose tags, which is a problem, but not versions.) 2. The administrator can misname a directory accidentally, or fail to create a new directory because the changes seem so small. In this model, there will be a very strong tendency to keep only versions that seem significant, and this may cause problems later. 3. A directory could be remo
RE: CVS and Jar files: Should you import Jar into the Repository? Why or why not
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 06, 2002 1:58 PM > To: Thornley, David > Cc: [EMAIL PROTECTED] > Subject: RE: CVS and Jar files: Should you import Jar into the > Repository? Why or why not > > > [ On Wednesday, March 6, 2002 at 09:59:38 (-0600), Thornley, > David wrote: ] > > Subject: RE: CVS and Jar files: Should you import Jar into > the Repository?Why or why not > > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > > > > It might not be a "necessary feature", but it's the way > RCS files work > > > today and in combination with the forced concurrent edits > feature of > > > CVS, it makes it nearly insane to try to track non-diff-able and > > > non-patch-able files! > > > > Why? Lots of people on this list who appear to be sane have used > > CVS to track limited numbers of non-diffable files. > > Sure, it's possible, but it does not work well and it does > not give any > meaning to the results that cannot better be obtained in any number of > other possible ways. > I still fail to understand the problem. If I have a directory with several text files and one binary, I can put it on CVS. I do have to record the binary as binary. I can have people do concurrent development on the text files, and can use branches. When I do a checkout, update, or export, I can get the versions I expect. One command to get the whole thing, reducing the possible ways to screw up. What I cannot do is merge versions of the binary, which means that I want to avoid concurrent development, and in the case of separate changes on branches I can't automatically merge. Instead, I have to choose one version or the other, or independently create a third. This is not particularly onerous, usually, and it's pretty much the same merge algorithm that any other system would have. Obviously, if the non-mergeable files change frequently, and are most of the source tree, it becomes effectively impossible to use branches and concurrent development, and in that case there's much less reason to use CVS. However, given small numbers of files that change relatively infrequently, this approach works pretty well, and I really don't know of anything better. > > The points to > > remember are (1) it works in CVS, although not as well as other > > formats do, and (2) there's nothing in general that's all that much > > better. > > On the contrary! _ANYTHING_, in general, is much better! > > Simple directory naming schemes are almost infinitely better! > In what way is a directory naming scheme, or named tarballs, infinitely better? In order for it to be infinitely better, I'd need to be causing infinitely hard problems by keeping binaries under CVS control. (Alternately, the naming scheme would have to set itself up with zero work, or zero chance of error, or something like that.) Even allowing for exaggeration, I haven't had serious problems connected with keeping binaries on CVS. I've been hearing that there are such problems for a long time, and still haven't found them. Could we perhaps have a use case showing these horrible problems? Assume we're developing software and need a few icons. > Get out of the box! > I'll get out of the box when somebody shows me something better outside. Hasn't happened so far. > > (Remember that, although binary diff programs exist, they're > > just storage optimization unless a diff between two > versions of a file > > can be patched into a third and still make sense.) > > _Me_ remember _that_? I'm the one that's been trying to teach people > that fact for nearly a decade now! That's part of the whole > point _here_! > No, that's not part of the whole point. If it was possible to do diff3 on certain binary files, and CVS didn't, then other systems could do better than CVS in that regard. (This is apparently true of MS Word files.) That would be part of the point. For things like icons, there is no feasible diff3 short of giving the versions to the local artist and telling her to come up with something that reflects both changes. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS and Jar files: Should you import Jar into the Repository? Why or why not
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > [ On Tuesday, March 5, 2002 at 21:52:00 (GMT), Richard Caley wrote: ] > > > > I know it (even processsed them a couple of times), but it's > > irrelevent. Storing as diffs is just an optimisation, not a > necessary > > feature. > > It might not be a "necessary feature", but it's the way RCS files work > today and in combination with the forced concurrent edits feature of > CVS, it makes it nearly insane to try to track non-diff-able and > non-patch-able files! > Why? Lots of people on this list who appear to be sane have used CVS to track limited numbers of non-diffable files. The points to remember are (1) it works in CVS, although not as well as other formats do, and (2) there's nothing in general that's all that much better. (Remember that, although binary diff programs exist, they're just storage optimization unless a diff between two versions of a file can be patched into a third and still make sense.) > > Works better than the non existant alernative. > > There's an almost inifinite number of better alternatives -- some of > them have yet to be written, of course, but you shouldn't let > that stop > you. > I don't know about anybody else, but my projects right now do not include writing a system better than CVS. If I were to do that, it would take a large amount of time, and I really doubt I'd make that back. (I don't know how SubVersion will handle non-mergeable files, but I'd rather get some work done now rather than wait and do nothing useful until it's ready for prime time.) > > Feel free to propose an alternative, if it's better everyone will be > > happy to hear. > > I did already -- and I've used it flawlessly many times > myself. Others > have proposed almost exactly the same concepts too. Multiple times. > The alternatives you propose tend to be on the order of using some other versioning system in parallel, which really doesn't give much more functionality than CVS, requires additional administration and training, and give a lot more opportunity for making mistakes than just keeping binaries in CVS. While you may be able to use it flawlessly, that seems to me more testimony to your ability and knowledge than a recommendation for general use. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS and Jar files: Should you import Jar into the Repository? Why or why not
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 05, 2002 2:02 PM > To: Christian Andersson > Cc: CVS-II Discussion Mailing List > Subject: Re: CVS and Jar files: Should you import Jar into the > Repository? Why or why not > > > > Good one, I use that a lot :-) > > and I also use a knife as a screwdriver a lot too :-) > > No, neither analogy is in any way "good". > Why not? > With CVS and non-diff-able, non-patch-able files we're talking about > using a tool that's not even remotely suitable for the job at hand. Why? CVS doesn't handle non-mergeable files well, but it doesn't really do much worse than systems purposely designed for them. It's less efficient, because it's optimized to handle mergeable files, but that doesn't mean it's unusable. You can keep track of the files by date and tag. You can branch them. You can't do concurrent development or branch merging. While these are excellent reasons to use CVS for mergeable files, they aren't necessary to use CVS in a more primitive fashion. > Meanwhile if you want to do things efficiently and effectively (one of > the very reasons for using version tracking tools in SCM in the first > place) then please try to learn to use the right tool for the job. > What if there really isn't a right tool for the job? Then what do you do? Go back to bed and cry all day? I'd rather find a usable tool, myself. CVS works very well for mergeable text files that don't need to be renamed. It works less well for non-mergeable files, and doesn't handle renames at all well. This doesn't mean it can't or shouldn't be used for limited numbers of non-mergeable files and renames. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: can rtag on an existing branch?
-Original Message- From: Rajesh Patwardhan [mailto:[EMAIL PROTECTED]] But if I am sure what I want to tag is on the repository and I use cvs rtag -D"Now" tag_name module Does it have any disadvantage? Regards, Rajesh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Dan Walter writes: > > Do I have to learn how to use the tag command instead of the rtag command > to do this? Absolutely. You should almost *never* use rtag without a -r argument because there's no way to know exactly what revisions you're tagging. The tag command tags exactly the revisions you have checked out in your working directory. -Larry Jones I hate it when they look at me that way. -- Calvin ___ The problem is that you normally don't know exactly what's in the repository right now. If you're sure that the repository is in the right state, and that nobody is checking anything in, this will work. Usually, it's easier to check out what you want and use "cvs tag" than to make sure the current state of the repository is just right. After all, you usually want a checked-out copy to verify that the release is suitable, and you can tag from there. BTW, your reply was in HTML. It's better to avoid HTML on a list like this, and in particular replying to a plain-text message in HTML is a bad idea. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Adding an existing file to a branch
> -Original Message- > From: Jake Colman [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 28, 2002 6:33 AM > To: [EMAIL PROTECTED] > Subject: Adding an existing file to a branch > > > > I have somes files that already exist in the trunk and in a > few branches. > I now need to bring those files into an already existing > branch. How do I do > this? Do I simply copy those files from elsewhere into that > branch's sandbox > and then add the branch tag to those files? > A file is on a branch if it has the branch tag, and that branch tag doesn't point to a dead version. All you really need to do is "cvs tag -b " from anywhere cvs can find the filename. Don't forget to add merge tags or branch point tags or any other such tags that are standard at your shop. Note that simply copying the file won't necessarily tell CVS what file it is, and that checking it out from where it exists and adding the branch tag will not update the sticky tag. If you do this in the branch's sandbox, update it to the branch tag afterwards. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Software Position
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 27, 2002 3:42 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Software Position > > > Dan Twyman writes: > > > > I found your organization while searching the internet for > companies that > > produce software for hand held computers. After reviewing > your web site, I > > became interested in working for you. > > Bull. CVS is open source software -- it is not produced by a company, > and it does not run on handheld computers. You might have more luck > finding work if you actually did some research instead of just > pretending to and quit lying to potential employers. Now go away and > quit spamming mailing lists. > So would anybody want a PalmOS CVS client? (Considering that my Visor seems to want to be a computer peripheral, I suspect not.) Anyway, reading further, we find that he mentions a website for some shareware he's written. I'd therefore suspect him of disguising some commercial spam, IMNSHO a more heinous act than spamming for employment. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: refactoring when using CVS
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 26, 2002 3:23 AM > To: Mark A. Flacy > Cc: [EMAIL PROTECTED] > Subject: Re: refactoring when using CVS > > > [ On , February 26, 2002 at 01:57:19 (-0600), Mark A. Flacy wrote: ] > > Subject: Re: refactoring when using CVS > > > > Of course, from your very own web page you state... > > > > However I have so far resisted any temptation to learn anything > > significant about any of the bastardised half-breed > languages such as > > C++, Perl, etc., or even most of their ill-begotten > offspring such as > > Java, C#, etc. > > > > ...so it doesn't surprise me very much that you have such a > uninformed > > opinion on the matter. > > Learning the details necessary to program successfully in a given > language does not mean that I don't know far more than enough > about them > to have a very _informed_ opinion on them and their usage. > My opinions > on those matters are in fact extremely well informed. > No they aren't. You cannot possibly have extremely well-informed opinions on languages you have never worked in. You can have interesting opinions, correct opinions, or even useful opinions, but not extremely well-informed ones. The *only* way to get an extremely well-informed opinion about a language is to work in it. Had I never had to do a term project in Common Lisp, I would have continued to have a woefully bad opinion of it. Have you read Stroustrup's "Design and Evolution of C++"? If you have not done that, or worked with a standard implementation, you don't know beans about C++. Similarly, if you haven't done anything in Perl, you won't know how easy it can be to get something working fast. (It isn't nearly as good for large projects, and it is necessary to be careful or the code will become unreadable, but I've got perfectly readable and understandable Perl programs of over 300 lines.) You give examples of bad software written with C++, and indeed it's possible to write bad software in it. My experience is that it's possible to write bad software in any language, including assembly, Fortran, BASIC, COBOL, C, C++, Common Lisp, Scheme, Pascal, and Prolog. Doubtless it's possible to write bad Smalltalk also; that language is on my "learn sometime" list, but I'm rather busy at the moment. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: questions on CVS, WinCVS
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > [ On Monday, February 25, 2002 at 21:06:40 (+0300), Leonid > Krutyansky wrote: ] > > I have WinCVS 1.2 client , CVSNT 1.11.1.2(41) server and > run pserver protocol. > > Oh, that's too bad. You should think about building a Unix-based CVS > server and about using SSH for client access > I *think* CVSNT is committing to pserver as an access mechanism. I don't think it's a good idea, for security reasons, but then I would prefer Linux or one of the *BSD for security in any case. For security, it uses NT-based authentication, which probably means not using Unix or Macintosh clients. It looks to me like CVSNT is diverging fairly rapidly, and is going to be much less useful in some environments, for example the free/open source software movement. While it may be more suitable in some other environments, I don't know how much longer this list is going to be useful for CVSNT users. > > I see that the server is not supporting "admin -l" and > suggests "edit > > -c" instead, but it looks like "edit-c" and "commit -c" are not > > supported by the client! > > CVS really does not work well for reserved checkouts. Perhaps you > should be looking for some entirely different version control tool. > CVSNT is being developed by people who seem to favor reserved checkouts more than the CVS people. Not to my taste. > > 2. How can I have really secure connection with CVS server through > >Internet. Am I right that Kerberos is not working with WinCVS > >client ? What about security with ntserver protocol, and what is > >VPN? > And here we get to a point where there are so many differences between CVSNT and CVS that there's no point in trying to discuss both. I believe that the proper response on this list is to suggest that Leonid Krutyansky should either convert to using standard CVS on a Unix box (presumably Linux or *BSD) or should go to http://www.cvsnt.org and join the mailing list there. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS Update Behaviour
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > [ On Monday, February 25, 2002 at 00:17:58 (-0800), Paul > Sander wrote: ] > > Subject: Re: CVS Update Behaviour > > > > Renames are not usually a requirement of maintenance, but they are a > > requirement of new development. Bug fixes are done during > maintenance, > > and merged into new development. That means that bug fixes > > It is extremely rare for bug fix merges to work automatically with CVS > commands alone, with or without any renames getting in the > way. It is? It is possible that we have different sorts of bugs than those you're familiar with, but we find that bug fixes often merge very nicely without manual handling. This is important; our business mandates that we maintain different branches for different customers. (We have few and large customers, compared to many other software houses.) Obviously, this will not work when files have been renamed, but in that case the changes between versions are likely to be so large that it really doesn't matter. In many cases, the bug has been removed in the redesign anyway. > huh? what do vendor branches have to do with this? If you don't > understand that you have to manually move changes between files that > have been renamed by the vendor then you should not be > messing with such > complicated things that you do not understand. > It seems to me that the question is not understanding, but whether it is desirable. It would be nice if CVS would track vendor renames, but it would have to be able to figure out vendor renames, and in any case the sources we track tend to be kept in CVS anyway, so the supplier is unlikely to rename things gratuitously. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: refactoring when using CVS
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 22, 2002 4:09 PM > To: Noel Yap > Cc: CVS-II Discussion Mailing List > Subject: RE: refactoring when using CVS > > > [ On Friday, February 22, 2002 at 07:12:39 (-0800), Noel Yap wrote: ] > > Subject: RE: refactoring when using CVS > > > > --- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > > > CVS is not and has never been very useful for > > > initial development under > > > any methodology that doesn't involve sharing of the > > > code under > > > development (and sharing in a non-XP manner!). > > > > I disagree. > > then you are, sadly, disillusioned, and perhaps that explains why you > don't always grasp how to make effective use of CVS. > I don't quite understand this. I use CVS at home, where I don't share development, and have found it convenient to use in initial development. Certainly I don't use many of the features of CVS that way (although I do some concurrent development, making fixes both on the Mac and the Linux box). I consider it useful as a way of keeping track of the state of the code and sometimes tying certain changes into certain features I'm adding. Granted, it's more useful when I actually do a release, but I certainly wouldn't say it's not very useful in initial development by one person. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: refactoring when using CVS
> -Original Message- > From: Noel Yap [mailto:[EMAIL PROTECTED]] > Other than theoretical attacks found by acadamecians > (that I think were later fixed) and possibly holes > within Visual J++, I haven't heard of any > insecurities, can you point me to a site, please? > In the US, under the DMCA, it is impossible to legally post a proof of insecurity, and people have indeed been sued for demonstrating that security vulnerabilities are practical and not merely theoretical. This means that any company can claim perfect security, and can ignore reported vulnerabilities by either claiming they are only theoretical and could not happen, or by asking for a cease-and-desist order to shut up the person showing otherwise. Therefore, vulnerabilities can only be properly discussed in illegal communities, or in countries with rational copyright laws. Therefore, also, I have no personal faith in the security of any product sold in the US that is not open source, and even that is a bit iffy. So, just remember that it will often be futile to ask for credible sites showing insecurities, unless you are active in illegal cracking organizations. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: refactoring when using CVS
> -Original Message- > From: Noel Yap [mailto:[EMAIL PROTECTED]] > AFAIK, XP promotes "Refactor early, refactor often." > If so, and given Greg's premise that refactorisation > should be rare and well-thought-out, then CVS isn't > good for within an XP environment. > No, it doesn't mean that. It may mean that Greg shouldn't use XP, but then the XP originators were emphatic that it wasn't the right way to program for everybody. If XP basically requires shuffling files around, then it really won't work well with CVS. If it's a matter of changing the stuff within the files, it should work well. Just commit after each refactor. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS client on a Mac OS 9
> -Original Message- > From: Pham, Khiem [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 20, 2002 11:50 AM > To: [EMAIL PROTECTED] > Subject: CVS client on a Mac OS 9 > > > Hi anyone, > I have a setup question if anyone can help me. I have CVS > running on NT > server with ntserver authentication, so you do not need to > log in from a CVS > client. I have CVS clients running from other NTs and they > are working > perfectly. CVSNT is going its own separate route from CVS. I'd suggest consulting their mailing list. Now I have been trying to run CVS client on a Mac > OS 9 with one > of these four: jCVS, MacCVS Client, MacCVSPro, CVSWeb with no > success. I notice that you left out MacCVS. This is part of the WinCVS project that apparently is falling in love with CVSNT, so that might be better suited for your desires. None > of these four client have a setup for ntserver authentication and all > mention CVS server on a Unix platform. The only > authentication method I saw > was pserver, ssh, rhosts which not recommended for NTs. I suppose that's fair; I don't know that any of us on this list would recommend using an NT as a CVS server. In general, given a barely adequate NT box, you should be able to install Linux and have plenty of capacity, using standard CVS, and it should be more reliable. Any > ideas how I can > get a CVS client to work on a Mac? Thanks a whole bunch... > I have plenty of ideas how to get a CVS client to work on a Mac. I use MacCVS at home quite successfully, and the others you mentioned would probably also work just peachy. However, that's not what you asked for initially. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: refactoring when using CVS
> -Original Message- > From: Noel Yap [mailto:[EMAIL PROTECTED]] > > Refactoring in C could just as easily leave you with > > a whole lot of > > deleted files and a whole lot of new files. > > The difference is that as a language, C doesn't demand > such changes (ie renames and moves), while Java does. > Yup. In that respect, I consider Java broken. > > There you have it, yet another space where CVS isn't > ideal: XP. > No, XP in Java. The original XP people used Smalltalk, a dynamic object-oriented language, and I'd think that XP would work best when using a dynamic object-oriented language such as Smalltalk and Common Lisp. Doing a quick Google search shows that people are talking about XP in Java, and selling stuff to support it, but that doesn't mean it's a good idea. So, if you're going to use a language that is unduly chummy with the file system in a role to which it isn't really suited, CVS may not be the right version control system to use. Ah, yes, software engineering defined as "knowing the right wrench to hammer the screw in with". ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Locks
Title: Locks -Original Message-From: Jasmeet Singh Virdi [mailto:[EMAIL PROTECTED]]Sent: Thursday, February 21, 2002 7:46 AMTo: [EMAIL PROTECTED]Subject: Locks Hi all, ne pointer on how to impliment LOCKS in CVS for NT server on a win2K box, with only windows clients. thanx -js [Thornley, David] If you're asking for such a pointer, go to http://www.cvsnt.org and check out what they've got there. There is apparently a mailing list for CVSNT, and you'd get a lot more help there than here.
RE: Converting ClearCase to CVS
> -Original Message- > From: Eric Siegerman [mailto:[EMAIL PROTECTED]] > > On Tue, Feb 19, 2002 at 05:04:54PM -0500, Greg A. Woods wrote: > > You either chose the wrong tool for your requirements, or > you chose to > > use it in a way that it was not designed to be used. > > Geez, that's just what Paul's been saying all along! It's > everyone else that's been treating his defence of ClearCase as > rank heresy. > No, I'm not saying ClearCase is a bad product (I don't know enough to know if it's a good one). I'm saying that Paul consistently claims costs for using CVS that are tremendously beyond my experience, and the experience of anybody on this list who's bothered to comment. Moreover, if CVS was the administration burden Paul claims, there's no way so many open source projects could be using it. It's not heresy at all to say that ClearCase can do things that CVS cannot, although it's legitimate to argue about just how important those things are. It's not heresy to say that CVS is a lower-end product than ClearCase. (It's by far the best product I've ever used, but I don't have nearly the experience with different version control systems that many of the regulars have.) However, Paul claims that the cost to use CVS is comparable to the cost to use ClearCase, and I find that unbelievable. He doesn't specify certain uses or environments, but seems to make the claim overall. Since the costs, by his assessment, make the use of CVS uneconomical in most cases (including very many where it is successful), this is seen as falsely denigrating CVS, and on a CVS list this is going to provoke people. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: point of fork
> -Original Message- > From: Alex Wiesmaier [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 19, 2002 7:42 AM > To: [EMAIL PROTECTED] > Subject: point of fork > > > hi > > i have several branches in my cvs. now i have to tag a > version at which a > certain branch was forked from the main trunk. so does > anybody know how to > retrieve a point of fork version? it will be very hard to do > this by using > the date because several subdirectories have been joined to > the branch at > different times. > You'll probably have to go file by file (if there's more than about three files to process, I'd write me a Perl script to do it). After all, if you didn't tag it in the first place, and can't use the date, you've got nothing global to use. Do a cvs stat -v on each file, and find what the branch numbers are. They'll be in a form like 1.32.4 or 1.23.6.34.2. Drop the last number (resulting in 1.32 or 1.23.6.34) to get the revision where the branch was forked. (If you're *sure* the file has been changed since the fork, you can drop the last two numbers of the revision number, but that's usually not the case.) These numbers will normally be different for each file. Once you've found the branch point for each file, put the tag there. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Converting ClearCase to CVS
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 19, 2002 12:45 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: Converting ClearCase to CVS > > > Starting to get off-topic and long-winded, but I can't let > this go. Sorry! > > First of all, I am a CVS expert: I have been using it for > over ten years > and I have a credit as one of its contributors. I have also made many > more changes to it that never went into the general distribution, for > many reasons. Some of them were very intrusive, affecting > CVS' internal > APIs. > > Second, I did pay someone: me. I supported CVS professionally for > my (former) employer for four years. > OK; presumably you could have found somebody else. The point is that comparing the deployment of CVS with zero money to the deployment of ClearCase with the money Rational charges is not useful. Comparing the deployment of CVS with money allocated, or at least tracked, is useful. (I have been on the periphery of one of those "Buy this system for X thousand dollars and you won't need DP support" sales pitches, which was successful. It turned out all right in the end, but the user department really hadn't planned on supporting four full-time developers.) > >Having source code doesn't mean the software is perfect, but it does > >mean that you can get independent and customized support. Moreover, > >it means you can sometimes get exactly what you need added to the > >base distribution. > > Yep, and I provided it. And again, having source code doesn't make up > for a broken design. We never should have deployed CVS, but I was > overruled. And afterward, I did the best I could by adding > the features > we needed that could be accomodated by the design (plus fixing many > that already existed but were broken). > Let me digress. My experience in having my car taken care of is that, if you take it to one of those independent shops that does nothing but repair cars, they do a good job at a reasonable price. A dealership or gas station may be making their money from their primary business, and a member of a chain can to some extent rely on advertising and chain reputation. An independent specializing in car repair has to do a good job or it's out of business. Similarly, I would think that, if you were to hire a CVS expert, that person would likely know CVS. After all, that person gets money for doing things with CVS, whereas a software vendor typically gets money for selling product. > You're right on this count. The people who demanded that CVS be used > preferred to support the hidden costs of maintaining CVS versus the > outright expenditures for licensing and maintaining a > commercial solution. > Some managers will happily spend lots of money on a commercial product, but would not spend a dime (explicitly, anyway) on an open source product. This leads to bad accounting. Similarly, some managers hate to spend money and will gladly waste their employee's time, and this also leads to bad accounting. Nobody who isn't willing to figure what free software is actually going to cost is going to make a rational decision. Sometimes open source is the way to go, and sometimes it isn't, and lots of enterprises simply don't deal with it rationally. > In the end, my employer was happy enough with CVS to live with it for > three years after I left. Then management turned over, and > they converted > to ClearCase. > That may have been the right decision, or may not have been. > But the comparison is simple: You have $X. You can spend it on a > commercial solution or you can get CVS and support it yourself (hiring > someone if necessary). Which is more cost-effective? I > contend that the > CVS approach costs as much as a commercial solution. > This is contrary to my experience. Right now, we've got a few score developers using CVS. We've got it set up on a server, and I spend maybe 1-2 hours a week on a continuing basis. Every so often, such as when it's time to upgrade or revise the scripts, I spend a few days. Figure we spend maybe 200 hours a year supporting it. That may be enough to cover a lower end commercial system (particularly if you ignore its hidden costs), but certainly not enough to set ClearCase up. We do of course develop concurrently, and we make heavy use of branches. > Actually, I've been a CM specialist for almost 15 years, and I have > developed commercial CM tools in the past. If my salary were equal to > the license fees of some commercial CM products for 75 users, and if I > could work on it full-time and uninterrupted, I could produce > a version > control system single-handedly in a year's time. It would be robust, > though not as feature-rich as some products (but it would > compete favorably > with CVS). But I've already put in my time and have no > desire to do this; > too many other projects beckon right now. > OK, I underestimated yo
RE: Converting ClearCase to CVS
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > >[ On Saturday, February 16, 2002 at 12:42:57 (-0800), Paul > Sander wrote: ] > >> Subject: Re: Converting ClearCase to CVS > >> > >> You get what you pay for. In my opinion, the quality of > implementation > >> of ClearCase is much more robust than CVS, and Rational > supports it much > >> better anyone supports CVS. > > Greg: > > >Have you ever paid anyone to support CVS with the same > amount of money > >you have pay for licensing _and_ support of ClearCase? I'll bet you > >would get better support for CVS than you could ever get for > ClearCase. > > Well, yes and no. > > I have not ever paid anyone to support CVS but rather did it myself. > I discovered that having source code doesn't make up for a broken > design, and that I have better things to do than to keep fixing basic > things (like signal handling so that ctrl-C doesn't break things, > various instances of memory mismanagement, and useful access control) > and adding hooks that I needed for larger systems. > In other words, no. Not "yes and no". You have not paid anybody to support CVS, but have rather chosen to do it yourself. I don't know how much you would pay for ClearCase license and support, but I would think you could hire at least a part-time CVS expert to deal with such things. After all, you do it on a part-time basis. Having source code doesn't mean the software is perfect, but it does mean that you can get independent and customized support. Moreover, it means you can sometimes get exactly what you need added to the base distribution. Your mistake is that you tried to get too cheap with CVS. Had you been willing to spend even a moderate amount of money, you would have been happier. You almost certainly could have been much happier with CVS while spending only a fraction of the ClearCase money. This doesn't necessarily mean that CVS is the right answer, but it shows that your comparison is based on false assumptions and is meaningless. > Given the status quo, I can either buy a commercial system that has > industrial robustness and support, or I can build it myself. In the > end, the same capabilities cost just as much either way: The money > goes to my salary to build it, or it goes to a salesman. If it goes > to the salesman, then I get many more man-years of robustness and > polish with a system that can be deployed much more quickly. > If you think you can write an industrial-strength system as cheaply as you could buy one, I think you're putting an astonishingly low value on your time. The proper thing to do is to leverage off other people's work, either commercially (by buying a product a company is selling to many other people) or in open source (by taking advantage of other people's work). > >In terms of support there are no advantages to being one of the many > >ClearCase users that are not also advantages of being one of the many > >CVS users. While Rational may have more long-term dollars > to put into > >research and development than has been or ever will be put into CVS > >research and development, that's not necessarily an advantage for > >ClearCase either. Free software does not have to fight for > market share > >by adding useless, and/or confusing, and/or buggy features. > > One would hope that a competent designer of quality software doesn't > introduce any of these things. Do you realize how much software you have eliminated? Feature lists are what sells most software. It's unfortunate, but it's true. It's much easier to evaluate software by the length of the feature list than to figure out whether it's secure, robust, and reliable. While it's true that most users don't > use every feature of any system, it's still possible to measure the > utility of features across the customer base. And companies don't > usually add features to their products unless there's great demand for > them. In contrast, features may be added to free software if only one > user calls for them... > Having worked in commercial software, and purchased commercial software, you are at least not completely correct. I've helped put in lots of features *into commercial software* because one user wanted them. In the case of shrink-wrap software for personal computers, the feature list is treated as critical for sales. Your statements may be true of certain sorts of commercial software, but without such qualifications they are unconvincing. > As for whether or not a feature is confusing, RTFM. > My experience with documentation is as follows: 1. For shrink-wrap PC products, the docs are usually useful but tedious to use and incomplete, since I'm not the archetypical buyer or user of such. 2. For higher-end commercial software, the docs vary very widely in quality. Some are good and some are dreadful. 3. Open source docs also vary, but in my experience are overall better than their counterparts in (2) above.
RE: Hierarchical team integration in CVS
> -Original Message- > From: Earl Williams [mailto:[EMAIL PROTECTED]] > > "Pierre Asselin" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Adapt your tree structure. Do *not* mix files from teams A > and B in a > > single directory, CVS won't handle that well. > > Hi Pierre, > > Thanks very much for your detailed suggestions. It seems > that in order to > use CVS, the directory structure of my project must be driven > by short-term, > division-of-labor-during-development concerns (Team A, Team B, Shared) > rather than by the conceptual structure of the classes in my > project. Too > bad. I guess I need to learn more about Software > Configuration Management. > To be specific, that is the case if you are determined to use CVS and no other tools for software configuration management. If you have been taught that no more than one tool should ever be necessary, then indeed you need to learn more. The Unix philosophy is to create tools that do one thing very well, and to combine those tools as needed. In accordance with that, CVS does some things very well and some other things not at all. This is sometimes inconvenient, but such things as working with the exact specific tools somebody else thought was exactly what you needed (or what you were going to get, anyway) can also be inconvenient. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: using head revision in branch after add on branch
> -Original Message- > From: C. Wienberg [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 13, 2002 4:07 AM > To: [EMAIL PROTECTED] > Subject: Re: using head revision in branch after add on branch > > > Hi Greg, > > > > You can only check them in into _one_ module. > > Of course -- that's about the only way you'll ever make any kind of > > change management system make sense! > > I think there is a misunderstanding: I do not intend to check > one file > into several modules! I just want to check in different > files, that are > in a common _folder_, into different repositories! > Nope; not in CVS. It would take a major redesign of CVS to make this possible. > > > If we have one module for common stuff and one with > specialties, that go > > > into the same directory, we have a problem. > > Huh? Nope. Not a problem. The source modules are each checked out > > into their own working directories. Your build system combines them > > into the common target directory. > > Well, so far we have very successfully been working using branches, > without the need to have an additional build system, like ANT. > Also, I do not think that what we do is an abuse of the > branch concept, > or that my request is perverted ;-). > I wouldn't call the desire perverted, but CVS alone isn't going to do what you want, and probably never will. This is unfortunate, since the easiest way to test things is often to change them in the working directory rather than to change them elsewhere and run make/ANT/whatever, but it is a characteristic of CVS. All files managed by CVS that are checked out into one directory must be in the same directory in the same repository. If you don't like this, your choices are basically: 1. Check the files out into separate directories and use some sort of build process to put them in the working directories. 2. Bash your repository until all the files are in the same repository directories (which obviously may not be possible, such as if you're using other people's repositories). 3. Bash your working directories so that they work the way the repository is set up. 4. Use another version control system (which, if you're using other people's repositories, may also not be possible). 5. Modify CVS extensively on your own (bearing in mind that your changes are almost certainly not going to become part of mainstream CVS). There is no guarantee that any of these options are attractive, but I don't see any alternatives. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: how to change a rev number
> -Original Message- > From: Shane McDaniel [mailto:[EMAIL PROTECTED]] > > > I accidently checked in a file with the wrong rev number. > How do I go > > > about changing the rev number in the DB? Is there an > easier way than > > > checking the rev out, removing it from the DB and putting it > > > back with the > > > new rev? > > > > > The right answer is to stop thinking about the rev number and just > > apply a tag when you want something you can refer to. Leave the > > revision numbers to CVS. > > > point taken. but then what is the use of having a hierchal > rev number if > tags are what one should use? wouldn't cvs just use an incrementing > number ie 1,2,3,4 instead of 1.0.1,1.0.2,etc.. > The reason is historical. Originally, CVS was a set of wrapper scripts over RCS, and CVS continues to use the RCS format of save files. (There's advantages there.) One intended successor to CVS, Subversion (http://subversion.tigris.org/index.html), does use sequential numbers for its revisions. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: how to change a rev number
> -Original Message- > From: Shane McDaniel [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 06, 2002 9:56 AM > To: [EMAIL PROTECTED] > Subject: how to change a rev number > > > > I accidently checked in a file with the wrong rev number. How do I go > about changing the rev number in the DB? Is there an easier way than > checking the rev out, removing it from the DB and putting it > back with the > new rev? > The right answer is to stop thinking about the rev number and just apply a tag when you want something you can refer to. Leave the revision numbers to CVS. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: DIfferent workspace directories than repository...
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 30, 2002 10:19 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: DIfferent workspace directories than repository... > > > > > > Um, why do you need this specific layout in the > > repository? It seems to me that the structure of > > the repository should be determined by the structure > > of what must be checked out. > > Some would disagree with you on that... myself included. I > was hoping that I could get CVS to treat a directory as a > true project/first-class object. Not just as a directory. > Nope; CVS does not treat directories as first-class objects, and is never likely to. Doing that would require a thorough redesign, and would not be likely to be called CVS afterwards. > Check out the Tigris project (www.tigris.org) which is > addressing these kinds of issues that CVS apparently doesn't meet. > Subversion (the SCM project at Tigris) is indeed intended as a thorough redesign of CVS, taking advantage of years of experience with CVS and its quirks, and is intended as a CVS replacement. Last I looked, it looked promising, but not something I have immediate use for. > Well, that answers my question. It can be done, but with > manual kludges involved. I was hoping to avoid such things. > I do lots of things with Perl to make CVS easier to use. I can get lots of the quirks papered over that way. Overall, I find that CVS's reliability, support of branching and concurrent development, and cost make it an extremely useful tool, although far from ideal. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: DIfferent workspace directories than repository...
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 29, 2002 10:50 PM > To: [EMAIL PROTECTED] > Subject: DIfferent workspace directories than repository... > > > Hope I can get some help here... > > I've used CVS for awhile now, but I have never really had to deal with > different workspace locations for repository directories. But I > actually need this now. Here is an example of the repository layout I > need : > > + myproject > | > + bin > | > + lib > | > + html > | > + src > | > + docs > Um, why do you need this specific layout in the repository? It seems to me that the structure of the repository should be determined by the structure of what must be checked out. (Not to mention that I'm always at least a bit suspicious about CVS-controlled directories called "bin" and "lib".) > Here is an example of the workspace layout I need : > > + /home/myhome > | > + mydirectory > | | > | + bin > | | > | + lib > | > + html > | > + src > | > + docs > > Is there anyway that I can map a CVS directory and assign it a > specific workspace directory? I'm really hoping I can do this, > otherwise I may have to dump CVS in favor of another SCM tool. And I > really don't want to. But this one is a show stopper. > CVS will use the identity map when checking out, but afterwards each directory has its own metadata (in the CVS subdirectory) so that it knows where it came from. This means that it will retain the mapping while you move the directories around on your own. Therefore, if you do something like "cvs co bin; mkdir mydirectory; mv bin mydirectory/" you will still be able to do updates and checkins from mydirectory/bin. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: URGENT: Initial revision number for CVS.
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 28, 2002 8:46 AM > To: [EMAIL PROTECTED] > Subject: Re: URGENT: Initial revision number for CVS. > > > I have a similar problem. At our company we have Sources that we want > to put under CVS control. Some of the sources are already RCS > controlled, so copying the *,v file directly into the repository seems > to be the right approach for us. The history is preserved and > we get the > revision numbers that have been created by RCS (which all have the > syntax x.y, let's call this depth 2). > OK, no problem with that. > No, importing the other, non RCS-controlled sources has the same > effect that you describe. All files get the revision number 1.1.1.1., > so the depth here is 4. > OK, no problem with that. > We really do not need the depth 4 revision numbers and want a default > revision number depth of 2. I have searched all the CVS manuals, > Google and other written resources, but found no answer to this > question. > Correction: if you're doing a "cvs import" you do need the depth 4 revision numbers, and that's not just because CVS does it that way. In imports, CVS maintains its own import branch, and since it's a branch it needs depth 4. Depth 2 revision numbers are only on the head branch, and in an import situation are for your own changes. Let me be more specific. It may happen that you import a codebase and maintain local changes to it. We do it with Gnats. In that case, CVS has to have a way of keeping track of the changes in the imported source versus the local changes. CVS keeps track of such things with branches, and so you need branches, and so you need the revision numbers you're complaining about. If you aren't importing somebody else's source, but you're bringing in source that will be developed from the CVS system, then you can use "cvs add" instead of "cvs import". > Has anybody an answer that is other than "don't care about the CVS > revision numbers, use your own scheme with the use of tags" ? > What other answer is needed or accurate? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: race condition?
> -Original Message- > From: David Hugh-Jones [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 22, 2002 11:38 AM > To: [EMAIL PROTECTED] > Subject: race condition? > > > > One of our developers pointed out that > > cvs commit foo bar > followed by > cvs rtag I_just_uploaded_this foo bar > > contains a race condition. Someone else might have committed > between the two > tags. > > Assuming we want to use tags as a way of assigning blame, is > there a way > round this? > I'd use "cvs tag", not "cvs rtag", since "tag" tags the revisions in the sandbox, not the repository. As long as your developer doesn't update between the commit and the tag, the tag should get exactly what he or she had then. If your developer wants to tag things that existed at that moment but which were not in the sandbox, you can always use "rtag" followed by "cvs tag -F" to force the tag to move to what's in the sandbox. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Basic usage question
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Sunday, January 20, 2002 9:01 PM > To: [EMAIL PROTECTED] > Subject: Re: Basic usage question > > > In article <[EMAIL PROTECTED]>, Wade > Williams wrote: > >Myself and another programmer are working on a project. > We're working > >mainly on different sections of the code. > > > >Day 1: I checkout the project > >Day 2: I make changes and commit them, and then continue > working on my > >working copy. > >Day 3: Programmer B makes changes and commits them > > If B does a module-level commit, then B's commit attept > should fail with > the ``up to date check failed'' diagnostic on files that you > commited on > day 2, assuming that B did a checkout before day 2, and has > not updated > since then. Thus B is forced to update to incorporate your > changes via > cvs update, resolve any conflicts and try the commit again. > Right. I understood this to mean that there were "cvs updates" as needed, although the original poster may not have been aware of these details. Basically, you can only commit changes if your files have been updated to the head or branch tip or something, and if changed have been checked in you'll have to run an update. If there is a conflict, that'll be mentioned in the output and kept as the file status, and you won't be able to commit your changes until you've dealt with the conflicts somehow. (There was an exchange a few months ago about what does and should constitute dealing with the conflicts, which need not be repeated now.) It is possible to merge changes to create an incorrect source file without causing a conflict; one easy example would be one programmer removing a member function from a class, with another one introducing a new use of it. In practice, this turns out to be unimportant, since such problems are readily found. > If people cheat by committing only the files that they modified, they > can get around the up to date check. But that is a bad idea because > the changes you make in one set of files can semantically > conflict with > changes in another set of files. Do you mean "updating only the files that they modified"? If so, that's a bad idea as you say, but it seems to be somewhat self-correcting. People get themselves into trouble that way, and soon find that it's easier in the long run to update everything. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Validate html file before to commit.
> -Original Message- > From: Franck Marchand [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 03, 2002 5:14 AM > To: [EMAIL PROTECTED] > Subject: Validate html file before to commit. > > > Hi all > > Someone has a script to check a file before to commit it in cvs ? > > I would like to do something like that : > > CommitInfo file : > DEFAULT $CVSROOT/validate-html > > I need a file which be able to read the new file and check it > if it contains > correct html tag. > Do you have a validation program? You can use that, with some setup. One thing I ran into when I tried adding complicated validation to the CommitInfo file was that the time needed to commit slowed to what would be unacceptable limits if committing in multiple directories. If validating the file is going to take inconveniently long, you might want to use LogInfo to validate it later, and then send out some sort of email, such as a notification to the manager or a termination notice or something like that. Seriously, if you can't trust your employees to follow process, you should get new employees. Establish that employees validate first, then commit, and test if you like after the commit (because people do make mistakes), and that should be enough. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: 1.9MB attachments (was Re: Wincvs download)
> -Original Message- > From: Marcel van der Boom [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 20, 2001 10:29 AM > To: Scott McDermott > Cc: [EMAIL PROTECTED] > Subject: Re: 1.9MB attachments (was Re: Wincvs download) > > > Configuring the mailing-list to limit or forbid attachments would be > better IMHO. > > time for a blacklist entry :) > On the other hand, it's sometimes useful to attach small things, like perl scripts. Unfortunately, some anti-virus filters seem to filter them out and complain to the list. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Possible modifications to CVS.
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 18, 2001 12:45 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Possible modifications to CVS. > > > [EMAIL PROTECTED] writes: > > > > Is it possible to checkout multiple files from different > directories within > > the repository and put them into a single directory? Can > CVS keep track of > > where each file came from and update the repository as necessary? > > No. CVS tracks metadata at the directory level, so all files in a > single working directory have to come from the same repository > directory. > It doesn't appear to be a problem to have sandbox subdirectories that don't correspond to repository subdirectories, since the subdirectories maintain their own metadata, but it's not going to work for files. > > If this isn't possible, I would suggest it be added to > CVS. What I would > > like to see is a way to check out files from anywhere in > the repository, and > > from any repository, and be able to put the files anywhere > I want in my > > working directory structure, and have CVS maintain the files. > > That would require completely redesigning and reimplementing CVS. > Anybody know how common this ability is in such systems? Subversion, in particular? In any case, you can always manipulate files after you've checked them out, so you can put varied files into one directory. You can't check back in from that directory, though, which is something of a pain. So, I figure that that would be a nice capability that isn't going to happen in CVS. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: ScanMail Message: To Recipient virus found and action taken.
-Original Message- From: System Attendant [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 11, 2001 8:49 AM To: '[EMAIL PROTECTED]' Subject: ScanMail Message: To Recipient virus found and action taken. ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = [EMAIL PROTECTED] Recipient(s) = [EMAIL PROTECTED];[EMAIL PROTECTED] Subject = Re: Unix/Windows CR/LF Problems Scanning Time = 12/11/2001 06:48:31 Action on virus found: The attachment commit_prep.pl matched file blocking settings. ScanMail has Deleted it. Warning to recipient. ScanMail detected a virus in an email attachment. [Thornley, David] This is not called for. The info-cvs list frequently has perl scripts sent around, and it is not reasonable to complain about it. It is reasonable to delete perl scripts from incoming mail if that is your desire. However, issuing email in HTML claiming to have found a virus is wrong and inconsiderate. (BTW, for whomever decided on the wording "ScanMail detected a virus in an email attachment", I'd suggest consulting a legal professional. That looks to me like it could be taken to be libel.) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs co error: "No space left on device"
> -Original Message- > From: Vinh Cao [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 07, 2001 11:59 AM > To: '[EMAIL PROTECTED]' > Subject: cvs co error: "No space left on device" > > > Hello All, > > Our Linux cvs server is working great for the pass two years. > For the pass couple week it has the error: > > "No space left on device" when my users are checking out or > do cvs update. > > CVS server has 1GB RAM and below is it partitions: > > FilesystemSize Used Avail Use% Mounted on > /dev/sda9 2.0G 91M 1.8G 5% / > /dev/sda1 23M 3.0k 22M 0% /boot > /dev/sda5 28G 5.2G 21G 20% /cvs > /dev/sda6 5.8G 213M 5.3G 4% /home > /dev/sda10197M 11M 176M 6% /tmp > /dev/sda7 2.0G 1.3G 517M 73% /usr > > I need your advice how to resolve this problem or what to do next. > > Thank you in advanced. > What caused that where I work is that the main source tree, which is a very large module, got close to the size of /tmp. CVS builds a source tree in /tmp, and if there wasn't enough room in /tmp it didn't work. What is the checked-out size of your largest module? If it's getting close to the 176M size of /tmp (which seems plausible, given the 5.2G size of /cvs), you may just be running out of /tmp space. What we did was to increase the size of /tmp and put in a cron job to remove anything in /tmp that was over a couple of days old. Since your /tmp is only 6% full, it looks like you don't have the slow filling-up problem we had, but you may need to enlarge /tmp. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Revision on a Branch
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 28, 2001 1:07 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Revision on a Branch > > > [EMAIL PROTECTED] writes: > > > > ex . I would like to update to ver: 1.4 on a branch 'br1' > > That doesn't make any sense -- revision 1.4 is on the trunk, > it's not on > a branch. > Ah, but it can be on a branch, provided that no revisions have ever been committed to that branch. In that case, cvs update -r br1 will bring up 1.4. If that's not the case, if for example the tip of br1 is 1.4.2.3, then it doesn't make sense. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Can we find all the branches on a module through some script?
> -Original Message-
> From: Jerry Nairn [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 26, 2001 4:34 PM
> To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
> Subject: RE: Can we find all the branches on a module through some
> script?
>
>
>
> > From: jsk-intoto [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, November 21, 2001 9:25 PM
>
> > based on the branch the user is working on. Can we obtain
> the branches
> > existing on the repository thru some script mechanism?
>
> cvs -nq log -h something | \
> sed -n -e '/^symbolic/,/^keyword/ {
> /[1-9][0-9]*\.[0-9][0-9]*\.0\.[0-9][0-9]*$/ p
> }'
>
> Will list all of the branches on something. The key thing
> here is tags which
> have at least four numbers, and the next to last number is 0.
> It occurs to me that this will not get those special branches
> created by
> imports.
> Jerry
>
It's also possible to parse the output of "cvs stat -v", which has
lines in the form of
TAGNAME (branch: 1.2.14)
TAGNAME1 (revision: 1.2.14.1)
In Perl, this would be something like
\s*(\w*)\s+\(branch: ([0-9.]*)
for branch names, with corresponding for revisions, with $1 being
the tag name and $2 being the rev number.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: A newbie question about branches
> -Original Message- > From: Elbert "Andrés" Messa "Díaz [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 20, 2001 7:23 AM > To: [EMAIL PROTECTED] > Subject: A newbie question about branches > > > I have a project under CVS version control. Right now > I am planning to make a dramatic change on a previous > release of the project, but I don't want > to affect the main trunk. > > I would think that it is appropiate to create > a new branch on that previous release, and make > modifications to the branch. > I completely agree. > Since I won't incorporate the modifications on the > main trunk, because both branches would be > irreconciliable, should I just keep the branch forever > and never merge? or is it worth it to create a > complete new project > starting on that previous release? > You don't have to merge branches for them to be useful. We split off a release branch for each release, and, while we will merge bugfixes to later branches and head, there's stuff we don't merge. You could create a complete project, but that would lose some history and probably increase the storage requirements (if you care about that). In addition, you'd lose the ability to merge bugfixes you find. In favor of a separate project, if you're going to be working on both branches indefinitely, it will take longer and longer to generate the tip of the branch. In my case, given a slow server and a 20,000 + line file with about thirty changes since the branch was cut and about thirty changes on the branch, it's noticeable. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS Sharing
-Original Message- From: Bryon Lape [mailto:[EMAIL PROTECTED]] >Ah, the typical Unix answer"roll your own"... If you would prefer the typical non-Unix answer, please send me a thousand dollars and I'll tell you the product doesn't do that. If you insist enough, for extra money I'll provide a patch that makes you go through additional hoops if you try anything similar. For enough extra money, I'll tell you it's a bug. (I've had experience dealing with commercial software support, and these are synopses of true stories. The names have been omitted to protect the guilty.) More seriously, if you would like somebody to write a script such as was designed, you can probably hire somebody to do it for far less than the cost of one ClearCase seat. You won't have to wait for the vendor to decide to do it, or negotiate with the vendor so you can pay an arm and a leg for the vendor to do it closer to your schedule. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS export
> -Original Message- > From: Lee Sau Dan [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 18, 2001 12:23 PM > To: [EMAIL PROTECTED] > Subject: Re: CVS export > > > This message uses a character set that is not supported by > the Internet Service. To view the original message content, > open the attached message. If the text doesn't display > correctly, save the attachment to disk, and then open it > using a viewer that can display the original character set. > This is how your message came across in Microsoft Outlook (no, it wasn't my idea to use it companywide). Posting in a form that people can't read is not going to help them respond to you. Please make sure you're posting in straight ASCII. Everybody can read that easily. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS & a Web site
> -Original Message- > From: Jason Purdy [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 17, 2001 3:22 PM > To: [EMAIL PROTECTED] > Subject: CVS & a Web site > > > > Hi, > > What is a good scheme of automating synchronization between a > CVS repository > and a Web site (or does a repository have to be separated > from the Web site > files [besides renaming the files from the ",v" suffix])? More than that is required. You will need to checkout or export the files, not just rename them from the repository. A > co-worker & I > have recently decided to work with CVS on our ever-growing > Web site, and I've > got CVS up & going, but lack an important piece of the puzzle > - getting data > out of the repository and into the Web site (hopefully in an > automated > fashion). > > I have a couple of ideas, but before I go down a road that's > surely been > traversed before, I'd love to get some input from the more > travelled on the > list. I hope there's already a solution for this scenario, > though I couldn't > find anything on the cvshome.org Web site or in a Google search. > > 2) Create 'trigger' scripts which would be triggered when the > developer > 'commit'ed their changes, which would also affect the changes > on the Web site > directories. > This is the correct answer, and the file you are looking for is commitinfo within CVSROOT. That file will specify programs to be run when something is checked in, and one to check out changed files and copy them to the web site should work just fine. Since you've been searching in the right place, you should be able to find the commitinfo material in the documentation. Sounds like all you needed was a pointer. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Handling project documentation using CVS
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 12, 2001 4:28 PM > To: [EMAIL PROTECTED] > Subject: Handling project documentation using CVS > > > Hello all, I was wondering if some of you nice people could > give me some > feedback on an issue I've been wrestling with. > > Besides the actual source code to a project, I also need the > ability to > version design documentation ( and maybe other stuff, but this is my > immediate concern ). By design documentation, I mean things > like Visio > documents, with UML diagrams, etc. > As opposed to TeX or ?roff documents, I guess. These are likely to be proprietary formats best represented as binary files, which means that they aren't well suited for CVS. > On one level, I have a feeling that CVS isn't the best way to handle > versioning these documents. It kinda feels like using the > wrong tool for > the job. But, on the > other hand, I can't think of any really, really, solid > reasons why NOT to > do it. > I think it would be more accurate to say that these files aren't the ones CVS handles best. I think that a systems that does file locking better than CVS would do a little better, but nobody's shown me a system that works much better than CVS. You have to remember that automatic merging isn't going to work, and in general the only way to merge is to take one of the versions and manually recreate the changes. This means that you want at least advisory locking, so that anybody starting work on such a file will know that there's likely to be a conflict that will require redoing changes. It also means that, while you can have branches, merging doc changes between branches will not in general work, and so it would probably be necessary to redo the work when applying changes to more than one branch. CVS won't store the files efficiently, so frequent small changes are likely to take lots of disk space in the repository. This may or may not be important. If you have another system that does what you need it to do and has good file locking facilities, then it may or may not be worth your while to use it to control documentation in a separate project. It is likely to do somewhat better than CVS, but introduces two version control systems and potential confusion. > So, if some of you have some experience, or thoughts, on this > issue, please > share them with me. > It works. It isn't ideal, but it works. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
> -Original Message- > From: Bryon Lape [mailto:[EMAIL PROTECTED]] > > Wrong. > > Kaz Kylheku wrote: > > > In article <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] wrote: > > > > > >You need to ask yourself why your group is experiencing so > many conflicts > > >while so many other groups (thousands?) are not. > > > > Because there is no group, and there are no conflicts. This is just > > another Chicken Little yelling that the sky is falling. Actually > > a step beneath Chicken Little, because something actually > did fall on > > Chicken Little's head, it wasn't just pure imagination. :) > Gee, that's an informative response. You burst on the scene with complaints about a feature of CVS that has given none of us serious problems, and never explain why it is a problem for you. You never answer questions about what it is that you are doing, or make any significant responses to suggestions. The only way some of us have been able to interpret your complaints about CVS is that you have such a messed-up shop that no version control system is going to work, and that strict locking is merely going to shift the mess around a bit, and probably increase it. If you are here merely as a troll, then you're getting more consideration than you deserve. If you have a legitimate problem, then your problems are far more severe than any software product can handle, and free advice on mailing lists isn't going to help either. Right now, you're asking questions akin to "When I use Amoco gasoline, my company's cars always catch fire. What additive should I use?" ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 12, 2001 1:34 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: CVS - setup reserved checkout > > > One would hope that one's shop is not using the same branch for both > maintenance and new features. That kind of thing is best done on > separate branches (where the two schedules don't interfere with each > other). The bug fix is later merged into the new development when > it's appropriate to do so. > The last job I had not involving the use of CVS was with SCCS, and we didn't have branches. This did make shipping bug-fixed stuff to customers interesting. Now assume the conditions where I'm working now, where the new features go on the main trunk and the bugfixes will be applied to a release branch, or maybe a patch subbranch. These need to be merged eventually, and I'd rather get them merged now before the developer forgets about them. > Under those conditions, almost any version control tool provides the > necessary merge tool. And locks don't matter because there's no > concurrent development on the same branch. > Any version control tool with branches. Of course, anything going in on the release branch probably should go into the development branch, and we're back to merging. The question, I suppose, is whether the merge will be done semi-automatically and promptly, so that the developer fixing the bug will watch it happen and have the problem fresh in his or her mind, or if it's going to be done manually and possibly at a later time, when the developer doesn't quite remember all the details, or not at all, and the developer finds a note three years later stuffed into documentation for an old version of the compiler about merging the change. I know which I prefer, but others seem to prefer cases 2 or 3. > 'Course, it's a different story if multiple developers are adding > their own bug fixes or features on either branch... > Yup. Any time more than one developer is working on things at the same time, there's a need for merging. It is possible to design a locking protocol that obviates the need for merges or wasted work. When a developer has a project, he or she grabs all needed locks. If that developer cannot grab all of them, he or she releases the grabbed ones (to avoid deadlock, except in the case of race conditions. This can be avoided by giving each developer a different time of day to grab locks). If the developer has all locks necessary for a task, he or she works on that task. If the developer does not have all locks necessary for any assigned task, that developer surfs the web or plays bocce ball or something. Personally, I'm not convinced that this is better than having to merge. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 12, 2001 11:46 AM > To: [EMAIL PROTECTED] > Subject: RE: CVS - setup reserved checkout > > > [ On Friday, October 12, 2001 at 09:35:58 (-0500), Thornley, > David wrote: ] > > Subject: RE: CVS - setup reserved checkout > > > > > > What do you mean by "method locking"? Locking individual parts > > of a file? It wouldn't do you any good. > > Well, not with CVS anyway! :-) > > Maybe in a multi-user smalltalk image it might (since you > only ever edit > one method at a time I was apparently unclear; I meant that method locking would do no good for anybody who finds CVS unusable because of merge conflicts. If people can work on separate methods OK, then using CVS it really doesn't matter if they're parts of the same file or not, because the changes won't conflict. If, on the other hand, everybody is messing with widespread changes all the time, which is basically what you'd have to do to have that much trouble with CVS, method locking is no better than file locking, probably more likely to cause deadlocks, and certainly more of a pain to find who's using all the locks you need and why. If you *want* to use a locking version control system on files you edit in distinct segments, then I suppose locking by method is more suitable to your desires than locking by file. In that situation, though, there's no reason not to go concurrent. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
> -Original Message- > From: Bryon Lape [mailto:[EMAIL PROTECTED]] > > The benefits add up to zero. Now, if it did method locking, > that would be helpful, > protective AND productive. Without some sort of locking, > having developers waste > time with doing merging by hand is counterproductive. > What do you mean by "method locking"? Locking individual parts of a file? It wouldn't do you any good. If you are getting large amounts of conflicts with CVS merging, that means that multiple people are changing the same parts of files in different ways. If the changes were localized in the files, so that different developers would be locking different member functions, then CVS would merge the changes just fine. In my experience, with some sort of locking developers waste time doing merging by hand. Developer A is adding a feature, and a bug report comes in from the field so developer B is assigned to fix it. B is now trying to hurry A up so she checks in and releases the lock, which means that A is likely to skimp on unimportant things like testing. Assuming B has not simply been playing 5,235 games of Minesweeper while waiting, B has likely figured out how to fix the bug, and then finds that A has modified that section and so he has to redo the bugfix. (Of course, if A did not modify that section, CVS would work just fine.) Alternatively, management yanks the lock away from A and gives it to B, who fixes the bug and checks in, and A now has to do the manual merging. Since merging of some sort is necessary when you have more than one person (or, in some cases, one person with more than one project) working on the same file, it's useful if the version control system actually has facilities to assist with the merge. Given that, it makes sense to allow concurrent development. You claim that the benefits are zero, in spite of the fact that many, many projects have found them to be great. It's pretty simple, really. If you have developers all over the place, changing everything in sight, then CVS isn't going to help you, but neither is anything else, because your shop is thoroughly messed up. If you have developers working on specific projects that change specific parts of the code, even if scattered among several files, then CVS is going to help you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: deprecated caommand in 1.11.1.1
> -Original Message- > From: Stanton, Curt (NCI/IMS) [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 09, 2001 2:32 PM > To: '[EMAIL PROTECTED]' > Subject: RE: deprecated caommand in 1.11.1.1 > > > First of all relax. Second of all, I like a lot of things > about CVS. We > would like to try to avoid problems right away by trying this > way, which was > already there in previous versions, until we are comfortable > without it. I > was merely asking if there was a way to do it in the latest > release, not > asking anyone to spend time on something that the software > isn't working > towards > You could always look at the "cvs watch"/"cvs edit" facility, which exists to let people know who is working on what files. In my experience, communication is a completely adequate substitute for hard locks. If this is not the case in your shop, you have problems that no software is going to solve. This has the advantage that two people will sometime wind up working on the same thing, and will find out about it, and so they may well try the CVS merge facilities and get comfortable with it. I think that concurrent development, when it works, is a Very Good Thing. The problem with using CVS in concurrent-only mode is that it's a matter of preaching to the choir, as only people already sold on concurrent development are going to use it. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Checkout text files with the Unix LF (Oxa) - from command line
> -Original Message- > From: Peter Ring [mailto:[EMAIL PROTECTED]] > What's flawed is the idea that the end-of-record format in > any text file > should be inherently determined by the operating system. > Would you also like > your OS to determine what character set you should be allowed to use? > What, then, is the OS-independent way of marking an end of record? There are several that occur to me as possibilities, and which have been used by various operating systems I am or have been familiar with. All of them have advantages and disadvantages, and have been selected for various reasons. I've also worked on systems that mandated EBCDIC, ASCII with assorted variations, several CDC display codes, and Unicode. There is some grounds for standardization here, but should it be on ASCII, Unicode, ISO 8559-1, or what? The CVS idea that the program, be it client or server, uses whatever convention is suitable for its host, does quite well when people refrain from mixing that which should not be mixed. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Possibly not possible
> -Original Message- > From: Emmanuel van der Meulen [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 04, 2001 2:13 PM > To: [EMAIL PROTECTED] > Subject: Possibly not possible > > > requirement, and then d) where this is not possible but you > find this of use, > could CVS please be extended to cater for this requirement - > then how would I go > about requesting this as an extension to CVS. > You would go about it by providing working code, along with supporting documentation and test cases. CVS is open source non-commercial software. If you do not have the resources to provide the code yourself, you can either try to talk somebody else into it or pay somebody to do it. > Here goes; > > Overview; > I want to make use of several repositories (at second level > of structure) > intercommunicating with each other via a root (at top of > structure), with > working directories (third level of structure) feeding off > their repositories > (at second level), thereby keeping different versions of > source separate but > enabling updating across separate 'routes' of development. > Why do you need different repositories here? If you have a specific need for actual separate repositories, CVS isn't going to work for you. Could you use different branches in one repository? > > Detail of CVS repository and working directories; > 1). > ProdSource - CVS root > ReleaseSource - CVS working directory with ProdSource as CVSROOT > > > 2). > QASource - CVS root as well as CVS working directory with > ProdSource as CVSROOT > QAWorkSource - CVS working directory with QASource as CVSROOT > It seems odd to me that you would want QA to have its own code base. One would think that QA would normally use the production code, and possibly sometimes the developer code. > > 3). > DevSource - CVS root as well as CVS working directory with > QASource as CVSROOT > DevWorkSource - CVS working directory with QASource as CVSROOT > > > Usage of above; > With above configuration, whenever source is COMMITted to > ProdSource, from > either ReleaseSource or QASource, those changes could then be > used to UPDATE > source in either ReleaseSource or QASource - enabling that > when changes are > applies from ReleaseSource, those are also available to > QASource and visa versa. > Do you mean that changes from ProdSource will be merged into the ReleaseSource and QASource branches? CVS does not itself support working directory code merged from different branches, although you can do that manually in individual cases. It sounds to me like you may want to be able to deal in some sort of "change sets" that can be handled as objects, and in that case CVS is probably not going to work for you. > This would make changes applied to 'service packs' available > to QA of next > release and visa versa. In addition any change made in QA > which applies to the > previous release, is made available to further 'service > packs'. These changes > are in addition also made available to development of the > next release, seeing > as DevSource gets source from QASource. > How we do it: There is the head, on which most development will ideally occur. When it is time to create a release, we cut a release branch and get it into shape to ship. We cut patch branches on those, and so when bugs are found they are first added to a patch branch, and then merged to the release branch and then to head. We can cut off a patch branch when it seems ready, and package all changes along that branch into a patch or service pack or whatever you want to call it. This means that head is basically the development source, and changes made on releases are propagated into it. The release branches are effectively the production source, and QA doesn't have a source base of its own. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: The future of CVS & Subversion
> Richard F Weber writes: > > > > Is subversion (http://subversion.tigris.org/) the future of > CVS, or is > > it being developed by a totally separate group of individuals? > > It's a completely separate project. > The subversion group does include Karl Fogel, the author of the critically acclaimed "Open Source Development with CVS", so there is definite CVS expertise there. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: checking links into source control
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 14, 2001 6:21 AM > To: [EMAIL PROTECTED] > Subject: Re: checking links into source control > > > [EMAIL PROTECTED] (Kaz Kylheku) writes: > > > Not combining unrelated responsibilities into the same > program is not > > necessarily a limitation. What would you say about an > e-mail application > > that contains a C compiler, and a filesystem repair tool? > > "Microsoft Outlook owns that market." > But how about an e-mail application that contains an editor, Lisp interpreter, and text adventure game? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: checking in links to source control
> -Original Message- > From: Edward Peschko [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 14, 2001 4:13 PM > To: CVS-II Discussion Mailing List > Cc: [EMAIL PROTECTED] > Subject: Re: checking in links to source control > > > On Fri, Sep 14, 2001 at 03:59:03PM -0400, Greg A. Woods wrote: > > [ On Friday, September 14, 2001 at 11:59:03 (-0700), Edward > Peschko wrote: ] > > > Subject: Re: checking in links to source control > > > > > > And that's exactly what I want to do - I want to build > in serialization > > > into CVS. > > > > That's such a silly thing to want to do in CVS that I can't > even begin > > to explain why it's so. There are, as I said, literally > hundreds if not > > thousands of ways to do it. Some better than others, and > many platform > > dependent. I.e. there is no "one true way" to do this kind > of thing. > > hmm. My ears are open. Give me a 'hundred useful different > ways' in which > you could serialize a symlink. And don't give me stuff about > cross-platform > support between shortcuts && aliases - I want to serialize a > *symlink* so > that one type of platform (Unix) can share them. We'll worry about > translations later. > If this is done on an ad hoc basis, it might work. At that point it seems reasonable to do it outside CVS. It really isn't difficult to write simple wrappers around CVS. > > This *is* _the_ perfect example of ideal place for ad hoc solutions. > > > > The requirements for a generic solution are just too > unwieldy. Only you > > can invent the right kind of wheel for your specific > requirements, and > > that generally means what you invent will never be perfect > for anyone else. > > examples please, again. Perhaps this time on permissions.. > How would you > serialize permissions in different ways, again with the guide that the > permissions will only be shared on the same OS? > If you set the requirements to that level of detail, you can doubtless come up with a standard solution. Assume that's implemented. Now, it happens that I work on Linux and MacOS at home, and various Unixes and MS Windows at work. Perhaps somebody else does Mac only. That's four situations that need different methods of serialization. Actually, MacOS 9 privileges don't map at all well to Unix permissions, so everybody serializing privileges to both is going to have to roll their own. There is quite a bit of support for running CVS clients on the Mac, by the way, with three implementations. Let's not gratuitously make things hard for Mac users. So, we find that permissions require ad hoc solutions in many common circumstances. > Like any programming technique, you don't use serialization > for *everything*. > You wouldn't serialize a database, for example. > Why not? Too long? I've got a serialized database in a directory around here somewhere. If I were to put it in CVS, it would be nice if CVS made more efficient use of /tmp and memory, but that's not an overwhelming problem. > No, you only use it for things that it makes sense to use on. > I can think > of only a few things that fall under this category: > Really? There's lots of things that can be serialized. > 1) directories - in fact, useful serialization in this case > would probably be >cross-platform (given pretty much any platform. Maybe VMS > might have some >issues). > Depends on how detailed you want to be, and how much differences there are with the directories. Remember the symbolic link issue: how much commonality is there between Unix symlinks, Windows shortcuts, and Macintosh aliases? (It's been over a decade since I did serious development on an OS that didn't have subdirectories. Are there any still out there?) > 2) permissions - cross-platform for all of unix, > cross-platform for all of NT, > cross-platform for all of Mac. > The Mac now subsumes much of Unix, since modern Macs ship with a Unix installed (it's called MacOS X, but it's mostly BSD with some fancy interface stuff on top). > 3) user/group - cross-platform on all of unix. cross-platform > for all of NT. > Again, what about MacOS, or people who want to use multiple platforms? The stuff I work on at home is intended to compile and run on multiple platforms, right out of the box (well, tarball). > 4) binary data - cross-platform on all of unix, && probably > all of NT && mac, > given the correct supporting programs or routines > Um, no. There are methods to converting arbitrary files to text or text-like representation. They are useless for anything except transmitting the file to another system. > 5) symlinks, shortcuts, aliases - cross-platform on all of > unix, NT, and mac >ie: symlinks are > cross-platform on > They don't necessarily map all that well onto each other. The list of converters you're proposing is incomplete, and simply won't fit everybody's needs. It is necessary
RE: giving up CVS
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Using CVS to try to track changes to non-text files is a > losing proposition, > almost by definition. > Almost by definition, you lose the main reason for considering CVS. This does not necessarily make it a losing proposition. > CVS is quite literally less useful for tracking changes to non-text > files than RCS alone can ever be. > Really? Does RCS enable merging changes to non-text files? Since it doesn't, what does it do better? There are a lot of things CVS does better than RCS. CVS manages concurrent development, branches, and works well by directory or module rather than by file. By using non-text files, the concurrent part goes out the window, and branches become less useful. The rest of the advantages remain. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How well does CVS handle other types of data?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > [ On Thursday, July 12, 2001 at 16:53:53 (-0500), Thornley, > David wrote: ] > > Subject: RE: How well does CVS handle other types of data? > > > > Except that I'm not banging my head against the wall, and it doesn't > > hurt. I don't know about the rest of you, but I'm not > having problems > > with the way CVS manages the stuff I work with, which does include > > some binaries. > > at first you say one thing, and now you say another. which is it? > That I don't think putting nonmergeable files into CVS is bad, that I don't have problems with it, and that I'd really like to find out if there is any reason not to. So far, I've gotten a lot of emotion, and an assumption that I must certainly be having problems, since I'm doing the Wrong Thing. > > What problem? You've claimed that putting binaries into CVS is bad, > > and now you're claiming that I've got a problem with it. I'm happy > > with CVS. I wish it could handle unmergeable data as well as it > > handles mergeable, but that isn't possible, so I'm (a) not > considering > > it a problem, and (b) not going to buy that keeping these apart is > > going to solve any problem I may have. > > Well then quit wishing for the impossible! All you're doing is > confusing the onlookers! > I'm not saying CVS should merge unmergeable files, I'm saying that nothing does, and so I can't seriously complain that CVS can't. As far as I can tell, CVS does an acceptable job of handling binaries. It could be better, but I don't see how any system is supposed to do significantly better. > > Why, in the name of Babbage, is that supposed to be better? I still > > can't automatically merge binaries, so it's no advantage there. So > > what do I get if I do that? > > but you can't avoid having to do something equivalent to merging of > opaque format binary files with CVS! > Right. You're so right, especially if you drop the last two words. I can't avoid having to do something equivalent to merging of opaque format binary files. This is not so much a matter of concurrent development as it is a matter of branches. We are going to have branches, and I can't change that just because it can be inconvenient with a small fraction of our controlled files. Since we have branches, we will come across the merging the unmergeable file problem; unless I dream the impossible dream of something that will do that for us, we will have to confront it when it happens. We can handle it. It will occur, regardless of how we manage our source. > If you must handle non-mergable files as source, and you want > to use CVS > for your mergable source, then it makes almost infinite sense to store > the non-mergable files in some other revision tracking system!! > Again, a very flat statement with no reason I can see. > > 1. I get to maintain two version control systems in parallel. > > 2. I get to maintain a more complicated build system. > > 3. I get to try to keep the CVS stuff and the other stuff correctly > > aligned. > > > > What I don't get is an easier way of managing binary files. > > You're looking at the world through CVS-only-eyes. If you're having > problems with non-mergable files in CVS then you should look > outside CVS > for a solution. You might be pleasantly surprised at how > much easier it > makes your life in the long term! > I'm not having problems with non-mergeable files in CVS that I wouldn't have without CVS. If you can point me to a better tool, I'm listening. It does have to support branching, because we can't do without branches. > > However, I think you're wrong. I have a simpler thing to > do than manage > > text-based sources in CVS and binary sources in another > directory with > > a more complicated build system: I can put them all in > CVS! As long > > as I make sure the -kb goes on (and this has not been a > problem in my > > shop), it's even simpler than hacking the build system. > > -kb is not the solution -- it just makes the problem harder! If it > didn't exist in the first place you'd never have gotten into this > predicament. > I'm sitting here quite comfortably in my swivel chair, and people keep telling me that I've got problems and predicaments. I want to see evidence that I've got a problem. > Why not just use RCS stand-alone for the binaries? Making a build > system that pulls a specified revision from an RCS file is trivial!
RE: How well does CVS handle other types of data?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 12, 2001 3:24 PM > [ On Thursday, July 12, 2001 at 09:38:17 (-0500), Thornley, > David wrote: ] > > Subject: RE: How well does CVS handle other types of data? > > > > > Learn to separate your unmergable files form your other stuff > > > and build > > > procedures and processes to bring them together only at > build time! > > > > > Why? What do I get out of this that I don't get by keeping the > > binary source files with the text source files and use CVS on both > > of them? What does it buy me? > > "Doctor! Doctor! It hurts when I bang my head against the wall!" > > Well stop banging your head against the wall! > Except that I'm not banging my head against the wall, and it doesn't hurt. I don't know about the rest of you, but I'm not having problems with the way CVS manages the stuff I work with, which does include some binaries. > If you keep your binaries and your sources separate you won't > have this > problem in the first place! > What problem? You've claimed that putting binaries into CVS is bad, and now you're claiming that I've got a problem with it. I'm happy with CVS. I wish it could handle unmergeable data as well as it handles mergeable, but that isn't possible, so I'm (a) not considering it a problem, and (b) not going to buy that keeping these apart is going to solve any problem I may have. > > You've accused me in another post of not being able to see > a screwdriver > > because there's a hammer in my hand. I've asked what a > screwdriver is, > > and where to get one, and so far I've got a piece of metal > I can pound > > into something almost as useful to drive in screws as the claw of my > > hammer. If you'd show me something better, like a piece of > metal I could > > pound into a better screwdriver than I've got, I'm very > willing to learn. > > I did show you something better. Several things in fact! > Here's one of > the alternatives, AGAIN: > > Keep and manage your binaries separately from your source > code. Create > a build system that pulls the various components together as desired. > Why, in the name of Babbage, is that supposed to be better? I still can't automatically merge binaries, so it's no advantage there. So what do I get if I do that? 1. I get to maintain two version control systems in parallel. 2. I get to maintain a more complicated build system. 3. I get to try to keep the CVS stuff and the other stuff correctly aligned. What I don't get is an easier way of managing binary files. > That's the easiest solution. It's so easy it's child's play -- brain > dead simple. There literally can't be anything simpler. > You know what's easier than CVS? Just keep all your source files in a directory tree, and let everybody change them as they need. Child's play; there can't be anything simpler. Personally, I don't want to do that, but your needs may differ. However, I think you're wrong. I have a simpler thing to do than manage text-based sources in CVS and binary sources in another directory with a more complicated build system: I can put them all in CVS! As long as I make sure the -kb goes on (and this has not been a problem in my shop), it's even simpler than hacking the build system. > When you have a problem managing disparate types of data, don't manage > them the same way! > What's the problem? And why is using one management technique worse than using two different techniques if the more complex process doesn't do anything more? > > Right. This is the point that you completely miss. If you > are going to > > tell me not to use a particular tool for a particular task, > you need to > > show me either that that tool doesn't work for that task, > or that there > > is a better tool. You haven't done either. > > BUT THAT WASN'T THE POINT! THE POINT WAS THAT YOU WANT THE > IMPOSSIBLE > Or at least I want some things my wife would object to (she doesn't want me buying more books). Anyway, what I want for source code management here is to use something like CVS without people telling me I'm doing something wrong. > The point of saying you can't see the screwdriver because you've got a > hammer in your hand is that you aren't thinking outside the box and > you're failing to see how to separate your problems out into managable > subdomains. > No, I'm failing to see *why* to separate my prob
RE: How well does CVS handle other types of data?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > [ On Wednesday, July 11, 2001 at 11:35:14 (-0500), Thornley, > David wrote: ] > > Subject: RE: How well does CVS handle other types of data? > > > > OK, what? For my purposes, it has to support concurrent development > > and branching, and right now my company isn't going to spend gobs > > of money. It has to be reliable. Heck, it has to be widely used > > and considered reliable. The source code repository here is very > > valuable, and we don't want to take chances. > > > > So, given these constraints, what should I use? > > I think you've totally and completely missed the point. > Somebody is completely missing a point, that's quite clear. Perhaps different people are missing different points, but I don't think so. > Unmergable files are fundamentally at odds with any concurrent > development (be it concurrent editing, or just branching and merging). > Period. > Right. However, we have to branch. This means that we have to cope with the problems of unmergeable files, and perform manual merges. CVS doesn't do this well. However this is only an objection to using CVS if other tools work better. I've seen suggestions for doing things that would cost me a good deal of work and work almost as well as CVS, but it doesn't seem to me that they would be improvements over using CVS. > Learn to separate your unmergable files form your other stuff > and build > procedures and processes to bring them together only at build time! > Why? What do I get out of this that I don't get by keeping the binary source files with the text source files and use CVS on both of them? What does it buy me? You've accused me in another post of not being able to see a screwdriver because there's a hammer in my hand. I've asked what a screwdriver is, and where to get one, and so far I've got a piece of metal I can pound into something almost as useful to drive in screws as the claw of my hammer. If you'd show me something better, like a piece of metal I could pound into a better screwdriver than I've got, I'm very willing to learn. > > And the version control system that allows branching and makes it > > relatively painless to merge binary files that get changed > in a merge > > would be > > There isn't one (that I know of). > Right. This is the point that you completely miss. If you are going to tell me not to use a particular tool for a particular task, you need to show me either that that tool doesn't work for that task, or that there is a better tool. You haven't done either. CVS handles unmergeable files, although not nearly as well as mergeable files. I haven't been told of a tool that manages unmergeable files better. I am going to continue using this hammer instead of the proper tool, which appears to have a handle made of unicorn horn and a blade formed from a dragon's scale. I do have work to get done. > Paul Sander and others have made several proposals about how > to build a > CVS-like tool that could handle multiple file types and make > more manual > merging processes work in conjunction with semi-automated merging of > text files. > Yes, and I'm on record as being very dubious about this. Merging does no good if it can't do some sort of conceptual merge (with source code, the concepts are fairly directly represented in the data format) and provide decent tools for resolving conflicts. If I've got to fire up Visio and design a composite image, I don't see that it matters much whether I'm automatically dumped into Visio or not. > > Consider a GIF that is changed on a branch and (in a > different manner) > > the main trunk. Where is the tool that will merge it like > CVS merges > > text files? Does it also work with PNGs and JPEGs? Any > other binary > > files we're likely to need? If you know of such a tool, I want to > > find out about it. > > How would I know? I'm not a graphics artist! I can imagine > the process So can I, but it requires a human mind to do anything useful with it. So what? > Get your graphics people to handle that problem! I.e. get > your graphics > files out of your CVS repository! Or let my graphics people into the repository. We allow several different classes of people in, and have processes to limit what they can do. The trick is to get the graphics people together with the graphics files, not just to assume where the graphics people are and move the files to match. Together with your graphics people > you should define identification schemes and procedures that'll allow > you to create a mas
RE: How well does CVS handle other types of data?
> -Original Message- > From: Jeff King [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 11, 2001 1:29 PM > To: [EMAIL PROTECTED] > Subject: RE: How well does CVS handle other types of data? > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Thornley, David > > Sent: Wednesday, July 11, 2001 12:35 PM > > To: [EMAIL PROTECTED] > > Subject: RE: How well does CVS handle other types of data? > > Why? It may make sense to you, with your applications, but I don't > > see that it makes sense for mine. I would rather group conceptually > > related files together rather than files of the same datatype. > > Exactly. "Source code" and "binary data" are quite > conceptually different. > Really? Suppose I'm putting a web site under CVS control. I have HTML and PNG files, let us say. What's the conceptual difference here? Both are part of the web site, both require some sort of tool to change (but a different sort of tool), both exist in different versions. There are things I can do with one but not the other, but that's not much of a conceptual difference. > > So, given these constraints, what should I use? > > A CVS repository for source code and a network directory for > binary data > with an established, enforced naming and access procedure. > That's worse than what I've got now. Right now, the binary files are tagged along with the text files, so I can easily pull out a consistent set of files. I don't think I should go for something worse. CVS with -kb does as good a job of managing binary data as dated tarballs do - better, in fact, since it allows tagging and retrieving without having to make sure the proper directory name is in the proper version. It doesn't offer nearly the advantages that it offers for text files, but that's hardly a reason to not use it on binary files. > > And the version control system that allows branching and makes it > > relatively painless to merge binary files that get changed > in a merge > > would be > > That depends on the filetype. Merging Word files is easy, as > it's simply a > binary format for text. But how exactly would you merge a > JPEG? It doesn't > make sense. > Right. It doesn't make sense. So, what version control system handles binary files better than CVS? This is a serious question. CVS satisfies my needs better than any other VCS for source code (my needs here do include money; CVS is much less expensive than ClearCase). Is there another VCS that works better than CVS for binary files, and, if so, how much better? CVS does everything for binary files that it does for text files, except for merging and diffing. If there is a VCS that will do automatic merging and diffing for binary files, then that would be a reason to use that instead of CVS. If not, I have no idea why I wouldn't want to use CVS. > > We've got to have branching. We can put up with a certain amount of > > pain with merging if we have to. I think CVS does the best possible > > thing here. > > I agree, assuming we're talking about datatypes that can be > automatically > merged with a reasonable process. > I think CVS does the best possible thing on binary files, also. It isn't as good a thing as it does with source files, but I don't know what tool can be used to do automatic merging of PNGs, and therefore I don't know that any tool can do better than CVS, hence I think CVS does the best possible thing here also. If you disagree, please nominate an action for "best thing" that is better than what CVS does. > > Consider a GIF that is changed on a branch and (in a > different manner) > > the main trunk. Where is the tool that will merge it like > CVS merges > > text files? Does it also work with PNGs and JPEGs? Any > other binary > > files we're likely to need? If you know of such a tool, I want to > > find out about it. > > This makes no sense. Right. If I take the idea that there are better tools for binary files than CVS, since CVS merges text files automatically, I am pretty much forced to the conclusion that some tool merges binary files automatically. This makes no sense. Hence, by the contrapositive, the argument that CVS is not the proper tool for binary files since it cannot merge them makes no sense. That's logic for you (particularly, it would seem, according to the Humpty-Dumpty definition). Supposed you have a blank bitmap for a > "tools" icon. > Two people make concurrent changes to it: the first person > draws a hammer, > the second person draws a screwdriver. How could this be > merged? You don't > want so
RE: How well does CVS handle other types of data?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > [ On Wednesday, July 11, 2001 at 08:52:37 (-0500), Daniel > Beckham wrote: ] > > Subject: Re: How well does CVS handle other types of data? > > > > Greg, as someone else pointed out. It's a rare project > that does not have a > > few binary files peppered in the source for various > > The more rare the binary files, the more sense it makes to keep them > separately. > Why? It may make sense to you, with your applications, but I don't see that it makes sense for mine. I would rather group conceptually related files together rather than files of the same datatype. > The more common the binary files, the more sens it makes to use > something other than CVS (if not for them then for everything!) > OK, what? For my purposes, it has to support concurrent development and branching, and right now my company isn't going to spend gobs of money. It has to be reliable. Heck, it has to be widely used and considered reliable. The source code repository here is very valuable, and we don't want to take chances. So, given these constraints, what should I use? > It's irrelivent whether or not you "need" to merge binary files. You > may *have* to If you use branches, and if changes to binary files > are made on branches then you _MUST_ "merge" them!!! CVS > simply cannot > do that and the only way to resolve the conflict is to choose one > revision. And the version control system that allows branching and makes it relatively painless to merge binary files that get changed in a merge would be We've got to have branching. We can put up with a certain amount of pain with merging if we have to. I think CVS does the best possible thing here. Consider a GIF that is changed on a branch and (in a different manner) the main trunk. Where is the tool that will merge it like CVS merges text files? Does it also work with PNGs and JPEGs? Any other binary files we're likely to need? If you know of such a tool, I want to find out about it. If you're lucky there'll only be one or two such conflicts > during a branch merge and manual cleanup is easy. However if > you've got > dozens of GIFs, for example, and you end up with a conflict on each, > then you're in for a much more difficult cleanup. > > > And in rebuttle to your comment.. there is no right tool > for the job. > > What are you talking about? Of course there's a "right" tool, even if > its some lame script you write that used gtar over SSH and carefully > named files and directories! > And a lame script will make merging GIFs easy? You're not making sense here. For any job of reasonable complexity, a lame script is not the right tool. I think version control counts as reasonable complexity. For many jobs, there just isn't a right tool. For some, there is a right tool, but accumulating all the "right tools" is impractical. I think it more appropriate to think in terms of a "best" tool, not a "right" tool. For many scenarios that involve binary files, CVS is the best tool I know of. Being told to drop CVS and write a lame script that keeps track of versions by dated tarball sounds to me a lot like using a worse tool, not a better. (Disclaimer: on the Plato-Aristotle axis, I'm a firm Aristotelian who carries and uses a Swiss Army knife. YMMV.) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: problem with remotehost
> -Original Message- > From: krishna rama [mailto:[EMAIL PROTECTED]] > > tcp nowait root /bin/echo echo hello" .After make this > I was run "telnet servername 2401" for this also we > geting error "telnet:Unable to connect to remote > host:connetion refused".I was given all detailes > whatever i did here.please help me. > This means that the CVS call isn't getting to CVS, but is being bounced by xinetd. I believe Red Hat provides documentation for xinetd which can be easily adapted to CVS. This isn't a CVS problem, but a networking one. The proper xinetd configuration can be found in the CVS mailing list archives, given a search, and that's the limit of CVS involvement. Are you sure that you restarted xinetd after changing the .conf file? I did a "shutdown -r now" to restart it. There's better ways, but I knew that one would work. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How well does CVS handle other types of data?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > John Dixon writes: > > > > Does anyone have experience using CVS with CAD/CAM binary > data files like > > .MOD (Solution3000) or .DWG (Mechanical Desktop)? > > Since such file don't allow for concurrent modifications, I can't > imagine why you'd want to use the *Concurrent* Versions > System to store > them. > Here at work, we have binary files scattered through the text files. Since CVS is one of the better available systems for source code, and using two systems is a significant cost, and CVS handles binary files in an adequate manner, that's what we do. I have a repository at home, which serves one developer (me) and therefore doesn't involve concurrent development. I use it partly because I'm familiar with it, but also because it works well over the home network (Linux and Macs) and serves my needs very well. I can have branches for possible development work. I can tag release points and cut branches, so I can fix bugs without interfering with new features. I can easily create diffs between versions. If I screw up maintaining the change log, it's easy to recover from. It's overkill, but what that means is that it satisfies all my current needs and I have room to go from there. There's also the fact that I'm doing my home stuff on as low a budget as I can get away with, and CVS fits into that budget very nicely. It seems to me that, to forego the possibility of concurrent development (which is irrelevant to me) I'd have to forego things that I care about. Can I get a Linux/Mac source code system that does branching for free other than CVS? > -Larry Jones > > Some people just don't have inquisitive minds. -- Calvin > Sometimes these random .sigs seem appropriate. :-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Renaming directory in repository--questions
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Rajesh Patwardhan writes: > > > > My thoughts: > > 1) make the new_dir as described from outside repository. > > 2) in the actual directories on the cvs repository copy > concerned ,v files > > into the new_dir location. > > Since all files are same (only under a different parent > directory )it would > > also continue to have history at the new location. > > The problem with that is that when you check out an old > version, you'll > get the files in both places, which isn't right. If that's not > acceptable, I think you mark all the old revisions as dead using cvs > admin, but I'm not sure whether that would have any undesirable side > effects or not. What I do in cases like this is to copy the files, "cvs rm" the files in the old directory, and remove all the tags from the files in the new directory. It isn't an ideal solution, but it generally works well enough. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: .doc file concerns
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 26, 2001 6:14 PM > To: [EMAIL PROTECTED] > Subject: Re: .doc file concerns > > > The thing is, most writers seem to prefer WYSIWYG editors > such as Word or Frame > Maker to using mark-up languages. This is reasonable, > because they're much more > productive with such tools, Has anybody done studies? My guess would be that getting an initial design slapped out would be somewhat faster with Word, but that redoing the document would be faster with something like LaTeX. In any case, there is at least one editor claiming to do essentially WYSIWYG with LaTeX. I have no doubt but that designers like Word and FrameMaker better, but there's a surprising lack of correlation between what seems easy to use and what makes you more productive. especially since they're much > more concerned with > an attractive presentation than are engineers who happen to > write simple documents. > TeX was written by a man very concerned with how his documents looked, and they include ways to do very tricky typesetting. Knuth stopped submitting papers to journals that could not typeset them to his standards. Since TeX, probably the most widely used markup language, was designed by somebody who was concerned with an attractive presentation and did not write simple documents, there is something wrong with your argument. If I'm going to write a simple document, I frequently use Word. If I'm going to write something complicated, I use a better tool, such as LaTeX or a real page layout program. > Choosing an inferior tool just because the version control > system can't handle > a full-featured one is a poor way to work. > On the other hand, using a tool that makes products that can be stored, compared, branched, merged, and so forth is attractive. I would be surprised to find that any version control system would handle Word documents in such a versatile fashion. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: .doc file concerns
> -Original Message- > From: Mike Castle [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 25, 2001 5:40 PM > To: [EMAIL PROTECTED] > Subject: Re: .doc file concerns > > > On Mon, Jun 25, 2001 at 02:56:34PM -0700, Anita Chacko wrote: > > Any alternate way to handle .doc files? > > Switch from using binary only formats. All of the items you > mentioned are > problems. Proprietary formats like Word documents, just > can't be handled > well. There is nothing you can do except not use them. > I'd be very uncomfortable about standardizing on a proprietary format, particularly since you can't effectively standardize on a Word format (they change). Other people do disagree with me on that. > Personally, I'd recommend using LaTeX to do your > documentation. We used > that with cvs (under win32!) and it worked great. We able to make > meaningful merges of documentation. People could easily, see what was > changed (using diff). It's cross platform (I actually did my > work under > Linux). > LaTeX is an excellent product. It's optimized for mathematics (Knuth is a mathematician), but will handle much more. There are at least attempts to make it comparable to a WYSIWYG word processor. A Google search for "LaTeX WYSIWYG" found a lot of references to something called LyX. (Note: there seems to be a lot of European activity on this, so there may be things out there that you can use if multilingual.) > And personally, I found it MUCH easier to use than Word (I > always get lost > in word. With TeX, I was able to focus on the content of > what I wanted to > write, and worry about how to mark up the structure later). > That's iffy, but as documents become more complicated it becomes easier to get it right with TeX rather than Word. One big advantage of TeX is that you can change typographic and format changes at will. You don't have to think, "Gee, I'd like to change how I formatted the section headers, but it's such a lot of work to manually change all of them, and I might miss them." > RTF _might_ be an option, if it uses reasonable formatting in > the rtf doc > (ie, not all one big long line). > > For the rest of the CVS group: What about other word > processors in the > win32/dos world? Do any word processors use text only format > these days? > (Maybe for a history lesson, what word processors in the past > may have used > suitable file formats? NotaBene? Word Perfect? PC/Write or > whatever it > was called. I can't believe they've always been so dense...) > You haven't been around the microcomputer revolution much, have you? Every word processor that I've used on a microcomputer operating system, including the ones I used before the IBM PC appeared, has had a binary proprietary format. I think the earliest concern was size (the size of computer-typed text hasn't changed much since the days of the 80K floppy), and after that nobody seemed to care about providing a non-proprietary or text-based format. (Presumably now the ever-changing Word format is seen as a cash cow by Microsoft.) Remember, proprietary formats are not generally for your benefit, but for the company's. The cultures of MS Windows and Unix are considerably different, the former being much more dominated by companies. Since the company assumes that you will continue to use their product, and continue updating, it is convenient for them to use binary formats, enforces their assumptions, and has no downside with large numbers of upset customers. The same is the case for the compilers I've used: project information is usually kept in some sort of proprietary binary format, rather than as a Makefile. I'm not going to recommend Make as a generally useful interface, but it does have advantages of portability and readability. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: The use of CVS Branches???
> -Original Message- > From: Patrice Martin - GRE [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 21, 2001 8:22 AM > To: [EMAIL PROTECTED] > Subject: The use of CVS Branches??? > > > Hello, > > I use CVS V1.10, and i am in confusion with the CVS branches. > If that's 1.10, with no .7 or .8 after it, you should upgrade. 1.10 is not Y2K-compliant, and if you use date specifications anywhere you're going to have problems. > First, what is the basic difference between "cvs commit" and "cvs > import"? > The intention is that "cvs commit" is for changes you make, and "cvs import" for tracking other people's code. The main difference is that "cvs import" is much more sweeping than "cvs commit", and models what you'd want to do when getting the latest source release. > I think that my problem came, because i track my source evolutions by > always doing an "cvs import" from the head directory of my project. In doing that, you are not making the best use of CVS. You could do about the same thing with a collection of dated tarballs. I'm not going to tell you you're doing the wrong thing here, but you do need to understand that this is not how CVS was intended to work. You can pound in a nail with a wrench, but it's not easy to pound in a nail and tighten a nut at the same time with the same wrench. > I have made this choice, because there is often lot of modifications > made at the same time in that project. > So in intent to not do "cvs commit", "cvs add", "cvs remove", > and so on > each time, from file to file, or directory to directory, i do an "cvs > import" one for all, starting at the head directory of the > project, once > i want to do a version. > It's work well like this until last month. > Hmmm. Massive changes seem to work with "cvs commit" here, and everywhere else I've heard of. What do you do for small changes? By treating your code as if it were vendor code, you at least make it harder to use CVS like a real SCM system. > But recently, i want to make branches for tracking parallel > development > of the project, because one part of the project go in maintenance, and > the other part stay in development with evolutions and new > functionalities. > Right. This is not usually a problem. However, since you're doing the wrong thing, you're having problems. What you need to do to make this work smoothly is to do your changes on checked-out copies and commit your work, not make your changes on external copies and import it. This will leave you doing what most of us do, and what CVS was designed for, and then it's much easier to help you. So, make sure all the "vendor" changes are merged to head. Cut a branch for the maintenance version, using a branch tag, a start tag, and a merged-up-to tag. Check out workspaces to do your development in, and commit from there. When you commit a bug fix to the maintenance release, merge the changes from the merged-up-to tag to head, and move the merged-up-to tag. > But by doing like this, i cant merge the modifications made in that > branch, because > the cvs (in fact rcs) revision number doesn't match the cvs revision > number of the trunk. > And then the diff, update and merge commands doesn't work very well... > If you're sweating the revision numbers, you're doing something wrong. IIRC, multiple vendor branches (and that's what you're proposing) have always been awkward. > So now i am completely confused with the used of branches with CVS. > > May i have some explanations and help to understand what's happen, and > then try to fix my problem, > and then used correctly CVS branches, for tracking parallel > development. > Correct use of CVS branches depends on correct use of CVS. Once you are using CVS as it was designed, you will find it far easier to use CVS features. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Future CVS Development
> -Original Message- > From: Kostur, Andre [mailto:[EMAIL PROTECTED]] > > -Original Message- > > From: Noel L Yap [mailto:[EMAIL PROTECTED]] > > > > CVS only requires files to be mergable. This has a different > > meaning from > > requiring files to be non-binary. > > > > One thing that may be done is to add a hook for pluggable > > diffing/merging > > engines. > As discussed before, this would require at least an extension to the RCS file format. The trick is the CVS definition of mergeable, which doesn't just mean that some sort of diff and patch will produce a file, but rather that merging two sets of changes is likely to make sense. That's the usual case with the source code it was originally designed on, although it's not universal (I remember one case in which two different changes added elements to a hard-coded array in different places, and both incremented the array size constant by one). If the file format doesn't preserve some sort of locality (so that a fairly small change affects only one part of a file) then it has to be treated special. This is why I'm not hopeful about Xdelta. (Another essential part is presenting the merged file, with conflicts, to the user to resolve, usually by some method that keeps both changes.) > Now, pluggable engines would be truly cool! I know that one > large argument > against CVS here (my office) was that it doesn't do > "intelligent" things > with proprietary format non-mergable files (like MSWord > documents), where > other source control systems can do (the counterexample was always > Clearcase). But if you could plug in a diff/patch tool for > *.doc files, > (and perhaps a different diff/patch tool for *.ppt, another > for *.xls) that > would make these files mergable, and thus behave sensibly in CVS! :) > Because of the above, you'd probably need one diff/patch tool for every file format, and you'd need to keep the diff/patch tools steadily updated for changes in file formats (MS Word file formats come to mind as changeable). This is in contrast to the diff/patch standard in CVS, which applies to a large number of different sorts of files, and can remain unchanged. I'm not sure producing diff/patch tools for arbitrary file formats is reasonable to expect out of an open source project. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Future CVS Development
> -Original Message- > From: Noel L Yap [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 19, 2001 11:03 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: Future CVS Development > > > > >As I just mentioned in another somewhat related thread anyone and > >everyone is "free" to design and implement a replacement for CVS. If > >such a thing actually succeeds in replacing CVS then that's an > >achievment to be applauded. In the mean time CVS does a fair job at > >what it's been designed to do and there seems to be no shortage of > >people who have requirements that it can specifically fill. > > I haven't looked at it yet, but this may be it: > http://www.netcraft.com.au/geoffrey/katie/ > > Noel > See also http://subversion.tigris.org/index.html which I've been keeping an eye on now and then. It is explicitly intended as a CVS replacement, and includes Karl Fogel among the developers. It appears to have been making steady progress, if slower than scheduled. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: (no subject)
> -Original Message- > From: Randall Weigers [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 18, 2001 9:52 AM > To: '[EMAIL PROTECTED]' > Subject: (no subject) > > > > > Can you review the attached list and tell me how CVS > fairs in regard > to the characteristics we are looking for in a source > management system?? > Thanks ! > ><> > > No, I cannot review the attached list - or, to be more precise, I will not. I do not open attachments from people I do not know, and I don't know you. Please review the information at http://www.cvshome.org/ and, if you have further questions, please post them as plain text. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Maintaining branches...
> -Original Message- > From: Ralph Mack [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 13, 2001 10:52 PM > To: [EMAIL PROTECTED] > Subject: Re: Maintaining branches... > > > [Quoth I... :-)] > > 0. select a reference version and a from and to version > > 1. make a diff from the reference version to the "from" version > > 2. make a diff from the reference version to the "to" version > > 3. merge the diffs (preferably with optional user input), and > > 4. apply the result to the "to" version. > > As I lay in bed thinking about all this, it suddenly occurred to me > that, since CVS is always using the root as its reference version, > CVS (and its ancestor RCS) can get away with not recalculating any > diffs at all during an update but merely selecting from among the > diffs calculated during prior commits. This is a significant time > savings. A commit becomes the only operation that actually > calculates a diff as a side-effect. > CVS does not always use the root as its reference version. The restriction is not that CVS does not permit merging, but that it does not itself have an automatic way of keeping track of what has been merged where. The user can keep track of this information with a tag, or externally, or can just merge the last change (which is usually what you want to do anyway). A commit is not the only operation to create a diff; the "cvs diff" command will normally also do so (although that diff is not kept by CVS; if you want to keep it as a diff you can save it yourself). For example, "cvs diff -r 1.10.2.6 -r 1.12.6.3 foo.C" will create a diff between the version of foo.C in two different branches. (If you like, "cvs update -r 1.23.2.3 foo.C; cvs update -j 1.10.2.6 -j 1.12.6.3 foo.C" will attempt to apply the difference between 1.10.2.6 and 1.12.6.3 to 1.23.2.3, which is usually not a useful thing to do.) > Is this true? If so, it seriously restricts the kind of merge > behavior that CVS can support, but I can see why it was done. > Lots of other things about CVS that seemed a little odd also > suddenly become comprehensible. > It restricts the kind of merge behavior that can be done without further ado and record-keeping. It does not restrict the ability to arbitrarily merge if the user is willing to keep track of things in some way. We use a tag to show what has been merged already. > How hard is it to extract three different revisions of the same > file to a temp area outside of the normal checkout tree using > CVS? If I were going to do that, I'd do three separate "cvs update -r ..." commands, moving each to the appropriate directory after the update. Again, it is not something that CVS automatically does with a simple command out of the box. (I'm contemplating what a seperate graphical merge utility > layered on CVS might need to do.) If I were to use this approach in order to use a different merge I would write a script to do it. There is certainly no reason why it can't be done, but for most purposes CVS's merging is quite adequate. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Use of CVS on large scales
> -Original Message- > From: Bob Bowen [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 11, 2001 8:20 PM > To: John Minnihan > Cc: [EMAIL PROTECTED] > Subject: Re: Use of CVS on large scales > > > John Minnihan wrote: > > Do you have specific experience with CVS 'breaking down and > becoming unusable'? > > If so, please share that experience here so others may > learn from it. > > I think there are two obvious areas where CVS doesn't scale well: > > 1) Working with branches - the interface is just too primitive and > clumsy for large numbers of users to do the right thing. It's not too > bad if you have just a few branches and a couple of people > that know how > to use them, but even then it's tedious. > Yeah, but in a large project you can afford some administrative work to automate this. Given a consistent naming scheme, it's not difficult to write a script that will do the merge. Basically, it has to determine what branch the current file is checked out on, what it was last merged to (maintaining, say, a BRANCH_1 and BRANCH_1_MERGED tag), and doing the merge and keeping the merge tag up-to-date. Figure out what you're going to do with branches and how you're going to do it, and write scripts to do it. I use Perl. > I would say the biggest deficiency is having to keep track of what's > already been merged, but it's also a pain to figure out what > has changed > on a branch and making sure you've merged what's necessary without > always having the entire repository checked out (time consuming in > itself for large projects). > I have several copies of a fairly large repository checked out right now, and I keep them handy. Disk space is fairly cheap nowadays, and it's usually better to keep the repository checked out than to check it out only when you need it. As far as determining what has changed, this can be done with a little process discipline. Whenever creating a branch, create the branch tag (BRANCH_1), a merge tag to keep track of what has been merged to wherever you merge to (BRANCH_1_MERGED), and a start tag to record where the branch started (BRANCH_1_START). > 2) Building a unified development process on top of CVS; e.g. > enforcing > conventions and policies which are inevitable as the size of > the project > grows. The hooks again are too primitive and each script > shouldn't have > to be called for every directory involved. The interfaces to the hooks > are all different and not enough information is available, e.g. what > branch is this on? I'm continually frustrated by the holes in the > support for the checkin templates in the client/server methods as well > as the lack of interactivity with the callout scripts. > This is a problem; it is not necessarily possible for the verify scripts to enforce policies. How necessary it is to enforce the policies (as opposed to, say, detecting violations and talking to the violator) is itself a matter of policy, and some projects may need to enforce them. In this case, I'd suggest some sort of approach where checkin or tag approval is granted separately, in another sort of system, and a simply verifymsg (for checkin) script checks that. It's not ideal, but I don't have experience with anything that is. That's what we're planning to do. The standard answer is that CVS is intended for source code management, not development process control. It wouldn't be suited for development process control, as all such tools I've seen tend to assume a certain process, and CVS is intended as a generally useful tool. The hooks could indeed be improved, and there's been discussion of that in the past. > > My sense is that CVS is adequate for small, fairly > independent projects > (even large numbers of small, independent projects ala > sourceforge), but > it's certainly not industrial strength. Unfortunately, nothing else is > either, so most commercial efforts end up growing their own. > It seems to work well on larger projects, although I have no experience with it on really large projects. Do you mean that most efforts grow their own process on top of an existing SCM system like CVS? It seems to me that growing a SCM system is not a trivial thing, and that it would be best to start with something like CVS and grow from there. There are other available systems. ClearCase is frequently mentioned as superior to CVS in many ways. The Subversion project at www.tigris.org is designed as an improved CVS. It will feature better branch and merge handling, although I don't know anything offhand about its hooks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Linux security issues as they pertain to CVS
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 25, 2001 7:48 PM > To: Mark > Cc: CVS Mailing List > Subject: Re: Linux security issues as they pertain to CVS > > > The problem is that pserver cannot be made secure. Literally cannot. > It runs on a raw, insecure TCP circuit and is subject to all kinds of > man-in-the-middle attacks, connection hijacking, spoofing, etc. > Any problems with running pserver over an encrypted channel? It seems to met that would be just as secure as ssh access (and, of course, just as unsafe - the biggest potential security problems being the guys on both ends of the channel). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Information about multiple checkouts
> -Original Message- > From: Bhavaniprasad Polimetla > [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 24, 2001 7:01 AM > To: CVS > Subject: Information about multiple checkouts > > > Dear Sir, > > I have the following situation. > > User a checked out file abc.java > When user b try to check out, it need to tell that user a already > checked out that file. > How can I implement it in CVS? > First, exactly what do you mean by checkout? In some systems, it gives you a copy of the file and a lock, so that you are the only one allowed to work on it. In CVS, it gives you a copy of the files and allows CVS to manage them (by means of metadata in a CVS directory). The assumption in CVS is that everybody who works on a project will have their own local copy of everything that concerns them. The standard way to implement something like lockin in CVS is to "cvs watch on" and ask developers to use "cvs edit" to unlock files before changing them. This is advisory only, and there is no way to enforce locking, but if your developers will deliberately bypass your procedures you've got a much worse problem than any version control system can solve. In practice, advisory locks work just as well as hard locks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS bookmarker or addressbook
> -Original Message- > From: Christian Robottom Reis [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 22, 2001 2:08 PM > To: [EMAIL PROTECTED] > Subject: CVS bookmarker or addressbook > > > > Us people that delve in the maze of Free Software > repositories have one > task that's dull -- keeping track of the CVSROOT strings for > every project > we want to pull. > > Is there something shell-oriented that provides something like that? A > means to add and use root strings by a key or an index? This would be > quite useful, and I'm sure I'm not the only one looking. :-) > I don't understand the problem. Each project has a CVSROOT string that is a pain to type, but usually you need to type it precisely twice. After that, the information is in the CVS/Root file for the project, and the password is in ~/.cvspass. For example, I've got a local checkout of CVS here somewhere. If I have that as a working directory, CVS will assume I mean to use the cvshome repository, and everything works just fine. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: using different user
> -Original Message- > From: richard degetel [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 18, 2001 3:20 AM > To: [EMAIL PROTECTED] > Subject: using different user > > > When I want to be log in a different user, I change the > preference setting > but when I do cvs login, cvs did as I wanted to log in whith > the old user > CVS will, apparently, want to log in as whoever is specified in the root value (i.e., ":pserver:[EMAIL PROTECTED]:/home/ces/repository"). If this is specified with the -d option, it will use that value. If not, it will use CVS/Root if that exists, otherwise the CVSROOT environment variable. Presumably you're in a directory checked out under username A, and you're using username B, and so it looks at the CVS/Root file. (We're having a somewhat similar issue. We often, in the course of reviews, want to use "cvs diff" in people's code. This requires logging in again, which is not a problem since everybody's got the same CVS password, for simplicity.) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: problem with LF <--> CRLF trasnlation
> -Original Message- > From: Mike Castle [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 15, 2001 9:28 PM > To: info-cvs > Subject: Re: problem with LF <--> CRLF trasnlation > > > > But. > > The rule of thumb is: only check out onto the machine that > your are going > to make changes on. > > If you are going to compile/edit on a Windows box, use a > windows client. > If you are going to compile/edit on a Unix box, use a Unix client. > If you are going to compile/edit on a Mac, use a Mac client. > Yesterday, I had a problem in that a coworker had a file in cygwin that had been edited with something that left it with Windows line endings, and CVS checked it into the main repository (on a Unix machine) with Windows line endings. Should I encourage developers to continue to use CVS on Cygwin, or should I push them to use WinCVS? Cygwin acted as if it were in the twilight zone between Windows and Unix in this case. > ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Newby : moving/renaming files loses version information?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 16, 2001 7:43 AM > To: Hondros, Constantine > Cc: '[EMAIL PROTECTED]' > Subject: Re: Newby : moving/renaming files loses version information? > > > "Hondros, Constantine" <[EMAIL PROTECTED]> writes: > > > Does moving / renaming a file in CVS necessarily mean that > the "new" file > > ends up at version 1.1? > > If you do it in the way you describe (which is the only way that I > know about to do it without directly frobbing the repository) then > yes. > Since it is generally advised to ignore the version numbers and keep track of things with tags, this is not usually a problem. It is possible to do "cvs commit -r ", but that usually doesn't buy you anything. > > I followed the instructions at the (excellent) red-bean CVS > tutorial thusly > > : > > > > floss$ mv oldname newname > > floss$ cvs remove oldname > > floss$ cvs add newname > > floss$ cvs ci -m "renamed oldname to newname" oldname newname > > > > and found that the "newname" file started at version 1.1. > > > > Is this situation avoidable? > > Yes, if you're willing to move things around in the repository itself, > and if you're willing for the resulting file to show up in the old > location when you do a checkout based on an old date or tag. > Just do this: > > 1) in the repository, do "cp oldname,v newname,v" > 2) in a work directory, do "rm oldname; cvs remove oldname; > cvs commit" > 3) Still in the work directory, do "cvs update" to get a > working copy of newname. > This keeps the history, but has the potential to check the file out twice. If I do that, I always remove all the tags from newname (cvs stat -v to get the tags, cvs tag -d TAGNAME newname to get rid of the tags). If the file is on active branches, it's better to get rid of version tags only, and kill oldname on all branches by "cvs update -r oldname; rm oldname; cvs rm oldname; cvs commit", branch by branch. Every way of renaming a file in CVS has awkwardnesses or inconveniences. If you move the file in the repository, you lose the ability to check out the file with the right name for previous tags or dates. If you copy the file in the repository, you can wind up getting two copies. If you remove and readd without touching the repository, you've split the history and made it difficult to get diffs between versions. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Secure Connections
> -Original Message- > From: Echlin, Michael [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 14, 2001 3:38 PM > To: 'Santimore, Matt' > Cc: '[EMAIL PROTECTED]' > Subject: RE: Secure Connections > > > Hi, > > As someone else has already said pserver will use the unix > login passwords > of anyone who is a user on that unix server. Set-up all of > your wincvs users > as users on your server and put them in the right group to > see your cvs > repository. I felt very uncomfortable in doing that, since it leaves the unix passwords hanging out in the open, albeit in encrypted form. I simply assigned a standard CVS password and told people to use that. I have no qualms about leaving CVS insecure, because I figure CVS is insecure, and there are other ways to limit access. BTW, I've run into an inconvenience. In the process of checking over one another's code, we're constantly using CVS in other people's directories (primarily "cvs diff"). Is there a way to avoid having to "cvs login" in every new account accessed, since the trees in different people's accounts have different CVS/Roots now? (For example, I've logged in for my own account, CVS/Root file being :pserver:me@cvs:/..., and now I have to review Roland's code. Roland's code is in his directory, CVS/Root file :pserver:Roland@cvs:/..., and before I do a "cvs diff -u" I have to "cvs login". Fortunately I set up all the passwords the same, so it's no big deal.) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Administering questions
> -Original Message- > From: Anita Chacko [mailto:[EMAIL PROTECTED]] > Sent: Sunday, May 13, 2001 8:57 PM > To: [EMAIL PROTECTED] > Subject: Administering questions > > 1.Is it a good practice to allow every developer in > the project to add/delete files/directories in the > repository according to their requirements?Or should > this be restricted such that only the cvs admin will > be able to do this?Any good reasons for whatever the > answer is?Should these additions/deletions be > documented? Here, every developer can add or delete files as needed. The neat thing about SCM is that, assuming that the developers don't have direct access to the repository and don't use some of the less-known features of "cvs admin", everything is recoverable. If you have an incompetent or malicious developer, that person can cause a good deal of temporary confusion, but (after that person is fired), it will be possible to clean up. The one problem I've had with having developers add files is that they often add them only to the branch that they're on, when they should also be on head. I've largely solved that by providing a add-file script for people to use. > 2.Same question as above with regard to check > ins.Should the cvs admin handle all the check ins?Any > reasons for this? I see no good reasons for this in normal use. There might be reasons to have one person do the checkins in special cases. Perhaps the repository and development staff are large, and there have been problems with updating during large checkins and not getting a consistent view of the repository. (Even so, it might be better to have reserved times for checkins in that case, rather than having an administrator handle it.) I'd suggest letting developers do their own checkins. > 3.Is there any purpose/use in documenting all check > ins? > Um, documenting how? They're already logged in the history file (if you've turned that on), and will be listed in the output of "cvs log" for a file. We require checkin comments that link the file to the PR, and a list of changed files in the PR itself (we use Gnats for bug tracking), and forbid people to check in without a valid PR. This has been enough to handle all desired inquiries for us. > I can't say how much I would appreciate any help as I > am really at a loss and have no senior persons to whom > I may put such questions.Infact before me,there was no > version control system used at all in this project. > Look on the bright side. Anything you do will make things a lot better. You will almost certainly make mistakes, but SCM run by somebody who does a pretty good job is much better than no SCM at all. CVS runs well in the absence of much administration (the state of affairs here before I took it over). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: query tag
> -Original Message- > From: Zanabria, Moises [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 11, 2001 3:25 PM > To: '[EMAIL PROTECTED]' > Subject: query tag > > > Hi there: > Is possible to know who person created a tag?? > How can I do this? > If you have history enabled and usable (I can't access the file here because it's become too large) you could use "cvs history" with the proper options. It apparently won't tell you what the tag name was, but it'll apparently tell you who and when and on what file, and you may be able to figure it out from that. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: problem with cvs log -d
-Original Message-From: Gabrio Verratti [mailto:[EMAIL PROTECTED]]Sent: Friday, May 11, 2001 1:52 PMTo: [EMAIL PROTECTED]Subject: problem with cvs log -d one of my colleagues modified a set of files three days ago. I need to back out what he did and I cannot contact him to find out which files he touched. I wanted to use the date range feature of cvs log to see all commits from the developer in question on the given date, but I cannot seem to be able to get the date format correct. I have tried many different formats, of which, I've listed only a couple: cvs -v Concurrent Versions System (CVS) 1.9 (client) I believe that this is your problem right here. 1.9 was not Y2K-compliant, and I've seen problems with trying to specify post-1999 dates in that version before. I think you may have to upgrade, preferably to the latest 1.11.1 version. This is probably not the best time to upgrade, but I don't know if you can make that work on 1.9 at all, and you really should have upgraded before January 1, 2000. (I think that may be why there's a lot of 1.10.7s out there - that was the latest version available in November 1999 or so when I got the job of upgrading.) Brokat Technologies 150 Almaden Blvd. San Jose, CA 95113 (800) 876-4900 www.brokat.com
RE: Suspicious email message intercepted
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 12:57 AM To: Donald Sharp Cc: Laine Stump; [EMAIL PROTECTED] Subject: Re: Suspicious email message intercepted [ On Wednesday, May 9, 2001 at 14:18:51 (-0400), Donald Sharp wrote: ] >> Subject: Re: Suspicious email message intercepted >> >> Actually it's a fairly good thing to send out the warning email >> to a list. People might thus avoid getting the virus. Alternatively, somebody might read through all the warning messages and be sufficiently numbed when he or she reaches the actual virus to do something stupid. Or take so long wading through them that the person misses something important in the mail. We had about half a dozen warnings sent to the list for one malicious email. If three of them had hit the list, we'd have enough warning messages to fill a screen. >Actually it IS NOT! NEVER EVER send such stupid lame warnings to a >public list, either by hand or automatically EVER I would except Maarten de Boer's warning, which was interesting and useful, showing people what the virus was. I also trust his judgment in only sending it to the list once. To be more precise, the automated messages to the list said, essentially, "this might be malicious", which is something I'd already figured out. Maarten de Boer said, in one message, that it was malicious and why. I learned something from his message. >If some people want to read the list with vulnerable mail readers then >that's their risk to take. But the idiots running broken scanners must >be taught to never EVER send bounces to list, no matter what the reason! Actually, that's the risk their companies may be taking. I was shifted over to Outlook by corporate policy yesterday (so I'm in a mean mood), and I figure that top management is responsible for that risk. (Not that there's any great danger from me using Outlook as opposed to some of the other people) FWIW, my wife's employer wasn't bothered at all by Homepage, and didn't spam mailing lists either. Her mail software currently strips out .vbs attachments on incoming mail. I'd suggest that as a policy for those who don't want to take the risk of incoming Virus Bombardment System payloads. If you miss something useful that somebody else posts to the lists, then send a private email asking for a zipped version, or included in the message body, or something like that. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: I have a question
-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Sent: Thursday, May 10, 2001 8:09 AMTo: [EMAIL PROTECTED]Subject: I have a question Hello , I am baesy . I work in Korea. I want to control binary file . My OS is Linux . First I make tar-file. I cvs import tar-file . But original file and imported file differ . Size of orginal file is 16691200. Size of imported file is 16691124. And I can't execute tar xvf imported file . Why does it do ? How can I cvs import binary file (*.tar file ) . please help me . I will be waiting for your answer. [Thornley, David] What do you mean "imported file"? Do you mean the file in the repository, or one checked out later? The file in the repository is not supposed to be used directly. And, for that matter, why are you controlling a tarball? Why not skip the whole tar process and just import the individual files? Importing a tarball makes no sense whatsoever. Importing is a way to allow your own development on somebody else's code while keeping track of their changes and merging them in. If they're in a tarball, they're not going to merge, so you're getting nothing out of it. If you must keep a tarball around, use "cvs add -kb" or something like that.
RE: Suspicious email message intercepted
What happens if someone wants to post a vbs script that works with cvs? doanld Fortunately, that's at least less likely. Most of us deal with CVS on Unix boxes of some sort, and Virus-writers' Benefactor System doesn't run on those. Of course, we have had automated complaints about Perl, and I would imagine that lots of us use Perl. Still, some people have to deal with CVS on NT boxes, and I suppose they may use such tools. It wouldn't be so bad if (by my count) six different automated checkers hadn't posted to the list, and if we couldn't expect the same six to do so again the next time somebody uses Outlook absent-mindedly. Could we filter out the incoming messages so that they would have to be from somebody on the list, rejecting messages from people like MAILER-DAEMON? On Wed, May 09, 2001 at 10:26:32AM -0700, Stephen Rasku wrote: > Richard Wesley wrote: > > > > >One wonders which causes more damage - lame virii from socially > inept > >teenagers or endless warnings from well-meaning servers... > > > > Exactly. Would it be possible to configure the list to drop .vbs > submissions so we don't have this problem? > ___ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
