Re: Antigen found =*.pl file
ANTIGEN_NA-ATC wrote: > > The following message is from the Alcoa Exchange Virus Protection System. > An attempt to send the File Cvsweb.pl matching the filter =*.pl for a > potential Virus from [EMAIL PROTECTED] > The file was Deleted. The message was, "cvsweb - strict, use CGI with > enhancements". > > Please ensure that your PC has Anti-Virus protection with current > definitions to detect and clean Viruses. Will whoever owns this dog please leash it in the future? There are very good reasons to include Perl scripts on the info-cvs mailing list, and we're all smart enough to look at them before using them. Putting out gratuitous irrelevant email whenever that happens is bad nettiquette. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: cvs-nserver and latest CVS advisory
"Greg A. Woods" wrote: > > > > But the real culprit gets away. This wouldn't happen with SSH. > > > > The culprit gets away no matter what. There's nothing I can do to > > them even if I find out which email address is really associated > > with the attack. > > No, with SSH the culprit cannot "get away". You've got a finger > pointing right at them, and a mound of evidence to show what they did, > when, and how. I.e. you have a counter-threat, and possibly one that's > far more powerful than the threat they posed to you earlier. Correction, Greg. In the SSH scenario, Justin has a finger pointing right at the account used, not the culprit per se. In some cases, this makes very little difference, and I have the impression that you function in those cases. Specifically, what is Justin to do when he finds, say, [EMAIL PROTECTED] (aka [EMAIL PROTECTED]) was behind some exploit? It's far more work than it's worth for him to come after me legally (IIRC, he's Canadian). He can revoke my access and inform my ISP, who may well cancel my account. There are plenty of other places I can get an account if I want to come back and taunt him a second time. If he were willing to take legal action, then it would matter that he had a finger pointing to me. If he had some sort of face-to-face link with developers, he could make sure I never got access again. In those cases, it would be very useful to have such accountability. Jon Bentley had a Programming Pearls column with wise sayings from the field (two, actually). One was "Never test an error condition you're not prepared to handle." In this case, Justin, using the best available security procedures, could perhaps find out that the culprit is [EMAIL PROTECTED], rather than [EMAIL PROTECTED] What is he going to do about that information? What if, after that, he gets a request for access from [EMAIL PROTECTED] (or whatever account name I got)? So, in Justin's case (and obviously not in Greg's), the additional accountability from SSH is not that important, and the barrier it presents is, in Justin's opinion, a more serious problem. Again, if somebody would like to change Mac and Wintel CVS clients to use SSH, presumably protocol 2, that would be very useful. Until it happens, SSH is going to be a problem for people not working off Unix platforms. As long as that is the case, people like Justin have to make some hard decisions as to what policy will work best. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
"Greg A. Woods" wrote: > > > > I ran [SSH] for six months and none or few of my WinCVS clients got it working. > > Now some documentation has been posted explaining how to do it, but I can > > see that it's a fairly painful installation. Hopefully that will change soon > > and I can really use the ssh solution. > > *YOU* should have been capable of writing that documentation in the > first place and ensuring that your users understood it sufficiently. Very likely capable. Does this mean it's a good idea? You can spend arbitrarily large amounts of time and effort and inconvenience on security, but eventually you have to get some work done or you've got nothing to be secure about. It would be beneficial if Justin were to make it easy to use SSH for Wintel boxes and Macs, but it's additional work that is not necessarily a good idea for his application, given his risk assessment. (BTW, I've only been able to find two SSH implementations for the Mac. One is commercial, costing a few hundred dollars, and one is not legal for use in the US until September 21, due to US Patent Office cluelessness. Fortunately for me, I've just installed a Linux box at home.) > You can use that documentation *NOW*. You should be capable of using > that documentation to build, or solicit the building of, a well tested > canned configuration for the necessary tools (eg. a self-installing > package) such that you don't even have to educate your users in mundane > issues that you don't think they should have to deal with. > That would be a useful project, and it would be nice if somebody would undertake it. And, yes, it's about personal computing, and, yes, personal computing can be a nightmare to professionals. On the other hand, it's useful, prevalent, and fun, and it's not going away. Professionals have to deal with personal computing in some way or another, and I don't think that trying to ban it from serious work is the best way to go. It's like the management structure set up around the CVS repository here: it isn't ideal from the CVS point of view, but it serves the needs of the company very well, and CVS can be set up to handle it. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
Mike Castle wrote: > > On Wed, Aug 09, 2000 at 02:34:02PM -0400, Justin Wells wrote: > > On Wed, Aug 09, 2000 at 12:06:53PM -0500, Mike Castle wrote: > > > On Wed, Aug 09, 2000 at 11:54:33AM -0400, Justin Wells wrote: > > > > Is it as easy for a WinCVS user to set up ssh as it is to set up pserver? > > > > > > Yes. > > > > No it isn't. You can use pserver with WinCVS directly by configuring WinCVS > > with no extra effort. To use ssh you have to go and do all kinds of > > complicated installation things outside of WinCVS. > > Not if you already have ssh installed. > > And if you don't, well, gosh, to use WinCVS, you have to *gasp* install all > kinds of complicated software outside of CVS! Oh no! We can't have that! > The user will NEVER get it right! We'd best only let them use cvs from the > command line! > Are you sure? I have very limited experience with Microsoft Windows, but there is an InstallShield thing that can make it easy to install complicated software, provided you want to set it up the way the guy who made the install package was thinking. I have no experience with WinCVS, but it might well come with an InstallShield or other thingy that makes it relatively easy to use WinCVS with pserver and require much more work to use ssh. It's Microsoft Windows, after all, and there's all sorts of interesting stuff you can get wrong trying to do things yourself. > Honestly, if someone can't set up ssh, they shouldn't be doing software > development. > You'd be surprised. Or, for that matter, what of somebody using a Wintel box for communication who doesn't want to learn the details of MS Windows? This isn't something relatively straightforward like Unix, remember. Anyway, I don't actually remember Justin talking about software development. It may be the only thing in his repository, but he may have other things, such as web pages, also there. CVS works well on lots of kinds of text files. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: Reserved checkout
Guilhem BONNEFILLE wrote: > > Hi, > > I want to use CVS in a reserved checkout model with centralised access > to repository. It's to say : > - reserved checkout : developpers need to lock files before act ; The best you're going to do is cvs watch and cvs edit, particularly with Noel Yap's patches. Actual locking is not well supported, and what support there is may go away. cvs edit, when properly used, gives you every benefit you would get from locking. > - centralised access : developpers only have read acces to repository. > They need to send their modified files to a configuration manager > (human) which is able to commit works. > Possibly you could use commitinfo or something like that, or use directory permissions. > It's a non natural model for CVS, but it's a model I need to use. > Why? If you don't trust your developers, fire them and hire new ones. If you do trust them, establish procedures that work, and tell them to follow them. The reason why it's unnatural for CVS is that it's unnatural for software development in general. You have to trust your developers to be working for you, not against you; there's too many things they can do if they don't like you that the configuration manager is not going to catch. If this is a management requirement, then you will have to treat it like any other case of irrational management: tell them what they want to hear, live with stupidity, change jobs, whatever. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: Branches vs keyword expansion
"John R. Dunning" wrote: > > In previous lives, I used cvs, branches, and expandable keywords, and > don't ever recall having this problem. So, questions for the > assembled experts: > > 3. Is there any other workaround other than jamming the equivalent of > -kk onto the command line, or putting it in the admin files or > something? > Personally, I consider branch-to-branch merges as too tricky to leave to the individual developer, so I wrote Perl scripts to do the dirty work (of which the -kkv I use is one of them). These scripts prevent several potential mistakes (like wiping out branch tags) and so I try to get people to use them. That way, they come to me less often with questions on "How do we fix things now that I did X?" (The biggest single problem I get is when people type cvs tag -F RELEASE_x_y rather than cvs tag -F RELEASE_x_y_MERGED where the first is the branch tag and the second is the marker showing which changes have been merged to head. Eliminating that was worth the time taken to write and verify the Perl stuff.) -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: Fixing a bad CVS setup... won't make CVS directories!
Stuart R Dole wrote: > > Clients are RedHat 6.1, CVS 1.10.6. (Should they be 1.10.8?) > We call them "nodes" (embedded systems, effectively -- no > monitor or keyboard -- we telnet in). Put "export > CVSROOT=:pserver:root@gaia:/usr/local/repository" in node's > /etc/profile. > Was it 1.10.6 that broke pserver? Try upgrading to 1.10.8 and see if the problem goes away. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: Cvswebedit needs to be made GPL/open source. Any volunteers?
"Todd T. Fries" wrote: > > On Thu, Jul 13, 2000 at 11:17:46AM -0700, Steve Arnold wrote: > > In short, no, and it sucks. RS created the GPL precisely because the BSD > > license was too restrictive. And the XFree86 guys use the GPL because > > they didn't like the X license (again, too restrictive). > > You are off base here. X and BSD allow anyone to do anything with the > source, GPL expressedly forbids anyone to do anything without releasing it. Actually, no. Unless I am sadly mistaken, the GPL allows you to do whatever you like to the software in private (the "consenting programmers" principle). Once you decide to distribute it, the license takes effect: you must release it under the GPL and you must release the modified source code. > GPL is the more restrictive. It is the freedom to 'do whatever' with the > source that RS cannot stand, and thus you and his cronies continue to > suggest that GPL is less restrictive, when in reality, it forces more > restrictions. Specifically, if I'm using code under the GPL, I'm prevented from doing things that I could do if I were to use, for example, X code. The GPL even points these things out: there are programs that you simply may not link with GPL-covered code and distribute. I don't believe this is the case with X code (provided you satisfy the requirements for the code you're linking to). (This is in addition to the practical difficulty of using Gnu code in commercial software.) Now, the people at Gnu obviously think these restrictions are reasonable, and that's fine with me. I can use Gnu software under the GPL or not at all, just like any other. However, it is a more restrictive license than X and BSD in terms of what it allows me to do with software, and there's no point in pretending otherwise. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: Linked Files in the Repository
Donald Sharp wrote: > > I seem to recall that it's very easy to tell MS's C++ compiler the > 'correct' extensions for your file. Why don't you just do that. > Another thing that might be extremely usefull would be for you to > explain your cvs setup some more to us. What are you using? > pserver/ssh? What type of machine does your cvs sit on? How > you connect to the server? I know little of Windows C++ compilers, and I'm not really up on the Apple MrC compiler for Macintosh Programmer's Workshop, but I have worked with Metrowerks Codewarrior for the Mac, and I assure you that you can change the default file extensions easily. If you do so for the template projects it uses, it should be picked up for all future projects. So, in addition, what specific compilers are you using that appear to need different extensions? -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: Adding files to branches
Sheldon Samuels wrote: > > Is it possible to add a file to a branch other than the main branch, without first >adding it to the main branch? We have custom files that apply to a specific >customer, but contain a feature that the application as a whole shouldn't support. >These custom files are add-ons to the primary application. But in using CVS and >WinCVS (I'm new to all of this), I know how to add a file and I know how to create a >branch and assign a file to a branch. But can I add the file to the branch without >first placing it on the Main branch. It seems that the CVS function of "ADD" only >adds files to the main branch first. > You can do that. At our shop, we consider it a nuisance, since it's possible to do it inadvertantly and needs to be fixed afterwards (since we almost never want to add a file without wanting to keep it on head branch). What you need to do, as far as I can tell, is have the directory checked out or updated to the branch tag you intend to use. You can check the CVS/Tag file to make sure the branch is what you want. Then, do a cvs add and a cvs commit. At least that's how it goes on Unix. I have no knowledge of WinCVS and don't know how it would work there. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: Patches or work-arounds requested for lock problems
"Win32 M$" wrote: > > Hi Laird , > > > Well, CVS has two camps of users: > > > Because CVS was designed for (1) and only happens to be suitable for (2) > > by virtue of its price, what you're describing isn't really a > > problem--it's the way that CVS was designed to be used. > > The camps of users are irrelevant - the locks functionality is broken in > many ways. > The problem is still there, no matter how you try to ignore it. > CVS will also not brush your teeth or do your taxes. Does this count as "broken"? I'm going to trot out a couple of stories from my past again. In one shop, we "locked" effectively by writing notes on the listings in the source library. No problem. In another shop, we used SCCS. One developer, who was intelligent, dedicated, and normally clear-headed, made a change on a copy of a program, waited until the program was checked in, and then accidentally overwrote the previous change in the course of trying to get his change into the new head version. My conclusion is that communication works, and hard locking doesn't. Anybody who wants to use CVS with some sort of locking can use the edit facilities, particularly with Noel Yap's patches. This will give all the good qualities of locking. Bear in mind that developers who will subvert this will subvert any arrangement you make, and you do not want these people working for you. In the meantime, the people who do the most work on CVS seem to appreciate the ability to do concurrent development, and see no particular reason to work hard to support file locking. As in all freeware/open-source projects, you are allowed to modify CVS as you see fit, and distribute your changes, and this is considered to be the proper approach to basic disagreements about how the product should work. My recommendation is to remove the CVS locking facility, and make cvs admin -l/L/u/U aliases for cvs edit/unedit. That will take care of all the complaints about CVS's bad support for hard locking. (No, I'm not currently volunteering to do the work for this. The current setup bothers me very little, and I have little free time to work on it right now.) -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Problem with merge
I just had a weird problem crop up. We have a file. At rev 1.8 we split off a release branch, and merged all changes in (so that diffing on 1.8.2.1 vs. 1.9 and 1.8.2.2 vs. 1.10 pick up only the keyword changes). One user made a large change to 1.8.2.2, and checked it in as 1.8.2.3. He then tried merging it to head branch, and was told there were three conflicts. As far as I can figure, CVS looks at 1.8.2.2 and 1.8.2.3, and tries to apply the change to 1.10; despite the fact that 1.10 and 1.8.2.2 are identical (using the -kk flag to suppress keyword expansion), it can't figure out how to apply the change. (I suppose the workaround is to do a physical copy, since we do want it 1.8.2.3 and 1.11 to be identical.) I've never seen a problem like this before. I checked out the latest CVS source and looked in README/BUGS/NEWS/ChangeLog, and found nothing applicable. Does anybody have any ideas? -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: RE ".trunk" patch refinement
John P Cavanaugh wrote: > > > > I may be slow today, but I don't see how merging the metadata is going > > > to accomplish all this [stuff that vendor branches do]. > > Merge Metadata can serve the same function as the vendor branch. > > Typical scenario, a local copy of an open source project, maybe say cvs. > Ill describe a scenario of how you could use this hypothetical cvs to > develop the features to get to the hypothetical version. > What you are proposing is to use the trunk as the vendor branch, and the equivalent of keeping a "last-merged" tag on it to merge onto a branch. This is the sort of functionality that took me three days or so to write perl programs to handle (interfacing with CVS, of course) that were tailored for our development process and which catch a lot of common errors in process and procedure. Specifically, the "merge metadata" idea seems to be nothing more than keeping a "last-version-merged" tag on each branch, and updating it accordingly. (Except that it is not shown to have the ability to *not* merge a change that should not be merged - whereas it's always possible to move the "last-version-merged" tag without actually merging. Presumably such a facility would have this ability, but it's still not looking to me like a great improvement.) > - You import the initial rev onto the main branch. (Say 1.10.8 > or whatever) > > - You create your own private branch (called named_trunk) to make your > changes for say the naming of the main trunk > The CVS way, you've now got a labelled vendor branch and a main branch you can do development on. Your way, you've got a main branch that's got the vendor release, and a private branch you can do development on. In the event that you've got two external products you're combining, you have problems your way, none the CVS way. This may not matter. > - Lots of work happens on cvs to fix bugs etc, or to add new > subcommands like lsvtree. > > - You now import a new rev onto the main branch (Say 1.10.9 > or something) > > - Now to update your private branch you just do a merge from the main > branch by doing something like "cvs up -j main" > > - Even more work happens on cvs to fix bugs etc, or to add new > subcommands > > - You now import a new rev onto the main branch (Say 1.10.10 > or something) > > - Now to update your private branch you just do a merge from the > main branch by doing something like "cvs up -j main". But the > difference now is that it only merges in the differences from your > last merge. > However, the recommended "-j:yesterday" works very well in this scenario, provided of course that you don't import vendor branches more than once every day or two. We don't here; I don't know about your shop. So, now that you've described this, what is the difference between what you've described and what CVS does? The difference I can see is that you want to put the vendor releases on the main trunk, whereas CVS puts them on a labelled branch. Obviously, in this case, merged metadata can do what CVS is doing. However, I really don't see that there is any advantage to doing so. > This model also allows you to have multiple private branches doing all > kinds of various things that are unrelated to each other. Perhaps > one to add rename support, another to add merge meta-data etc. > And the difference between this and intelligent use of CVS would be? We can do things like that already. It requires a little intelligent use of tags. This use can be codified into wrappers that people will use instead of raw CVS commands. Nothing you've described is beyond what can be done with intelligent tag use. It would probably be easier to use for somebody starting with CVS being installed and projects starting yesterday, but that's a pathological case for any support software. There are instructions in the Cederqvist about how to do this sort of thing. This isn't anything new, or anything that hasn't been considered before. So, merging metadata (as you put it) would be a convenience, but as far as I can tell nothing more. If it requires more active CVS administration, it might well be a loss. > > And how did merging (meta)data get into this thread? I'm not signing > > up for _that_, no matter how many people refuse to change the > > subject line. ;-) Wy too hard, and I'm not really sure I even like the > > idea anyway. > > -- steve > > I agree its hard, but its very useful for big software projects with > multiple parallel lines of development its essential. > What do you mean by "multiple parallel lines of development"? How parallel? (ISTM that, if they don't track each other, they're going to diverge, and that will destroy the "parallel" part.) Would it qualify to have head branch and two or three releases on which development is happening? This is not giving any great amount of trouble. > If you havent done multiple parallel lines of development (ie. like 3 > or more) you wont see
Re: RE ".trunk" patch refinement
"Cameron, Steve" wrote: > > David Thornley wrote: > > > [...Regarding support for redundant ".latest" suffix for branch tags.] > >And similarity with the main trunk. There's no great harm in synonyms. > > Except people have to write the code to support them, spend the effort > to understand that code when debugging, maintain that code, test > that code. If it doesn't add significant value, why put it in? synonyms > like this don't add real value, IMHO > [...] Depends on what the code is doing. Sometimes it makes sense to make everything orthogonal, even when it causes redundancy. The code complexity depends on how much is put in to support the synonyms and how much would be put in to suppress them. Anyway, it's nice to have orthogonality when writing tools to use CVS. It's something of a pain to have to treat the main trunk differently from a branch. That is likely to create more extra code than putting the synonym in would, although the code will be a lot more distributed. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: ".trunk" patch refinement
John P Cavanaugh wrote: > > On Thu, Jun 22, 2000 at 10:02:19AM -0500, Cameron, Steve wrote: > > > > > - Name the main trunk "main" or "trunk" and just deal with the > > > consequences of people that already have that branch name > > > > Why should we break things when it's not necessary? ".trunk" > > isn't so hard to type, you don't even have to hit "shift". > > Partly for personal preference of liking main or trunk better than .trunk. > But it also allows for main.latest (which I will admit is only to facilitate > similarity with other branches) > .main.latest types easy too. (. is in the central part of the three basic rows of the QWERTY keyboard, and doesn't require a shift key.) > > > - Delete the whole concept of HEAD, instead generalize it to something > > This I think can agree with. > > > > > really useful and scaleable like > > > .latest - For the latest version on a branch > > > > ok, that's an oversimplification. but this ".latest" thing doesn't do > > anything > > that the branch tag by itself doesn't do already, is my point, so I think I > > have > > to vote against that one. > > Well sort of, I included it just for similarity with branch.base > And similarity with the main trunk. There's no great harm in synonyms. > > > .base - For the version where the branch sprouted > > I haven't thought about BASE, or what it means, at all, not one whit, so I > > haven't yet formed an opinion. > > Its nice to be able to easily figure out where your branch sprouted from > using an abstract mechanism. > Or an explicit tag. One thing that everybody says is to tag the base of any branch being cut. Any more or less mechanical thing that lots of people say should always be done is a prime candidate for automation. > > > - Allow importing directly to the main branch, > > I think I agree with this, the key word being "allow". > > > > > get rid of the import branch. > > I don't agree with this. I'm not experienced with vendor > > branches, but from reading what little I have about what's > > going on there, there is a definite purpose and method to > > the madness, I believe. I don't think they can or should be gotten > > rid of. But I'm sure someone more experienced with vendor > > branches will pipe up. > > > > Perhaps there's even some reasoning related to vendor > > branches which can explain a method to the madness > > around "cvs diff" and "HEAD", though nobody has yet > > explained it to me. > > The vendor branch in my opinion is a gross hack in an attempt to > mask some really deficient functionality in cvs, namely merge > meta data. If we had merge meta data we would never need the > vendor branch. Yes it would be a different model, and yes Im > going out on a limb here, but it would be a much better model. > I think we need to keep the vendor branch or equivalent functionality. Some of the things we need to do: - Restore earlier releases, even if the guy who installed them threw them out - Merge the changes we've made from the old release to the new release - Keep track of which changes were made by the vendor and which locally I may be slow today, but I don't see how merging the metadata is going to accomplish all this. > For those interested there are some cosource.com project and funding > related to these items. > > CVS Advanded Merge & Metadata Support (Currently at $3700) > http://www.cosource.com/cgi-bin/cos.pl/wish/info/187 > There's an issue that I didn't see covered in the advanced merge issue list, which is when somebody makes a change to a branch that should not be merged forward. One example might be that a bug has to be fixed on a branch, but it was fixed in a different way on head, along with other changes. It shouldn't be difficult to say "this change is only for this branch, and should not be merged". (In my shop, we maintain merged tags for branches, and simply advance the tag for changes that should not be propagated.) -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: ".trunk" patch refinement
"Greg A. Woods" wrote: > > [ On Monday, June 19, 2000 at 17:13:10 (-0500), David Thornley wrote: ] > > Subject: Re: ".trunk" patch refinement > > > > Since it's a very natural thing to do, lots of people have done > > it. It's easy (and correct) to say they should not have done > > that, but the important fact is that it has been done. > > However the important thing now is to continue to deprecate that > practice. Certainly. This does nothing to fix any existing problem. Nor does it help if somebody imports RCS files that have 2.x or higher rev numbers. That includes removing the instructions for doing it from the > manual (and replacing them with dire warnings against doing it), and > most definitely not adding new code that's expressly designed to handle > only one of the corner cases that this sillyness introduces. > Um, why not? And what are the other corner cases? If you use the rev number like a cookie, what problems are likely to result? In any case, one of the things we keep saying is never to use the rev numbers, and so you're claiming that the proper way to reference the head is to use the rev numbers? That looks like a kludge to me. So, since a kludge works on repositories that have never had a certain mistaken operation done to them (one that is easy and natural), you're against providing a clean way to handle the problem? > (If someone found some way to clean up *all* of the corner cases, and if > they could justify the effort this would take even in the face of the > design goal of using symbolic tags to identify such things, then that > might be a somewhat different matter) > Are you saying that there might be a reason to change the rev number to 2.x or so? I don't think so. I think CVS works best, and is likely to continue to work best, when people treat the rev number as a raw identifier for the change. This doesn't mean that it isn't worth handling cases where somebody has previously changed the rev number. > > Mike Little referred to "some previous cvs admin", and this is > > precisely what happened in my case. Some previous CVS admin > > put some of the rev numbers to 2.x, and there's no way I can put > > It may be possible to renumber the trunk back to "normal", especially if > there aren't too many branches in your repository > There are too many. > > You can also leap-frog into a new repository starting fresh with "1.1" > at some major milestone in your project. The actual amounts of use of > history information is usually far lower than people surmise without > measurements and indeed is extremely low if you only examine events > where users back past a major milestone. You don't have to 100% cut > them off from the old history either -- just keep it in a read-only > repository for easy local access and then occasionally audit to see how > often it's accessed before you retire it for good. > We routinely have to change code that's three or four milestones back, when (for instance) a client runs into a bug. Keeping this code read-only is not acceptable. Further, we consider it important to be able to match source changes with the Gnats PR they are associated with. If we were to change the rev numbers, we'd have to find some way to change them in the PRs. This seems to me a major project to support a particular kludge. Another issue is that we can't invalidate everybody's workspace without major consequences. Most people have projects going pretty much all the time, and there's no time in which everybody's workspace is synchronized with the repository. Forcing such a synchronization is going to be expensive. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: ".trunk" patch refinement
[EMAIL PROTECTED] wrote: > > > I would just like to point out that trying to use CVS revision > numbers as module or system version numbers is a bad, bad thing > to do. This cannot be reiterated enough, and I realize that you > did not suggest doing it Mike, but some people might get the > mistaken impression that this use of revision numbers is not > the mistake that it is. > > Rex. Right. It's unfortunate that CVS supports the reassignment of revision numbers. It's a very natural thing to do to move all the rev numbers up to 2.1 for release 2, rather than creating a tag, which is of course the correct thing to do. Since it's a very natural thing to do, lots of people have done it. It's easy (and correct) to say they should not have done that, but the important fact is that it has been done. Mike Little referred to "some previous cvs admin", and this is precisely what happened in my case. Some previous CVS admin put some of the rev numbers to 2.x, and there's no way I can put them back to 1.x. This has doubtless happened to many admins; either they inherited such a repository, or they created the problem themselves while not knowing better. Either way, any technique that assumes that all main trunk development is on rev numbers 1.* is useless to me, and probably to quite a few people. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: Off topic, sort of: best ChangeLog practices?
"Greg A. Woods" wrote:
>
> One of the problems with ChangeLog files is that unless they are
> *always* generated automatically they have a tendancy to be "different"
> in unpredictable ways from the "real" logs.
>
Right. They aren't authoritative. I don't see that they have to be.
They can describe, very quickly, what sort of thing was done and
when. If you need to find out exactly what was done, there's always
"cvs diff -u -D ... -D ... | less".
> Typically I always commit all the files at once with the same CVS
> command (something that's quite easy to do and now even more trivial to
> do with PCL-CVS) and thus I do end up with the identical log entry on
> each related revision in each file.
>
Right.
Still, if I were to wonder if there was a change done to support the
FOO environment variable, there's something to be said for reading
the ChangeLog as opposed to doing "cvs log" on likely-looking
files.
ISTM that there's several levels of documentation here, for different
uses. The ChangeLog is for humans to read, providing an overview of
changes done to the system. The "cvs log" is for humans to read,
providing a history of what was done to a given file and why. The
source code is for the machine (and, I certainly hope, humans) to
read, and that provides the definitive answer of what was done in
detail.
> But unfortunately even if you religiously use something like PCL-CVS to
> automatically update the ChangeLog file, or even "rcs2log" to generate
> it at release build time, it's still just a "copy" of what I would hope
> is the authoritative information.
>
Not necessarily even a direct copy of the authoritative information, but
still useful.
> There's a *LOT* more to be said of more formal documentation, including
> detailed release notes written by someone who reads both the log entries
> and the actual diffs! ;-)
>
That's another piece of documentation, which has the distinct advantage
of being useful for the paying customers. It can be done somewhat
post facto, and probably should at least be revised before shipping
to be more than a chronological list of random changes, some of which
the customers really don't need details of. ("The foo subsystem has
been changed to assure faster performance" is probably better than
"Changed event queue in foo to use a heap" and "Consolidated database
queries in foo initialization" and "Moved slow action from inner to
outer loop" for the customers.)
--
David H. Thornley Software Engineer
at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/
Virus warning to CVS fans: I LOVE YOU
Do not open any emails with the subject I LOVE YOU, particularly if you are using Outlook Express under Windows. For details, see http://www.f-secure.com/v-descs/love.htm (but not from Internet Explorer if you've been hit already). -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
anoncvs, firewalls, and security
I'm trying to use anoncvs here, and am getting "Connection refused" so fast I think it must be the firewall. My sysadmin has assured me that port 2401 is open for outgoing connections. So, I've got a few questions. Is opening 2401 for outgoing good enough to get source by anoncvs? (It's possible that he made a mistake, or there's some more configuration that needs to be done.) Are there any additional security concerns with allowing incoming connections aside from those common to all ports? -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: question (preference?) about xmalloc
Derek Scherger wrote: > > > > For safety, I propose that xmalloc zero out the memory it allocates. Any > > > comments or rebuttals? > > > > > For safety, I would prefer it does not. I don't think we should > > use non-portable solutions to cover up the faults of badly-written > > software. I'd feel more comfortable using the software knowing that > > some classes of errors would have been discovered. > > So you would rather have problems occur *randomly* depending on what the > values *happen* to be at the moment? Personally, if something is not > properly initialized I'd like a core dump every time so that it is found > and fixed quickly. > Ideally, I'd rather not have problems. Since that isn't possible, I'd like them to show up definitely and emphatically. I don't like solutions that patch over problems in most cases, particularly since CVS is used in a very wide range of environments to control very important files. (My company's primary asset - aside from people - is the software base currently managed by CVS.) If xmalloc is to initialize memory, I'd prefer it to be initialized to something obviously bad. Jonathan Gilligan had some very good suggestions. Now, "obviously bad" is system-specific, but it's better than initializing to a value selected to be innocuous. (Steve Maguire, in "Writing Solid Code", p. 49, gives some good pointers on selecting a bad value.) So I'd rather have random crashes than lurking bugs, assuming the crashes occurred sufficiently often, and I'd rather have reliable crashes than random. About the free(0) issue: ISO C requires free() to handle a null pointer correctly, so any concern on this part is catering to non-standard C libraries. It's been over ten years since C was standardized by ANSI, and it's even gotten a new standard. If we're going to make sure CVS runs properly on non-standard C implementations, we should try to make sure it runs properly on odd hardware with conforming implementations also, and that means not relying on the value of binary zeros for pointer or floating- point values. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: question (preference?) about xmalloc
Noel L Yap wrote: > > I've noticed that xmalloc does not zero out the memory that's just been > allocated. Right. It shouldn't have to. Well-written programs do not access uninitialized memory. This doesn't jive well when adding new fields to existing structures > (specially these structures don't have a common constructor-type function to > initialize the memory). If they are complicated enough to need some sort of constructor function, then that's what they should have. This may make it more difficult to make certain changes to the code, but it seems to me that making such changes is going to make the code harder to maintain in the future. Further, it adds to the unwritten assumptions that the code depends on. I realize that there are a good many hacks in all the software that we're using here, but I see no reason to encourage these hacks. What winds up happening is that these fields contain > garbage. This is fine when these fields aren't used, but when these fields are > pointers, they are always used by the function that frees the memory causing a > core dump. > Yes. This tends to happen with code that mismatches mallocs and frees. I consider this at least partly a useful feature, in that it points out that there is a problem with the code, and the dump will show what's failing. > For safety, I propose that xmalloc zero out the memory it allocates. Any > comments or rebuttals? > For safety, I would prefer it does not. I don't think we should use non-portable solutions to cover up the faults of badly-written software. I'd feel more comfortable using the software knowing that some classes of errors would have been discovered. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: Disable "cvs tag -F" of branch tags
"Greg A. Woods" wrote: > > [ On Wednesday, March 29, 2000 at 13:06:20 (EST), [EMAIL PROTECTED] wrote: ] > > Subject: Disable "cvs tag -F" of branch tags > > > > Maybe this falls under the "yeah, and any idiot who accidently types 'rm -rf > > /usr' should have to accept the price", but it would sure seem like an easy > > fix for CVS to not allow the -F option when the tag is a branch tag. > > > > What do YOU guys think? > > Yes, that seems logical -- CVS should not allow a branch tag to be > moved, particularly if it would be converted to a normal tag in the > process. > Yup. About fifteen minutes ago, I typed the wrong tag and changed a branch tag into a normal tag. This would not have happened if the restriction above had been in place. I have mistyped things in the past. I have every reason to believe I will mistype things in the future. I appreciate all the help I can get to make sure these mistypings don't do anything too bad. In this case, it looks irrecoverable. I updated to the correct revision and created a new branch tag with the old branch tag name, but this will mean that any future revisions on that branch will have a six-digit revision number rather than a four. I've effectively cut off a branch and added a twig. If I'm lucky, nobody's going to change that branch any more. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: RCS style locking
Ben Leibig wrote: > > Any idea how to make this system work with the WinCVS client and a UNIX > repository? > Unfortunately, I'm completely unfamiliar with WinCVS. The trick here is to have some sort of reminder to use "cvs edit". On Unix, having the files read-only serves as a reminder when somebody tries to edit one. I don't know what the equivalent sort of reminder would be in Windows. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: RCS style locking
Ben Leibig wrote: > > Well, I've tried as hard as I can, but I can't convice our developers that > RCS locking is not necessary when using CVS. They're all old school, and > they don't trust CVS's ability to merge, nor do they claim they need it. If they don't need it, then they're never trying to work on the same file at the same time, so they don't need locks. But I digress > THey do however want the whole remote repository ability, which means I'm > in a hard spot. I need to figure out how to provide locking (every file > gets locked everytime it is checked out and unlocked everytime it is > commited.) Using CVS, or to provide a remote repository system using RCS. Nope, not in CVS. If these are hard requirements, you'll have to try to find something else that's going to work. The "cvs watch" facility could be used. If you have "cvs watch on", then files are checked out into the developer's directory in read-only mode. The developers will then use "cvs edit" to unlock the files. You may want to look into Noel Yap's "cvs edit -c" patch. This is, in my experience, the most restrictive form of locking that makes sense. It is easy to subvert, but, then, so are more restrictive locks. > Actually the developers even want to have a copy of the checked out source > all running in one directory on one of the UNIX servers. When they check > out they want the file's permissions in that directory to change so they > can access it untill the check it back in, then they want it to go to read > only for everyone. The proposed procedure will provide multiple copies, one for each developer, and each directory will have only the appropriate files read/write. This isn't what the developers are asking for, but it's the best CVS is going to do. It also strikes me as a lousy way to work, since you're working in an environment where you can't control changes. If a guy who's working on a header file goofs and goes to lunch, you can't compile in that directory until after his lunch. In the CVS environment, you get only checked-in changes, and only when you ask for them. Not quick hacks that don't quite work yet whenever. I'm not sure how possable any of this is. It seems > like what we really need is a client/server version of RCS. You need more than that, I'd think. I really doubt that there is a system that'll do exactly what you've stated without a lot of customization. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (612)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: new guy - hopefully easy questions
"Michael R. Salazar" wrote: > > Dear CVS listers, > > I'm a new user of CVS and I have, what I hope, are easy questions. > I have a rather large code that multiple users will be editing. Each > user will need the entire code for their improvements. So, branching > seems to make sense in this situation. My ideas are: > > 1.Have a centralized repository where each user can branch out of > and create their own repository with the whole code in it. > > 2.After the individuals make their improvements, then they may > update the centralized repository. > CVS does not support this. If you are determined to do this, you'll have to find another tool, or go to a lot of work to make CVS do this. > I don't want a repository that each user has access to and is being > updated often by the individual users, because each user needs the whole > code and this senario seems that it would create alot more problems with > users attempting to commit their improvements while other users have > checkout earlier editions. It seems like that, yes. In practice, it usually is not much of a problem. That's one of the things that people find hard to believe about CVS, which is why you'll see discussions all over the place, including the original Berliner paper. There's tradeoffs here. If you make updates infrequent and large, they have a greater potential to cause problems when made. If frequent and small, they have more opportunities to cause problems but less potential. In practice, both work. > > As you all can probably tell by these questons, don't assume too much in > your answers. If possible, please provide the necessary commands and a > brief description. The architecture on which I am running is SGI Irix > 6.5. I'm using CVS version 1.9 > Two recommendations: First, if possible, update to a later CVS version. Second, CVS comes with pretty good documentation, which can be printed out or viewed with "info", and there is an excellent book, "Open Source Development with CVS" available from CoriolisOpen Press. (The CVS-specific chapters are available at http:[EMAIL PROTECTED] and are covered under the GPL.) If you're going to run a CVS repository, those are going to be very useful resources. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (612)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: Files Created After Installation
"Greg A. Woods" wrote: > > [ On Wednesday, February 16, 2000 at 20:34:21 (-0800), Richard Goh Muk Ling wrote: ] > > Subject: Files Created After Installation > > > > directory), so I was wondering after the installation do I need to > > remove that directory. > > Yes, you may remove the "source" directory -- i.e. the place where you > > However you might want to keep it around anyway in case you need to > apply any patches. If you're low on available disk space in that > partition you can either move it to some other location and/or run "make > clean" to remove all the files that can be regenerated by "make". > If you're going to keep it around, and possibly make patches, I'd strongly suggest putting the CVS source into your repository with "cvs import". That way, it'll be far easier to keep patches you make. After that, you really don't need to keep a separate source code directory (assuming, of course, that you back up your repository properly). If you're not going to make changes yourself, then you don't need to keep it. You can always get a copy of the latest CVS somewhere. I'd keep a gzipped tarball somewhere, myself, though. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (612)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: Questions about CVS
RonPetersen wrote: > > I am trying to find out if CVS can do the following: > > 1. Does it support COBOL/370 and Assembler source code? It supports source code in text formats very well. I wouldn't expect problems. > 2. Are there any limitations to the number of developers that can > be making changes to a program concurrently? No. > 3. Is there a mainframe interface to Panvalet? Not unless somebody wrote one specially for it, and I haven't heard of such. > 4. Is there a mainframe build and compile component? There is no build and compile component. That is explicitly expected to be supplied by the user. > 5. Can CVS do PC syntax checks of all of the different types of > supported source code? No. It supports text, and has no internal idea whether it is storing haikus or COBOL. > 6. Is there an automatic merging of source code when several > developers (working in the same program) migrate their changes to > various stages in the testing life cycle (i.e. unit, system > and customer acceptance testing)? If merging of these program > changes can only be done manually, is there any limitations to the > number of versions which can be merged together? > I'm not completely sure what you mean here. Around here, we do the unit testing in programmer local directories, and when that's finished, put it into the source tree. We developers then pass it on to testing and the project engineers, and fix problems as they find them. New development is done on the head branch, which is generally not shipped; every so often, we cut off what we've got as a branch, and use it as a release. After that, fixes are generally done on the branch, and merged to head. If you require a system to do all of this right out of the box, then CVS isn't going to work for you. Most or all of this can be done with externally written programs (I use Perl), which can either be distributed to developers to use instead of the raw cvs commands, or can be invoked by certain "hooks" in CVS. In that way, CVS can probably be made to do everything you want, provided that you have the necessary external programs (like a syntax checker and something resembling "make") - and, of course, the proper interface to Panvalet (which I haven't used in well over twenty years). CVS is not a commercial mainframe product, and is never going to be. (The license forbids making it into a commercial product, for one thing.) It is Unix-centric open source written in C. Expect a culture clash. :-) -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (612)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: CVS File Locking
"Greg A. Woods" wrote: > > [ On Wednesday, February 16, 2000 at 09:51:44 (-0600), David Thornley wrote: ] > > Subject: Re: CVS File Locking > > > > There are files which cannot be merged. Feel free to curse the > > people who made some of them so recalcitrant, if you like. However, > > I know of no shop where developer work is considered so freely > > disposable as to say "OK, Jack and Jill have conflicting changes to > > the VB program.We're keeping Jill's changes. Sorry, > > Jack, good work, but we'll just have to tell the customer we're not > > going to fulfil that requirement." > > Anyone who has ever spent any time working in a shop where serialised > development is the soup du jour will know that incidents of accidental > "concurrent" development happen all the time (through errors, usually > human in nature) and when merging isn't possible (or isn't thought of), > someone has to re-do their changes using the other's as a new baseline. > Sometimes this happens without anyone but the second developer knowing > that it happened. > Yes, it happens. I've been in that position often enough. That's what CVS was designed to avoid. > Such recreation of changes is a perfectly valid solution. Nothing needs > to be lost of given up. > I suddenly feel like I'm in an alien universe. Certainly you're aware that this is the standard solution in (say) a SCCS or RCS conflict that's not caught in time. If you think this is a perfectly valuable solution, then why do you like CVS? You can do concurrent development with no tools at all, if you don't mind this sort of "merge". I did it for quite a few years. I hated it when it went wrong. > > > CVS was designed only with the copy-edit-merge paradigm in mind. > > > > Your first sentence is at least close to true, although it doesn't > > seem to account for the first "to-do" item at the end of the paper. > > Ah, the first item has already been done, a long long ago in fact. The > resulting feature is called "cvs history". > So you think that "cvs history" is the ideal way of learning "who might be working on the same module that you are"? That seems odd. I don't think "cvs history" is the ideal way of learning anything, the way the output is formatted. And, if you're working to a strict copy-edit-merge paradigm, what do you care about what other developers are doing? The only reason you'd want to know is if you wanted to coordinate changes with them - in other words, if you wanted to add some serialization to the development. > > I'm saying that, to me, the paper reads like "Look at this neat new > > development system we've devised!", and seems to be devoted to showing > > that concurrent development works. > > You're right, it does. However there's also a fairly obvious underlying > agenda. > The obvious agenda is to push copy-edit-merge. It seems that there is no obvious agenda to prevent serialized development, since I and some other people don't seem to find it in the paper. It may have been Berliner's intent, but it is not clearly manifest in the paper. > > After all, we still have trouble > > convincing people that it works, and this is some years later. It > > looks to me like it is advancing a new method to deal with known > > problems with the old, and I don't see anything doctrinaire in it. > > There will always be issues convincing people that concurrent > development works (be it in copy-edit-merge systems, or in two-stage > commit systems, or whatever). It's not intuitive and unless we somehow > manage to wipe out existance of all serialised version control tools > there will always be people who have tunnel vision about them. > Right. We are in complete agreement here. Now, since there is always a fight to push copy-edit-merge, it makes sense that Berliner was pushing for it. He didn't have to advocate serialized development, since there were, and are, enough people who don't believe concurrent works. He had to bring up its flaws, so that he could push for an improved alternative. In other words, he would have written the paper in much the same manner if he had thought serialized development was bad, or if he had thought it was merely unnecessary. There is no way to tell which from the paper itself. It is not evidence for the claim that CVS was designed to force copy-edit-merge. Now, CVS was certainly designed to facilitate copy-edit-merge, and initially had no support for serialization. This is at best negative evidence to show that it was designed to force copy-edit-m
Re: OK, Remove the locks then...
"Win32 M$" wrote: > > Hi All, > > OK, what if we remove the locks completely? Any objections? If I am the only > one who thinks that feature should be under control, I will step out and > give a way to an option of completely removing the locks. I will do it If you mean remove "cvs admin -l", sure. I would be perfectly happy to see that one gone. If you mean to remove "cvs edit" and "cvs watch", I object. That's useful. (Am I the only person here who thinks that (a) CVS should support locks when necessary, and (b) it does already, for all practical - if not all ideological - purposes?) -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (612)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: CVS File Locking
"Greg A. Woods" wrote: > > [ On Tuesday, February 15, 2000 at 14:33:51 (-0600), David Thornley wrote: ] > > Subject: Re: CVS File Locking > > > > So, please tell me where in Berliner's paper it says what you claim > > it says. You can use either the page numbers or the internal > > subdivisions. Alternatively, you could retract your claim. > > Please refer to my previous reply to JMM under this thread. > Yes, and it looks thin. IIRC, it was the second paragraph of the paper proper, the part that mentions the problems with locking, serialized, development. There are problems with serialized development. I think we can all agree on that, particularly if we've used it in the past. I take this as meaning that another, more parallel, method would be desirable, if it works, and the rest of the paper is devoted to showing that CVS works. I think we can all agree that concurrent development is good, when it works (or we wouldn't be here). > Well, OK, that's not exactly what I meant to imply. Indeed CVS works OK > with non-mergable files. The issue is only with how one resolves > conflicts. If it is always OK to make a binary choice between two > changes then yes, CVS works just fine with non-mergable files. > Which is sufficiently close to false to not be worth dealing with. There are files which cannot be merged. Feel free to curse the people who made some of them so recalcitrant, if you like. However, I know of no shop where developer work is considered so freely disposable as to say "OK, Jack and Jill have conflicting changes to the VB program.We're keeping Jill's changes. Sorry, Jack, good work, but we'll just have to tell the customer we're not going to fulfil that requirement." > > > > These have > > > > to have some form of lock. (From experience, I think "cvs watch on/ > > > > cvs edit" is adequate locking, and hard locks would be no better > > > > > > No, they do not. For those very few files for which a merging algorithm > > > cannot be developed "cvs edit" and friends are far *MORE* than > > > sufficient for *ALL* purposes CVS should ever be put to use for. Even > > > they are over-kill in my opinion. > > > > > "cvs edit" and friends are, in my opinion, sufficient. > > Sorry, but I got carried away over-reacting to the opening sentence in > your paragraph. As you can see from my reply I mostly agree with you > (but strongly disagree with those who think serialised development is > the only answer to the problem). > I'm going to take issue with the final "the" in your paragraph. I don't see that there is one single problem. It may well be that all the controlled files at your shop can be merged. Right now, it's true of mine. I don't know how many people here know about "cvs edit" and "cvs watch". I haven't told anybody. However, I'm not willing to say that that will be true forever. Things change, and it's possible that we'll need to put nonmergeable files into the repository in the near future. We need to have a mechanism to manage those in CVS, or we'll have to move off CVS, which would be a great shame. We agree that the concurrent model is better, when it works. > CVS was designed only with the copy-edit-merge paradigm in mind. > Clearly it doesn't force programmers to always make simultaneous changes > to the same files and I certainly didn't mean to imply that it does. > Indeed good project management outside of CVS is often focused on how to > reduce conflicts and the need for merges and there's nothing wrong with > this. > Your first sentence is at least close to true, although it doesn't seem to account for the first "to-do" item at the end of the paper. Nor am I trying to say that CVS should substitute for management, since no revision control system can. I'm saying that, to me, the paper reads like "Look at this neat new development system we've devised!", and seems to be devoted to showing that concurrent development works. After all, we still have trouble convincing people that it works, and this is some years later. It looks to me like it is advancing a new method to deal with known problems with the old, and I don't see anything doctrinaire in it. > All I'm saying is that CVS forces developers to work within the > copy-edit-merge paradigm -- there is no option to use hard locks and > Berliner justified this by showing that there has been not real need for > locks in their experience (and we can now amplify his conclusion though > the ongoing half-dozen years of experience a wide variety of people have > had w
Re: CVS File Locking
"Greg A. Woods" wrote: > > [ On Tuesday, February 15, 2000 at 09:56:42 (-0600), David Thornley wrote: ] > > Subject: Re: CVS File Locking > > > > I don't believe it is designed to do that. It's freely available > > open-source software, and I've never met anybody in the community > > that wanted to force somebody to do development in one specific > > way before. You may want it to do that, but that's a different > > statement. > > The fact that CVS was indeed designed to force concurrent development > been discussed in detail on this list and is clearly evident both in the > original CVS-I scripts and documentation, as well as in Brian Berliner's > paper. You can believe what you will, but those are the facts. > Berliner's paper will be a good source; I have it very conveniently to hand. I just skimmed through it again, and didn't find any such statement. It seems to have been intended to show that concurrent development works. So, please tell me where in Berliner's paper it says what you claim it says. You can use either the page numbers or the internal subdivisions. Alternatively, you could retract your claim. > > Besides, there are things that cannot be developed concurrently, > > since they are unmergeable, for good reasons or bad. > > CVS is not designed to work with un-mergable files. Period. > I found no mention of such files in the Berliner paper, either positive or negative. I will point out that CVS can at least version binary files, which are not mergeable. It may not have been designed to work with them, but it seems to not have been designed not to work with them. > If you want to add more merging support to CVS (i.e. to diff3) for > different types of files then that's an entirely different story than > advocating locks. The former is entirely within the design goals of > CVS but the latter is entirely without. > Additional sorts of merges would be good. It's require additional code, of course, but it'd be worth it. Handling non-mergeable files does not seem to me to be entirely foreign to "a freely available tool to manage software revision and release control in a multi-developer, multi-directory, multi-group environment" (from the abstract of Berliner's paper). > > These have > > to have some form of lock. (From experience, I think "cvs watch on/ > > cvs edit" is adequate locking, and hard locks would be no better > > in practice. Others have different opinions.) I assume it is your > > position that CVS should not be used in such cases. > > No, they do not. For those very few files for which a merging algorithm > cannot be developed "cvs edit" and friends are far *MORE* than > sufficient for *ALL* purposes CVS should ever be put to use for. Even > they are over-kill in my opinion. > "cvs edit" and friends are, in my opinion, sufficient. Some people I think reasonable disagree, for reasons that I do not see the same way they do. They allow CVS to be used in an environment with both mergeable and non-mergeable files. Given the quote from the abstract above, it looks to me like Berliner was talking about a very general solution. Further, "cvs edit" and "cvs watch" are a fairly straightforward implementation of the first item in Berliner's "4. Future Enhancements and Current Bugs", where he complains that it is not possible to know who else is working on a file. > (and before Paul Sander jumps up and down in a flurry again: CVS cannot > be "CVS" if it supports hard locks. Period. This is not something that > can be discussed logically. Either CVS forces the copy-edit-merge > paradigm or it is not CVS.) > Perhaps you could show me where somebody else says that. The Berliner paper seems to me to be about how concurrent development is possible, with some mention in the second paragraph about how locking systems like RCS and SCCS don't scale well. CVS seems to be about permitting copy-edit-merge in a freely available tool. I don't see anywhere where it is about forcing programmers to simultaneously working on the same file. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (612)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: CVS File Locking
Tobias Weingartner wrote: > > On Tuesday, February 15, David Thornley wrote: > > > > Besides, there are things that cannot be developed concurrently, > > since they are unmergeable, for good reasons or bad. These have > > to have some form of lock. > > No, they do not *require* some form of lock. Using some form of > lock is one way of dealing with these files. Simple selection to > resolve the conflict is another. > I have been imprecise. There are files that are non-mergeable for various reasons, that still are changed frequently in the course of development. If two people have changes to make on a file that is not mergeable, then it is probably not acceptable development practice to have them both make changes and have a decision procedure to see whose changes get blown away. Under these circumstances, it is usually a good idea to have one person actually modifying the file, and all others perhaps making notes on the changes they will make. If they go further and modify the file, somebody's work is going right into the bit bucket. The person modifying the file may be referred to as having some sort of lock on it. It doesn't have to be a hard lock. In my experience, writing a "see me" on the listing in the master listing repository works (although very few shops have master listing libraries and racks of punch card decks any more), even in a shop with loose procedures. IMNSHO, this can be achieved with CVS as it currently exists, with "cvs watch on" and "cvs edit". You can speak of an editor as having a lock on a file. It isn't an exclusive lock, and people may want to create such. It doesn't actually prevent commits, and people may want to change that. However, I think this can be considered as "locking". It seems likely, to me, that more and more shops will have a mix of mergeable and non-mergeable files, and that they will become more and more intermixed. This will obviously change. Some types of files will acquire merging algorithms, and some morons will create new file types that gratuitously resist merging, and other people will create file types where it's genuinely difficult to merge them in a meaningful way. If CVS is to continue to be useful, it needs to handle both mergeable and non-mergeable files well. (It wouldn't hurt to allow the use of different merging algorithms by file type, defined somehow, either.) But what it comes down to is that there are cases where concurrent development just doesn't work, and changes simply have to be made serially. Making serial changes in any efficient manner implies, to me, that a maximum of one person or team is changing a file at one time, and that other people and teams will have to wait to make their changes, or find that they have to redo them later. In that case, the person or team making the change can be said to have the lock, in whatever form the lock is. That is why I say these sorts of files require some form of lock. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (612)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: CVS File Locking
"Greg A. Woods" wrote: > > Yup. And the reason is that it would be absolutely against the design > goals of CVS to build a hybrid environment. CVS is designed to *FORCE* > concurrent development. If you don't like it then don't use it (and > don't post stupid arguments about it either). > I don't believe it is designed to do that. It's freely available open-source software, and I've never met anybody in the community that wanted to force somebody to do development in one specific way before. You may want it to do that, but that's a different statement. Besides, there are things that cannot be developed concurrently, since they are unmergeable, for good reasons or bad. These have to have some form of lock. (From experience, I think "cvs watch on/ cvs edit" is adequate locking, and hard locks would be no better in practice. Others have different opinions.) I assume it is your position that CVS should not be used in such cases. If you want to force people to do things your way, please fork off your version into something like FCVS: Fascistly Concurrent Versioning System. Remove "cvs watch" and "cvs edit" and "cvs admin -l", since they're just extra code. Then try and force people to use it, if that's what drives you. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (612)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
