Re: "cvs [commit aborted]: cannot commit files as 'root'"
[ On Monday, July 9, 2001 at 01:03:36 (-0400), Lenny Foner wrote: ] > Subject: "cvs [commit aborted]: cannot commit files as 'root'" > > And with that, I'm outta here. I'd be happy to suggest ways to > implement this idea, and to discuss the engineering trade-offs made > in implementing it. I'd even be happy to spend some effort on some > patches, although I'm not necessarily volunteering to do -all- of the > work. However, I will -not- respond to yet another scream from Greg > saying, "You must not do that!" Life is too short. If no one else > thinks that this is an idea worth pursuing, or if everyone else is so > cowed by the thought of having Greg yell at them for days that they're > unwilling to start, or if I'm told that no such patch will be accepted > to CVS, then it will die here. I won't be the one screaming about the problems you introduce by arbitrarily changing output of CVS. The authors of all the front ends that try to parse its output will do the complaining. Been there, done that. CVS is now a widely used legacy program that's integrated with in some very strange and wonderful other tools. You have to do a lot of analysis and verification of a lot of other tools, and present concrete plans and propsals for public examination, before you go barging in and changing the way it behaves, even if all you're doing is changing some error message text. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: "cvs [commit aborted]: cannot commit files as 'root'"
[ On Monday, July 9, 2001 at 01:03:36 (-0400), Lenny Foner wrote: ] > Subject: "cvs [commit aborted]: cannot commit files as 'root'" > > In that time, you've come across as basically a reactionary force, > in the original meaning of that term---in other words, just about any > change to CVS has launched you on a crusade to preserve the One True > Original Implementation, even in the face of lots of people who might > rather it behaved otherwise. You're obviously not paying attention to what I'm writing. Please try again. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Per-directory sticky tags - a possible bug?
Hi,
I'm using CVS version 1.10.7 on Windows (not using the client/server model).
I have a CVS project that is made of some directory tree, where the topmost
directory does not contain any files:
root
subdir1
subdir2
...
The root directory of the project ("root") does not contain any files; all
files are located in the sub-directories of "root".
When I use "cvs update -r tag-name" in the working directory of "root", CVS
updates the project to the version indicated by "tag-name". In the CVS
sub-directory of each working directory, it creates the "Tag" file which
indicates the sticky tag.
When "tag-name" is not a branch tag (i.e., it is not the name of a branch),
the "CVS/Tag" files in the sub-directories of "root" contain the right
thing: "Ntag-name". However, the "CVS/Tag" file in the working directory of
"root", contains: "Ttag-name", as if this is a branch tag. This means that I
can (I tried, and it works) add files, modify them and commit them in the
working directory of "root", while I cannot do so for the sub-directories.
Is this a bug in CVS? If not, can you explain to me the idea behind this?
One more thing that is somehow related to the above: My group always treats
a whole CVS project as a single entity - tags are always applied to whole
projects and not to specific files/directories of a project. Given that, is
there a way for me to know whether my working copy of a project is set to a
branch or not? (not just to a branch tag, but to a tag that belongs to a
branch) (Let's say I forgot if I checked-out from a branch or not)
Thanks a lot,
Shlomo
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
"cvs [commit aborted]: cannot commit files as 'root'"
Greg. Greg, Greg, Greg. I've been watching your traffic on info-cvs since about August 1996. That's over 100 meg of traffic. Of course, not all of it is yours. In that time, you've come across as basically a reactionary force, in the original meaning of that term---in other words, just about any change to CVS has launched you on a crusade to preserve the One True Original Implementation, even in the face of lots of people who might rather it behaved otherwise. You've generally shouted down many attempts to change CVS via bluster, zillions of increasingly-inflammatory messages (in which the count of exclamation marks increases exponentially over time), and apparently having more time than anyone else who cares to shout ever more loudly about what -you- want CVS to be. People who don't have time to spend arguing with you simply leave. This is a common occurrence in all sorta of fora. Various experiments in self-governance in MUDs, for example, have failed by being taken over by people who have no lives. Such people spend more time shouting than people with better things to do, and win by driving everyone reasonable away. This effect has been documented by numerous academic papers which look at the sociology and anthropology of online environments. On this list, -you- seem to have that role. I'm going to respond -just once- to your latest scream, and then I'm going to abandon this thread no matter what you say. I don't have the time. If someone informs me that patches to make CVS easier to use would be accepted, I may well write some. Other people might, too. (Obviously, I'd be more than happy to participate in a discussion of how such a patch should be designed.) Of course, the more likely outcome is that any patches intended to make life easier for the users, no matter how rational, will simply be shouted down by you. Thus, there -aren't- any such patches, because nobody wants to waste their time writing them when you'll try to shout them off the stage. This is the sort of behavior that leads to forking the code in order to make progress. Perhaps this should have happened years ago. Of course, maybe the most productive approach would be to create the Greg fork, and the fork everyone else uses; that avoids having two large but splintered groups of users, as seems to have happened with the *BSD forks of various things already. I should note that I am -not- the first to suggest a Greg fork; this alone might give one pause. Given your repeated screams of "RTFM!", I must conclude that you hate CVS' users and wish to punish them. (It's especially ironic in this case, since you've said yourself that this particular error message never got documented in the M to begin with.) I don't share that viewpoint. And, given the message traffic on this list, I'm willing to believe that the people who write here asking questions don't share that viewpoint, either. And I'll bet that those few selfless individuals who seem to spend a great deal of time answering their questions don't share that viewpoint, either, and would rather that users could be made more independent. What's wrong with empowering the users? Now, let me address your particular points. As I see it, they are all strawmen, but you need to have them in order to bluster more effectively: o You've said quite clearly that making things easier for users is inherently bad, e.g., that they must not be enlightened through the actual error messages, but merely given -just- enough information to be able to find out something about the error in the manual. This seems an extremely curious attitude; I wonder if it is widely shared. o You've spent lots of bluster talking about time and resources, but have failed to actually mention what resources those are. I contend that those resources break down into an insignificant amount of memory and load-time (and you did not refute those), some amount of CVS developer time, and some amount of time to make sure that front-ends can parse the results. It is my contention that the developer-time required to dramatically improve the situation (see below) is insignificant when compared to the users' time, and the time of those who read this list, that is wasted by not doing so. o You claim that front-ends cannot handle more-useful documentation, but that's clearly a strawman argument. As I demonstrated, it wouldn't be hard to embed some unique identifier into -every- message that CVS emits, and front ends can trivially look for it. o You claim that I must clearly be inexperienced, both as a programmer and in CVS internals, to have made the assertions I did. Having been a programmer since 1973 and the days of the PDP-8, I can assure you that I'm not. I've done work in speech recognition. I've helped build Ada compilers. I was a systems programmer for many years on Lisp Machines. I've done more communications-related programming than I can remember. I've built commercial expert systems in a var
Re: The hated $Log$ keyword
On Sun, Jul 08, 2001 at 10:39:52PM -0400, Greg A. Woods wrote: > The "evil" thing abou RCS keyword design is that they contain their > values when stored in the ,v file, Mmm, yes. If it stripped out the values at commit time, and just stored the keywords, all these *#(! merge conflicts would go away. > and that they contain their markers > when they appear in a "frozen" file. Why is this a problem? I very much prefer it. Suppose, using SCCS or raw RCS, I accidentally edit a file I haven't locked. With RCS, once I've seen the "permission denied" message, I can: :!co -l foo :w! The SCCS equivalent would inappropriately freeze all my keywords. OK, that's a really dumb thing to do when collaborating with others. But then, I've rarely collaborated using raw RCS, and never with SCCS; by the time I had coworkers who were willing to consider version control at all, I'd discovered CVS :-) > This was one of the several things that hindsight shows us SCCS did > right in the first place, especially when you're using it as an > underlying tool for delta management in something like CVS. I don't see how one could even do CVS-style unreserved checkouts layered on top of something which handled its keywords the way SCCS does. Should a checkout give you the values (in which case, the magic-keyword-ness is lost on commit), or the keywords (in which case, why bother with keywords in the first place since they never get substituted)? I'm trying to think of how one could get this to work. You'd have to do some kludge like: - check out with values only into the user's sandbox (actually, SCCS itself gives you no choice, if I recall, since the only way to get keywords only is "get -e", which also acquires a lock) - at commit time, do a merge between: 1. a fresh checkout with values only 2. another fresh checkout with keywords only 3. the sandbox file i.e. diff (1) and (2) and apply the results to (3) as a patch Shudder! Every commit becomes a merge; it happens at commit time, not update time, so the user can't inspect the results; a conflict is guaranteed if the user so much as touches the keyword-values or their immediate vicinity; two revision checkouts per commit. Have I listed all the problems yet? Likely not... > > > - why do you put $Header$ in the "totally evil" class, not > > merely evil? > > $Header contains information that has no business ever being seen in the > file content, especially in CVS, though even in plain RCS use it is > bogus. If you move your repo all that info becomes wrong even though > nothing else has to break. Point taken. > Well over a decade ago I argued for [...] > a way to expand just the relative path-prefix within > the repository Now that you mention it, I seem to recall wishing for the same thing (not quite a decade ago), but never got around to griping about it. Maybe I should have :-) -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The hated $Log$ keyword
[ On Sunday, July 8, 2001 at 20:13:40 (-0400), Eric Siegerman wrote: ] > Subject: Re: The hated $Log$ keyword > > I thoroughly agree about $Log$, but: > - what's evil about the rest? The "evil" thing abou RCS keyword design is that they contain their values when stored in the ,v file, and that they contain their markers when they appear in a "frozen" file. This was one of the several things that hindsight shows us SCCS did right in the first place, especially when you're using it as an underlying tool for delta management in something like CVS. > - why do you put $Header$ in the "totally evil" class, not > merely evil? $Header contains information that has no business ever being seen in the file content, especially in CVS, though even in plain RCS use it is bogus. If you move your repo all that info becomes wrong even though nothing else has to break. Well over a decade ago I argued for something half-way between $Id and $Header in RCS, and I repeated that plea when CVS-II first appeared. What I wanted was a way to expand just the relative path-prefix within the repository. It would have been doable in RCS without much problem, and with CVS it's actually trivial (though I think CVS still contains an implementation bug that would make it harder than it should be, and of course CVS modules attempt to be way more than anyone ever needs, further complicating the issue). As it is I usually end up hard-coding the module name and relative path within the module into my ident strings. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: "cvs [commit aborted]: cannot commit files as 'root'"
[ On Sunday, July 8, 2001 at 19:27:07 (-0400), Lenny Foner wrote: ] > Subject: "cvs [commit aborted]: cannot commit files as 'root'" > > No, it only says that you can't. It doesn't explain WHY, which was > precisely the question that was asked. Well of course not! RTFM! > Nor, apparently, does it help > anyone who ever gets it---they say, "Yeah, so, I'm root. What's the > big deal?" And then (a) they waste their time asking the list, and > (b) they waste all -our- time reading their question, and (c) they > waste a few peoples' time who answer them. Seems suboptimal to me... You'll never eliminate "RTFM" answerable questions, not even if you put the whole stinking manual right into the code so every message is as verbose as humanly possible. > Maybe if it said "You, whomever you are, cannot commit files as 'root'!" > (complete with the explanation mark :-) > > That doesn't help the users, whose immediate next question is, "why not?" The immediate response of any sane person who asks such a question should be to RTFM! > That's not a real suggestion though -- CVS error messages should remain > as stable as possible so as to facilitate ease of maintenance of wrapper > and front-end programs. > > You're kidding, right? Nope, not at all. Not one iota. That's a very very serious concern. I dare you to write a front-end to CVS (as it is today) and say otherwise! > You're actually arguing that error messages must remain fixed for all > time because someone might have based a wrapper on them? No, I'm not saying that either -- I'm saying they must not change without due cause. > Whatever > happened to the concept of exit codes? What about them? They serve an entirely separate purpose. > Whatever happened to the > concept of the localization of all text emitted by a program for the > user's native language? What indeed! Do you have patches to implement this feature in CVS? > Whatever happened to any pretense of design, > not to mention professionalism? You should learn some more about the history of CVS and its development. I'm sure such knowledge will enlighten you significantly! ;-) > If that's -really- the concern, then I submit that a much more stable > mechanism would be to number all the error messages uniquely, and emit > that number (perhaps surrounded by some sequence of characters not > ever used elsewhere in error messages---though be careful of > filenames! This is a viable scheme, but it would take quite some doing to make CVS (as we know it today) implement it. UNIX System V took a similar approach, though I don't know exactly how far they got. > Sounds like sanity.sh should be amended to do a grep for every error > message through the manual and at least make sure that it appears > -somewhere-. Hmm I think it would be easier to analyse the code and create REs from the printf format strings At least then you know where the variable bits of the messages are, and even what type of data to expect in those places Such a tool would have much wider application than just CVS, of course! > Why? What a waste of space, energy, resources, time, effort, etc.! > > Because one implementor's effort saves n thousand people's time, > that's why. I think you vastly under-estimate the needs of the maintainer. This is no small problem we're talking about here! I would submit that it simply cannot ever succeed without at least partial automation, and of course such a drastic change would require a very significant amount of up-front work, even if one did draw upon existing practice (eg. have a look at the code in Postfix). I know of what I speak -- I've been around this block more than once myself! > Why force the user through an extra step? He's already staring at the > message. Why not help him to understand what he's looking at? Why force an expert user (not to mention a front-end driver program) through all the extra verbiage? Why not help the user learn to become an expert user? > I really rather dislike execessive verbosity in error messages. > > Is telling the user what he did wrong, and why, "excessive"? Yes, absolutely. A simple error number is insufficient except for the most expert user (or front-end program). An error message must give just enough information to provide context and memory/search clues, and absolutely no more. We're not talking about some kind of fancy GUI-driven DWIM application here! If you want all that extra crud all the time then please put it only int he fancy GUI DWIM thing, not in the underlying _tool_. > You > sound like you're saying that all CVS error messages should simply be > "?", like a certain well-known text editor from the early 70's, when > memory was many cents/bit. Or perhaps they should just be "abend 34117"; > after all, that's what the manual is for, right? There was a significant UI advantage to that scheme, but of course it can only be taken so far! ;-) > Inscrutib
Re: The hated $Log$ keyword
On , July 7, 2001 at 18:22:09 (+0100), James Youngman wrote: > Subject: Re: The hated $Log$ keyword > > What if there was a keyword like $Log$ but which expanded to the > entire log history (with comment leaders)? This would avoid the > merge problem and surely cannot be too expensive to compute. It would indeed avoid the merge problem (or at least reduce it) ... but it's *impossible* to compute in the presence of branches. CVS doesn't keep around enough info to know which revisions of which branches actually contributed to the rev in question. (That's a problem that wants solving for other reasons, of course, as has been discussed in the past.) On Sat, Jul 07, 2001 at 05:49:30PM -0400, Greg A. Woods wrote: > RCS keywords are evilly implemented at best, and $Header, $Log, and a > few similar are just totally evil from the get go. Avoid them like the > plague. I thoroughly agree about $Log$, but: - what's evil about the rest? - why do you put $Header$ in the "totally evil" class, not merely evil? -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
"cvs [commit aborted]: cannot commit files as 'root'"
Date: Sun, 8 Jul 2001 18:28:50 -0400 (EDT) From: [EMAIL PROTECTED] (Greg A. Woods) [ On Sunday, July 8, 2001 at 16:00:55 (-0400), Lenny Foner wrote: ] > Subject: "cvs [commit aborted]: cannot commit files as 'root'" > > You know, given how often people ask this question, maybe some > paragraph of your response here should be put INTO THE ERROR > MESSAGE ITSELF. Well actually I would have thought the message was already very very clear all by itself -- if maybe a bit terse for anyone with English as a second language. It does, after all, say exactly what it means. No, it only says that you can't. It doesn't explain WHY, which was precisely the question that was asked. Nor, apparently, does it help anyone who ever gets it---they say, "Yeah, so, I'm root. What's the big deal?" And then (a) they waste their time asking the list, and (b) they waste all -our- time reading their question, and (c) they waste a few peoples' time who answer them. Seems suboptimal to me... Maybe if it said "You, whomever you are, cannot commit files as 'root'!" (complete with the explanation mark :-) That doesn't help the users, whose immediate next question is, "why not?" That's not a real suggestion though -- CVS error messages should remain as stable as possible so as to facilitate ease of maintenance of wrapper and front-end programs. You're kidding, right? You're actually arguing that error messages must remain fixed for all time because someone might have based a wrapper on them? Whatever happened to the concept of exit codes? Whatever happened to the concept of the localization of all text emitted by a program for the user's native language? Whatever happened to any pretense of design, not to mention professionalism? If that's -really- the concern, then I submit that a much more stable mechanism would be to number all the error messages uniquely, and emit that number (perhaps surrounded by some sequence of characters not ever used elsewhere in error messages---though be careful of filenames! probably it needs to be ina known location, like the start) along with the error text. And, of course, the easiest way to do that would be to put all the error messages in a big enumeration, which guarantees no duplicated numbers (because it's the compiler assigning the numbers), and makes internationalization simply a matter of translating the messages that appear in that table---which is probably in a single file. This isn't rocket science---it's how any number of programs are actually written. Obviously, you have to make sure that nobody ever inserts a new message in the middle and upsets the numbers, but hey, that's easy enough to enforce---in sanity.sh if necessary. (Or, you move away from numbers entirely, and use unique strings---checked by whatever routine builds the table to -guarantee- that they are, in fact, unique---hence avoiding any ordering at all. This is how VAX/VMS did it, so typical error messages that looked like "DCL-F-NOFILE, no such file FOOBAR" and you know what emitted the message [DCL], how bad it was [fatal], and had a unique string if you really wanted to search for it in a logfile [NOFILE].) Hence, a typical CVS error message might instead look like: ##CVS-Error 23##: cvs [commit aborted]: cannot commit files as 'root' Since root is usually a shared account, CVS won't allow you to commit as root unless it can figure out who you really are. Logging in as yourself and then su'ing to root will usually allow CVS to figure out who you are, but logging in as root won't. If you're sure you want to be able to commit as root, see CVS_BADROOT in src/options.h. For more information, see section 23.4.5 of the manual, or http://foo/bar.html. Wrappers can search for the "##CVS-Error 23##". Users can ignore that part, though they can use it in bug reports as a shorthand. But users -do- get something that actually explains what they did wrong, exactly where and when they need it, and without forcing a shift of attention. Those attention shifts are very costly in terms of productivity. I think what maybe surprises people about this is that usually 'root' can do anything and usually error messages say "you must be root to" Obviously though a source code control system has different security requirements than a filesystem. In this particular case, you may (or may not) be correct about what it is that "surprises people". I'm making a more-general argument than just this particular error message, of course. > Yeah, I know, I know, everyone will say "that's why you're supposed > to read the manual!", but it's obvious that either (a) people aren't > reading it well enough, or (b) it's a little too buried. It isn't even in the manual, as far as I can see. That's maybe the worst failing of the manual -- there's no (even partial) list of the error messages in one place with lin
Re: "cvs [commit aborted]: cannot commit files as 'root'"
[ On Sunday, July 8, 2001 at 16:00:55 (-0400), Lenny Foner wrote: ] > Subject: "cvs [commit aborted]: cannot commit files as 'root'" > > You know, given how often people ask this question, maybe some > paragraph of your response here should be put INTO THE ERROR > MESSAGE ITSELF. Well actually I would have thought the message was already very very clear all by itself -- if maybe a bit terse for anyone with English as a second language. It does, after all, say exactly what it means. Maybe if it said "You, whomever you are, cannot commit files as 'root'!" (complete with the explanation mark :-) That's not a real suggestion though -- CVS error messages should remain as stable as possible so as to facilitate ease of maintenance of wrapper and front-end programs. I think what maybe surprises people about this is that usually 'root' can do anything and usually error messages say "you must be root to" Obviously though a source code control system has different security requirements than a filesystem. > Yeah, I know, I know, everyone will say "that's why you're supposed > to read the manual!", but it's obvious that either (a) people aren't > reading it well enough, or (b) it's a little too buried. It isn't even in the manual, as far as I can see. That's maybe the worst failing of the manual -- there's no (even partial) list of the error messages in one place with links to nodes containing their explanations. > My basic point here is that, industry-wide, far too many error > messages are far too terse. They should include paragraphs of prose, > pointers to manual sections, URLs for further clarification---and > probably all -three- of them. Why not? Why? What a waste of space, energy, resources, time, effort, etc.! All that's really necessary is that the documentation contain descriptions of the error messages. With 'info' documentation the searching for the meaning is extremely simple. I really rather dislike execessive verbosity in error messages. Specifically for CVS though error messages should be kept as stable as possible and short enough that when fully formatted with an average filename they don't exceed 80 characters in length. > After all, we're no longer > using 300 baud teletypes where a long error message takes a minute to > sit through. Nor does it matter if the executable is 10K larger > because the error messages actually tell you what's wrong---not in an > era of 1G OS's and 10M applications... Size and speed aren't everything (though they're certainly still very very important -- far more important than you seem to think!). Maintenance is also incredibly important. I think it's far better to have very good documentation and to keep it up-to-date with lists and descriptions of error messages rather than to have to maintain the same text in both the code and the documentation (or come up with some convoluted scheme to try to merge one from the other). -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Didn't you say you wanted to RUIN SOMEONE?
Title: SPY HEADQUARTERS EMAIL You are receiving this email because you have requested information regarding Investigative Research Products. If you want to unsubscribe from this list, please reply to this with the word "UNSUBSCRIBE" in the body of the e-mail. Hello to all My Friends from: Law Enforcement Agencies Private Investigations, Government Officials, Foreign Diplomats, Criminal Law Offices SPY Headquarters, a business subsidiary of MLH Marketing is a state-of-the-art Security Products company. We are the home of the "Ruin Anyone - Find Anyone" Cyber-SNOOPER Software. We have sold over 10,000 copies to date. This is our 2nd year in business servicing our wholesale and retail clients. We are celebrating our a new year of offering Security Products on the Internet. We keep our on-line product information and prices up-to-date, and have expanded our product line to include a library of specialty books. We will consistently add new product in the up coming weeks. Please take a look at the great investigative products currently available at our website. Fabulous July's Specials: Novelty Products: SPY EAR: Here is the latest high-tech gadget that will allow you to listen to conversations from a great distance without suspect knowledge. With this sound amplifier, you can now hear things crystal clear that you could never not before. Spy ear is very easy to use, just put the ear buds in your ears - aim the Spy Ear towards what you want to hear and listen-in. Spy Ear has adjustable volume control. You can listen to conversations across a room, and gather all the gossip!! And you will not pay any shipping and handling! Priced to sell @ $9.99 each Click here for additional information Investigative Software: Cyber-SNOOPER Investigative Software: "RUIN ANYONE - FIND ANYONE" This amazing software provides you with a complete "how to" guide, a large selection of tools and even databases that will aid you in just about any type of informational investigation. Not only does the kit provide you with the sources and tools that are useful in gathering information on others but it will also provide you with an organized guide to what each source can provide and where it's located. And you will not pay any shipping and handling as usual! Priced to sell @ $9.99 each Click here for additional information Come and visit this website for great bargains to investigate anyone! ©2001, MLH Marketing. The "Spy Headquarters" Leader on the Internet All rights reserved and strictly enforced.
Re: "cvs [commit aborted]: cannot commit files as 'root'"
Matthew Von-Maszewski writes: > > su to root worked like a champ. Thanks for the work-around. Perhaps I understated things a bit in my original response. There *are* security concerns with committing as root -- be very sure you know what you're doing. Even better, just don't do it. -Larry Jones The surgeon general should issue a warning about playing with girls. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: "cvs [commit aborted]: cannot commit files as 'root'"
su to root worked like a champ. Thanks for the work-around. Matthew -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Sunday, July 08, 2001 3:27 PM To: Matthew Von-Maszewski Cc: [EMAIL PROTECTED] Subject: Re: "cvs [commit aborted]: cannot commit files as 'root'" Matthew Von-Maszewski writes: > > cvs [commit aborted]: cannot commit files as 'root' [...] > Is this an intended security feature ... or am I just being stupid again? It's an intended feature, but it has more to do with maintaining accountability than security. Since root is usually a shared account, CVS won't allow you to commit as root unless it can figure out who you really are. Logging in as yourself and then su'ing to root will usually allow CVS to figure out who you are, logging in as root won't. If you're sure you want to be able to commit as root, see CVS_BADROOT in src/options.h. -Larry Jones Mr. Subtlety drives home another point. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
"cvs [commit aborted]: cannot commit files as 'root'"
Date: Sun, 8 Jul 2001 15:26:59 -0400 (EDT) From: [EMAIL PROTECTED] (Larry Jones) Matthew Von-Maszewski writes: > > cvs [commit aborted]: cannot commit files as 'root' [...] > Is this an intended security feature ... or am I just being stupid again? It's an intended feature, but it has more to do with maintaining accountability than security. Since root is usually a shared account, CVS won't allow you to commit as root unless it can figure out who you really are. Logging in as yourself and then su'ing to root will usually allow CVS to figure out who you are, logging in as root won't. If you're sure you want to be able to commit as root, see CVS_BADROOT in src/options.h. You know, given how often people ask this question, maybe some paragraph of your response here should be put INTO THE ERROR MESSAGE ITSELF. Yeah, I know, I know, everyone will say "that's why you're supposed to read the manual!", but it's obvious that either (a) people aren't reading it well enough, or (b) it's a little too buried. So why not actually spell the entire thing out in the message? It's not like brevity is required in these things. I'd say you should just take everything after the first sentence above (e.g., starting at "Since root is usually...") and just add it to the error message. If that were done, some large percentage of FAQs would stop being asked. If that were done to many of the other common screwups, many more people could also be instantly enlightened, instead of asking the list. It speeds them up (they don't have to (a) try to find the message in th emanual, or (b) compose a message, send it, and wait for a reply), and it might even make life easier for people who are using CVS whose native language isn't English and who aren't using some localized copy---after all, the more explanation there is, the more likely that some subportion of it will be intelligible enough that the user will understand it. [My favorite example of this---and it's even for a native English speaker!---is the compiler error message saying "FOO is multiply defined", which invariably causes some subset of those reading it to say, "What in the world does multiplication have to do with what I"m doing?" It -should- say, "FOO is defined more than once" or "FOO is defined multiple times"---just a teeny bit of additional prose can do wonders.] My basic point here is that, industry-wide, far too many error messages are far too terse. They should include paragraphs of prose, pointers to manual sections, URLs for further clarification---and probably all -three- of them. Why not? After all, we're no longer using 300 baud teletypes where a long error message takes a minute to sit through. Nor does it matter if the executable is 10K larger because the error messages actually tell you what's wrong---not in an era of 1G OS's and 10M applications... Thanks for listening... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: "cvs [commit aborted]: cannot commit files as 'root'"
Matthew Von-Maszewski writes: > > cvs [commit aborted]: cannot commit files as 'root' [...] > Is this an intended security feature ... or am I just being stupid again? It's an intended feature, but it has more to do with maintaining accountability than security. Since root is usually a shared account, CVS won't allow you to commit as root unless it can figure out who you really are. Logging in as yourself and then su'ing to root will usually allow CVS to figure out who you are, logging in as root won't. If you're sure you want to be able to commit as root, see CVS_BADROOT in src/options.h. -Larry Jones Mr. Subtlety drives home another point. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: "cvs [commit aborted]: cannot commit files as 'root'"
[ On Sunday, July 8, 2001 at 11:16:40 (-0400), Matthew Von-Maszewski wrote: ] > Subject: "cvs [commit aborted]: cannot commit files as 'root'" > > Is this an intended security feature ... or am I just being stupid again? VERY intended! -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
"cvs [commit aborted]: cannot commit files as 'root'"
Anyone? I get the following message attempting to make a commit locally on the CVS server: cvs [commit aborted]: cannot commit files as 'root' $CVSROOT is properly set. All is fine if I switch to another user. File permissions in the repository look good too. Is this an intended security feature ... or am I just being stupid again? == Matthew Von-Maszewski [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merging different types of files
[EMAIL PROTECTED] wrote: >Hi, > >I don't see how the cvswrappers file can help me, because for the *same* >files I would like to see a different behavior, depending on the command. >When I check-out/check-in source files, I would like the keyword >substitutions to take place, e.g., I would like $Revision$ to be expanded to >the version of the file. >When I merge source files (in branches), I would like to avoid the keyword >substitutions so that I don't get "false conflicts" about the keywords. > >Is there a solution for this? Is there a simple utility that eliminates the >"false conflicts" generated by the keyword substitution? > >I read that I can determine a filter to work on each file based on its name >when the file is checked-out or checked-in, however, the manual also says >that these options are not available when you work in a client/server model. >(We currently don't use client/server, but we'll do so soon.) > >Thanks, >Shlomo > >-Original Message- >From: John Minnihan [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, July 04, 2001 8:57 PM >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Subject: Re: Merging different types of files > > >Define the file handling in cvswrappers, such that the expansion mode is >appropriately applied on a per file basis rather than wholesale via a >command >line switch. > >This technique is discussed in many places (probably this list archive for >starters). > >[EMAIL PROTECTED] wrote: > >>and in general we're interested in the keyword substitution feature for >> >the > >>text files. However, the binary files are stored in the repository with >> >the > >>"-kb" option, to prevent the keyword substitution and the line-ending >>conversions from taking place. >> >>What is the right way to merge such a project? >> > >- >John Minnihan >mailto:[EMAIL PROTECTED] >http://www.freepository.com > > > > > RE: > > Content-Type: > > text/plain > Content-Encoding: > > quoted-printable > > A... now I understand your original question. I wrestled with this one some time back, and ultimately just turned off keywords. You can get the log info using other techniques. It doesn't have to be embedded in the file. _ John Minnihan mailto:[EMAIL PROTECTED] http://www.freepository.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Merging different types of files
Hi, I don't see how the cvswrappers file can help me, because for the *same* files I would like to see a different behavior, depending on the command. When I check-out/check-in source files, I would like the keyword substitutions to take place, e.g., I would like $Revision$ to be expanded to the version of the file. When I merge source files (in branches), I would like to avoid the keyword substitutions so that I don't get "false conflicts" about the keywords. Is there a solution for this? Is there a simple utility that eliminates the "false conflicts" generated by the keyword substitution? I read that I can determine a filter to work on each file based on its name when the file is checked-out or checked-in, however, the manual also says that these options are not available when you work in a client/server model. (We currently don't use client/server, but we'll do so soon.) Thanks, Shlomo -Original Message- From: John Minnihan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 04, 2001 8:57 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Merging different types of files Define the file handling in cvswrappers, such that the expansion mode is appropriately applied on a per file basis rather than wholesale via a command line switch. This technique is discussed in many places (probably this list archive for starters). [EMAIL PROTECTED] wrote: > and in general we're interested in the keyword substitution feature for the > text files. However, the binary files are stored in the repository with the > "-kb" option, to prevent the keyword substitution and the line-ending > conversions from taking place. > > What is the right way to merge such a project? - John Minnihan mailto:[EMAIL PROTECTED] http://www.freepository.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
