RE: Administrivia -- RE: Per-modules readers/writers ?
::I have just read that Mailman can be used to produce a ::Majordomo type roster of users, by email request (necessary, ::as I do not have shell access to the Mailman host) -- If I can ::get that roster (a couple thousand names), I will issue a ::serialized vacation tracer to each user, and weed some stale ::accounts out. :: How do you get that roster? Regards, Shabbir. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Visual Studio .NET projects and CVS
Dror == info-cvs-admin [EMAIL PROTECTED] writes: Dror Hi,=20 I think I need to clarify myself a little, what am I Dror looking for is not a Visual Studio (.NET) plugin for CVS. Dror My team is working on an Intranet project and using Visual Dror Studio .NET. While we where looking at the source directory Dror in order to decide what goes to the repository and what Dror should be left outside (local files created by the VS) we Dror noticed a large number of files that we could not decide Dror their purpose or the effect of managing them in the Dror repository. I'm looking for someone who has succeeded in Dror managing such project with CVS.=20 Thanks, Dror Hi, In addition to source code and header files, I only manage the .sln and .vcproj files. These, of course, are text files. The solutions and projects build the same way every time. Depending on your apps, the .config files may also need to be managed in cvs. HTH, Rob ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
When are keywords substituted?
Reading from the CVS (info) manual [keyword substitution / using keywords]: To include a keyword string you simply include the relevant text string, such as `$Id$', inside the file, and commit the file. CVS will automatically expand the string *as part of the commit operation*. Is this true? I thought that expansion occured as a part of the *export* (cvs checkout, cvs diff, cvs export, etc) operations. /npat -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
Todd Denniston writes: This is the point where you set down, add up what it will cost your company to support your number of users by putting addons on a ''cheapskates'' version control system to support its use in the companies IP policy setup. Oh, please.. Well, is it the consensus of the maintainers that they will *never* accept any access control feature patches for CVS? Or is it that if someone is willing to back-port and contribute this from the CVSNT side, they will accept it? I.e. is the opposition to ACLs a matter of priorities, or philosophy? If it is philosophy, is it the position of the maintainers that ACLs are so evil that they will actively oppose any attempt by anyone to insert such a feature into CVS, in order to protect innocent users from this heresy? Just asking all these idiotic questions because no one is addressing that point. All I'm seeing are comments along the lines of if your company VPs cannot all take time to sit down and do a top-down reorganization of your IT department to take advantage of CVS as it stands in its purity today, just go away and don't bother us. Oh, heck, never mind - stupid me for offering to investigate this. Let's kill this topic and get back to the regular topics of discussion.. -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
looking for loginfo.pl
I cannot seem to locate loginfo.pl. According to some posts its in the source distribtion, so I downloaded the source to CVS from www.cvshome.org, but didn't see it. Could somebody please send me a loginfo.pl and the line from loginfo that calls it. Thanks a bunch, Brian ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: When are keywords substituted?
Nick Patavalis writes: Is this true? I thought that expansion occured as a part of the *export* (cvs checkout, cvs diff, cvs export, etc) operations. Both are correct. The actual process of expanding keywords happens during checkout, but committing a file containing keywords triggers an automatic re-checkout of the file and thus updates the keywords. -Larry Jones I don't want to be THIS good! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Branching best practices with multiple OS releases
Stefan Monnier [EMAIL PROTECTED] [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Forrest == Forrest Samuels [EMAIL PROTECTED] writes: My company is developing a Java application that we are releasing on several different platforms. We initially released it on Windows and then created a Linux branch to take care of some tweaks that should only be in the Linux release/branch. CVS branches are not very good for this kind of use. You might want to take a look at cvslines (on sourceforge) if you really insist of going that route. Otherwise, I'd recommend you use things like #ifdef directives to take care of the multiple platform versions. In Java? What happened to ``write once, run everywhere?'' ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
Larry Jones wrote: A bit of both, I suspect. That's good to know. In any case, I'll take a closer look at the CVSNT stuff (I wish they hadn't gone and reformatted all their sources so much :-/), and see what's portable back to the main line.. Some basic features (cvs passwd, cvs ls, etc.) should be easy to backport. Others (ACLs, all the NT-specific stuff, etc.) may be a lot more messy, and probably won't be solid enough to pass muster anyway (so this long argument may be moot, for all you know..) -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Upcoming dynamic CVSADM patch - 1 workspace 1 repositories for each file
On Mon, Oct 28, 2002 at 03:43:04PM -0800, Andy Glew wrote: I originally posted this to the newsgroup fa.info-cvs, but it appears to be oneway. Pardon if this is a repost. [It isn't. But only the (sparsely-tagged) HTML was readable in my plain-text mail client; the text version was all run together on one line.] This enhancement allows the CVSADM directory to be specified. In priority order, from lowest to highest: Yes, please! This will help greatly with my current disconnected-repo situation. default CVS environment variable CVSADM --CVSADM command line argument. That last includes .cvsrc support, I hope. WISH? / DESIRABLE FEATURE? It would be nice if cvs ci could be directed to check into all repositories in one command. That's trivially shell-scriptable: for cvsadm in CVS*; do # Note that -d cvsroot-override is not required cvs --CVSADM $cvsadm ci done So why bother including it in CVS proper? (N.B: both the script and the built-in implementation require some naming convention for cvsadm subdirectories, so that doesn't offer any reason to choose one approach over the other.) WISH? / DESIRABLE FEATURE? It might be nice if cvs update could check out from all repositories and automatically merge. After all, the separate repositories are really just a differet physical implementation of branches. If all == 2, perhaps. But again, isn't that also scriptable easily enough? For more than two repo's, I think this would be overwhelmingly confusing -- though no more or less so than an (N2)-way merge between conventional CVS branches. I've often enough found myself with the task of merging N divergent versions of the same stuff (source trees, contact lists, whatever). I've almost(?) always ended up simplifying the problem to a series of two-way merges, by: - picking by visual inspection one version that looks closest to the desired final state, and designating that as good - going through the other versions, one at a time, doing a merge between that and the good one I think that, unless most or all of the merges end up being trivial, this is the only way to keep such a task manageable. Reserved checkouts tetatively updating a version number would not have the make problem. Well, if there were reserved checkouts in the first place :-) For all my objections to the wish list, I think the basic idea could be really useful in some unfortunate situations -- like the one on my current project. Andy, I could really use those patches, if they're in any shape to distribute. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The acronym for the powers that be differs by only one letter from that for the pointy-haired boss. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
[ On Tuesday, October 29, 2002 at 09:10:44 (-0800), Shankar Unni wrote: ] Subject: RE: Per-modules readers/writers ? Well, is it the consensus of the maintainers that they will *never* accept any access control feature patches for CVS? Nobody can arrive at any consensus on this kind of thing without first seeing a complete design and functional specification for the proposed features. You haven't proposed anything concrete enough yet to even dream of whether it should be included in what we call CVS today. I.e. is the opposition to ACLs a matter of priorities, or philosophy? If it is philosophy, is it the position of the maintainers that ACLs are so evil that they will actively oppose any attempt by anyone to insert such a feature into CVS, in order to protect innocent users from this heresy? You still don't seem to understand that it's a fundamental design issue that hinges off the choice to use RCS for the underlying repository You cannot securely implement access controls to internal structural elements in CVS/RCS. It is simply not possible. There's no way to expose those internal structures to the OS in such a way that it can provide the necessary authorisation controls. If you're going to implement security features then you'd damn well better make sure they're for real because if you add some hack that gives a false sense of security and then some other bumbling fool uses it without knowing that it really doesn't provide any true security, then you would be directly responsible (in the moral sense, and perhaps even in the legal sense in some jurisdictions) for any damage done. Philosophically I doubt anyone has any conflict with the _idea_ of having finer-grained access controls for things like branches and tags and commit logs and whatnot. However if you want to design and implement something like that then you're going to have to toss out the whole underlying RCS layer, and if you're going to do that then you may as well just toss out the whole thing and start from scratch (well maybe retain the command-line interface and perhaps the client/server protocol for compatability's sake). Even the suggestion of using a closed host system and perverting all the security into the network server application isn't going to provide any real security if it's based on anything even remotely related to the current CVS code base. Even if you cleaned up the current code base so that it could be better trusted as a security application; and re-engineered some of the internal administrative control features (eg. the way the *info files work) so that they could be trusted; you'd still have to deal with network security issues because now you've made the network and the workstations into the weakest links. That means forcing use of something like SSH or TLS/SSL and providing for ways to manage certificates so that they can be used for authentication. Once you do that then you still have the workstations as the weakest link (which of course they are even with the current use of SSH to access a CVS server). Applications programmers really need to learn to leave security to the OS and learn to deal with whatever limitations that might impose on how they design their systems. As it turns out that's exactly the way CVS was designed in the first place, and how it has been extended to be used in a client/server configuration with RSH/SSH. If you want to use CVS then you have to live with these design decisions. You can hack on some false sense of security if you want but nobody who knows any better is going to want to share that false security with you. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Diffing reformatted code
On Tue, Oct 29, 2002 at 10:28:25AM -0800, Shankar Unni wrote:
In any case, I'll take a closer look at the CVSNT stuff (I wish they
hadn't gone and reformatted all their sources so much :-/), and see
what's portable back to the main line..
GNU wdiff might be useful. It's a diff that's word-based instead
of line-based. It was intended for filled text, and I've only
ever used it for that, but it *might* produce readable diff's of
code. Even if the sections containing differences are
confusingly jumbled in its output, at least it'll show you where
the differences are, so you can skip past sections that are
token-for-token identical.
Hint:
- By default, wdiff marks diffs by inserting [-silly-]
{+special-character+} sequences that I find hard to read.
I've had much better luck by making it use different colours
or font attributes for the removed and inserted text.
See the attached trivial wrapper script, but you'll probably
have to change the specific escape sequences, or better yet,
termcapize it.
Corollaries, when using the wrapper:
- If your terminal is vaguely ANSI-like (as xterms are)
searching for an ASCII ESC character is a good way to
seek to the next difference section.
- less -rG is your friend, even if wdiff's output confuses it
such that the colourization is sometimes messed up near the
top of the screen; scrolling up a line or two, and/or hitting
CTRL-L a couple of times, usually clears it up...
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The acronym for the powers that be differs by only one letter
from that for the pointy-haired boss.
#!/bin/sh
WDIFF=$HOME/dist/bin/wdiff
COLOURS='--start-insert=[;1m --end-insert=[m --start-delete=[;4m --end-delete=[m'
[ x$1 = x-c ] {
COLOURS=
shift
}
exec $WDIFF $COLOURS ${1+$@}
RE: Per-modules readers/writers ?
The consensus of the maintainers has historically been to never add features that they don't personally need, unless somneone supplies code, documentation, and a regression suite. And then it gets integrated at their discretion. There are already at least two major splinter groups using features that have been rejected for whatever reasons: Those using advisory locks as supplied by Noel Yap, and those using mcvs. --- Forwarded mail from [EMAIL PROTECTED] Well, is it the consensus of the maintainers that they will *never* accept any access control feature patches for CVS? Or is it that if someone is willing to back-port and contribute this from the CVSNT side, they will accept it? I.e. is the opposition to ACLs a matter of priorities, or philosophy? If it is philosophy, is it the position of the maintainers that ACLs are so evil that they will actively oppose any attempt by anyone to insert such a feature into CVS, in order to protect innocent users from this heresy? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
[ On Tuesday, October 29, 2002 at 10:28:25 (-0800), Shankar Unni wrote: ] Subject: RE: Per-modules readers/writers ? In any case, I'll take a closer look at the CVSNT stuff (I wish they hadn't gone and reformatted all their sources so much :-/), and see what's portable back to the main line.. Some basic features (cvs passwd, cvs ls, etc.) should be easy to backport. Others (ACLs, all the NT-specific stuff, etc.) may be a lot more messy, and probably won't be solid enough to pass muster anyway (so this long argument may be moot, for all you know..) If you're happy without real security then why don't you just move your repository over to M$-NT and run CVSNT? -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Per-modules readers/writers ?
Todd Denniston writes: This is the point where you set down, add up what it will cost your company to support your number of users by putting addons on a ''cheapskates'' version control system to support its use in the companies IP policy setup. For rational values of company, of course. Just asking all these idiotic questions because no one is addressing that point. All I'm seeing are comments along the lines of if your company VPs cannot all take time to sit down and do a top-down reorganization of your IT department to take advantage of CVS as it stands in its purity today, just go away and don't bother us. FWIW, Open Source/Free software is not generally known for providing features to cater to pointy-haired bosses and their policies, or anything that is seen as PHB-created messes. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
I think this discussion has hit a wall, but I'll answer these points anyway. But I'm no longer pushing for such a feature to be included, because of the obvious reluctance of so many, so we can let this discussion drift away.. Greg Woods wrote: If you're happy without real security then why don't you just move your repository over to M$-NT and run CVSNT? Cost? Utility? Stability? (And besides, is it your contention that Linux filesystem security is real security? All I have to do is break into the machine as root using one of the many unpatched vulnerabilities, and the whole repository is mine..) NT Server costs $$$. Besides, I don't like NT Server very much anyway as a server - a Linux server is far more versatile and solid. In fact, we did start off using CVSNT on an NT box, and after several dozen blue screens and one repository corruption, I gave up on the stupid thing. On the other hand, I can't very well go up to, say, the CIO and tell them that I want the whole company to ditch Microsoft and implement a whole new Grand Unified Authentication and Authorization mechanism across the company. I could, if I wanted to make it my personal full-time evangelism and crusade, but I have to live within real-life constraints. Look, I understand where you come from regarding security, and grafting on security mechanisms on top of each other. On the other hand, what most of us are looking for here are not absolute, drop-dead, guaranteed security, but a mere semblance of an approximation of authorization walls. In most of our environments, we don't have gangs of hostile hackers wandering around looking for things to break into. These are more like little doorlocks that exist merely as an indication to law-abiding employees that the contents are not for them. Certainly there is no intention to make the protection criminal-proof, because that would be enormously difficult. I'm not making my repository public to Joe Random from Little Rock, AK, and I'm not trying to make my repository more secure than my company's overall IT infrastructure. I understand that implementing such a feature may lead someone else to think that that would make CVS secure enough to put it on a public internet with national secrets protected only by this mechanism, but that could be addressed by a warning or something.. For example, pserver isn't really (or even remotely) secure either, and it's there for good or bad, because there's such an *overwhelming* demand and need for it. I know you'd like to rip it out and throw it away, but you'll never hear the end of the screaming if you did so. Still, I hear the reluctance from the faithful, so I'll no longer push for this feature, anyway.. I'll still look to try to back-port non-security-related features where it would be easy and useful.. -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
[ On Tuesday, October 29, 2002 at 13:47:05 (-0800), Shankar Unni wrote: ] Subject: RE: Per-modules readers/writers ? Cost? Utility? Stability? Good questions. What are _your_ answers? (And besides, is it your contention that Linux filesystem security is real security? All I have to do is break into the machine as root using one of the many unpatched vulnerabilities, and the whole repository is mine..) Who said anything about Linux? I certainly didn't. NT Server costs $$$. Besides, I don't like NT Server very much anyway as a server - a Linux server is far more versatile and solid. In fact, we did start off using CVSNT on an NT box, and after several dozen blue screens and one repository corruption, I gave up on the stupid thing. So, which is it? Do you want some level of security, or not? On the other hand, I can't very well go up to, say, the CIO and tell them that I want the whole company to ditch Microsoft and implement a whole new Grand Unified Authentication and Authorization mechanism across the company. I could, if I wanted to make it my personal full-time evangelism and crusade, but I have to live within real-life constraints. You (must) live with the circumstances you create for yourself. Look, I understand where you come from regarding security, and grafting on security mechanisms on top of each other. Well, either you do or you don't. You're still asking to create something that is only an illusion while at the same time not thinking about how you could build your illusion without changing CVS at all. On the other hand, what most of us are looking for here are not absolute, drop-dead, guaranteed security, but a mere semblance of an approximation of authorization walls. Then clearly you do not need or want anything over and above what CVS gives you today with basic unix permissions and ownerships and so on. You already have a mere semblance of an approximation of authorization controls -- and you can implement even more of them too in very simple hooks in the CVSROOT/*info files, with no mods necessary to CVS itself. For example, pserver isn't really (or even remotely) secure either, and it's there for good or bad, Indeed. And for bad only. because there's such an *overwhelming* demand and need for it. I know you'd like to rip it out and throw it away, but you'll never hear the end of the screaming if you did so. You've got that _way_ wrong. 'cvs pserver' was a horrible failed experiment with absolutlely no thought to security or its future bad impact on CVS. It's a stupid hack that really isn't necessary now and never really was. It was only created because the better alternative was (mistakenly) considered to be too difficult. It's only still in CVS because nobody bothered to take it out in time. Even for anonymous read-only access pserver's time has come and gone long long ago. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
perl script to tag message text
hi all, i was wondering if anyone had a simple script where you could say: script.pl modulename message.* TEMP_TAG (or similar) and it would tag each file with that message -- throwing an error if it didn't. I know this sounds kinda specific but hopefully someone has already needed it. I want to use it to do code reviews on checked in code between versions, but fishing through the cvs log output for individual files is a major drag. I could just find the two commit messages in the cvs2cl output, tag them, rdiff them, then delete the tags. anyway, if noone's done it, i'll have a shot and post it up here. cheers, matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS checkout, excluding some files??
Hi Is there anyway to checkout the repository such that I can exclude some files?These files are needed for an older release but in the current version they are not needed.I know we can make a branch, but is there any other method to exclude just some files from checkout?They are in different directories. Thanks, Jeeva Sarma __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
