Re: CVS newbie - I want to make a new CVS installation secure...
Flossie wrote: snip... 2) I'm suprised how much CVS docs emphasise the fact that multiple users can check out the same file and CVS can resolve conflicts as checkins occur. However there are problems with letting users resolve conflicts (they can get it wrong), and I doubt a system can be 100% foolproof at deciding that an auto-merge is safe (in which case CVS can get it wrong), although the chances of error are very small. There are other reasons, but basically, can I disable multiple checkouts? 3) Can I stop the general users from performing things like code branching? Stop them from removing files? Are there any other tips on tightening up CVS security? Not security in the sense of SSH, etc, but once a user is 'in', limiting what they can do? Good grief! Might as well continue: Can we stop them from checking out files? Can we stop them from checking in files? Can we stop them from editing files? Can we stop them from getting any work done at all? :) Really, what on earth would you want to use CVS for? 1. You don't want to use concurent editing because you're concerned that merges might fail. We used to have some developers at our site that were concerned about this. A little education and all was better (I've never ever once seen or heard of any evidence of CVS screwing up a merge, every screwup I've ever seen was user error). BTW, the C in CVS stands for Concurent. This is the whole point of CVS over lock-based versioning systems. Don't want the C then use RCS, and the telephone: Hey Bob, I need to tweek one line in the file you've got checked out, can you check it in so I can actually get some work done? 2. You have hired developers for their skills, you're paying them money, and you trust them with your code base, but you don't trust them to take care of code conflicts? Or managing source files? Come on... If you don't trust them, why allow them to work on your code at all? I'd get people that I felt were competent and I trusted in the first place. 3. Multiple checkouts... I hope you're not trying to disable one developer from checking out multiple files at once. If you do, it will be near impossible for anyone to get any work done at all. 4. Branching is probably the most importaint feature of CVS (after merging of course). Disabling this would cause every change, even temporary experimental changes, to have to be checked into the mainline stable codebase. Which means that you don't any longer get version control for your experiments, or you make your stable codebase very unstable. Examine your workflows carefully. You'll find that one of the following is true: 1. A set of files in a commonly accessable directory is all you really want. Result: you don't need CVS. 2. Your expectations of either your workflow or your users is wrong. You can and should use the features that CVS gives you. Result: educate yourself and use CVS the way it is intended. 3. Your expectations of the workflow or users is right. You need a central repository and the feature set and phillosophy of CVS doesn't match your needs. Result: don't use CVS; do some research and find the repostory system that is right for your needs. CVS is not a one-size fits all sort of program. It is excellent for people and groups that want and need its features and for workflows that match the CVS philosophy if you will. There are tons of other code repository/source control/revision control systems out there, and if CVS doesn't map well to your needs, then you should fine one that does. And CVS isn't even the only OSS one out there either, though in the long run you might find it cheaper to use the right tool for the job even if it costs you money. CVS works well in our company. We've had to adjust the habits of some of our developers, but after a while everyone settled down and started using it properly. But I recognize that it wouldn't work as well in all cases. Do a little research and maybe you can find something that matches you better. - Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Personal CVS repository?
In her place, what I would do is: 1. Keep two local workspaces. One is the checkout from the remote repository, the other is the checkout from the local personal repository. 2. Do all my work in the local one, checking in as necessary. 3. When I release to the remote repository, I would copy all my changes to the remote workspace, run an update and fix any conflicts that the other site may have introduced, make and debug (again to deal with new stuff that the other side introduced), and then check into the new repository. 4. copy all that back into my personal workspace and checkin (since there is new stuff from outside) to the personal cvs. 5. Put a tag in my personal cvs to indicate this is the result of the merge with the remote cvs. Really, I don't know any other decent way to do it. editorial However... this seems like a huge extra amount of effort and time. I don't know why the supervisor is requiring such a thing, but in my opinion this seems like the real problem. Perhaps he's there to make sure that no company specific IP goes into the OSS project? I don't know, but such requirements (not the requirement to keep company IP out, the requirement to be checked) really kill the use of good revision control and collaboration with the external projects, and I'd say that the cost of such oversight really needs to be examined. We contribute to OSS projects here at my company and no one looks them over. We have NDAs and I feel that should be sufficient to keep company IP out of the OSS projects. And besides, my supervisors wouldn't even know how to read the code let alone determine if any of our IP is in it (but we've got a really small engr dept.). /editorial Jim.Hyslop wrote: MKlinke wrote: In a simple single-authored project where she is trying to maintain a much more fine grained control over her revisions that what the official repository allows I'm not sure why she would even want to sync the repositories? It seems a simple comment in her personal repository to the effect that At this point in development the code was released to the official repository should suffice. (By snycing I'm assuming you mean make them identical in all respects including cvs assigned revision levels at some point in time ) Given the assumption above, why do you feel syncing is important here? Well, without any further input from Jill, we're both making assumptions here. My assumption was that when she said: I'll be the only programmer on this project; moreover, my contribution will probably be pretty self-contained (i.e. I don't expect that anyone but me will be modifying the code that I write for this.) I assumed she meant she would be the only programmer *at her company* working on the project, but there could be other people from the open-source project, who might make changes. If Jill is the only person working on the code in any capacity, then a CVS repository is overkill. The local, fine-grained control might be more easily achieved by making a tarball (or Windows equivalent) when appropriate. But if she's not, then the whole issue becomes more complex - she will have to manage both her changes, and make sure to integrate the changes from the main repository. This is what I meant by keeping the two in sync. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CTRL-M and CTRL-J characters in files
The CVS client automatically handles the differences between Windows and UNIX line endings by converting the files when you do the checkout or update (or commit, or...). So, as unintuitive as it sounds, uncheck this option. Then you'll get the Windows line endings without those being imported into the repository. To cleanup your current problem, I'd sugest have your Linux guys check out the files, run them through dos2unix until the files are cleaned up, check them in, and then you need to do an update or checkout without that box checked. - Steve prolist wrote: I uses Windows 2000 machine and use Jcreator LE for my Java code. When I am adding files to CVS using WinCVS client, somehow other memebers of team using Linux machines are getting ^M^J in their files. Why is it happening and moreover how can I get rid of this automatically while checking-in and checking-out fiiles. There is a settings in WinCVS preferences Global tab which has a checkbox Checkout text files with the Unix LF (0xa) and I already have this checkbox checked. What should I do to avoid this problem? Thanks!!! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CTRL-M and CTRL-J characters in files
The line ending conversion happens with every (relevant) command that cvs does. Checkouts, commits, updates, exports, etc. Different OSes use different line endings on text files. CVS deals with text files, and so handles this very nicely. (but, see the earlier comment about the -kb flags) - Steve prolist wrote: But, isn't that option only about checkouts, what about check-ins I can't locate any poption specific to that. Thanks!!! - Original Message - From: Steve deRosier [EMAIL PROTECTED] To: prolist [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, March 25, 2004 1:01 AM Subject: Re: CTRL-M and CTRL-J characters in files The CVS client automatically handles the differences between Windows and UNIX line endings by converting the files when you do the checkout or update (or commit, or...). So, as unintuitive as it sounds, uncheck this option. Then you'll get the Windows line endings without those being imported into the repository. To cleanup your current problem, I'd sugest have your Linux guys check out the files, run them through dos2unix until the files are cleaned up, check them in, and then you need to do an update or checkout without that box checked. - Steve prolist wrote: I uses Windows 2000 machine and use Jcreator LE for my Java code. When I am adding files to CVS using WinCVS client, somehow other memebers of team using Linux machines are getting ^M^J in their files. Why is it happening and moreover how can I get rid of this automatically while checking-in and checking-out fiiles. There is a settings in WinCVS preferences Global tab which has a checkbox Checkout text files with the Unix LF (0xa) and I already have this checkbox checked. What should I do to avoid this problem? Thanks!!! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS on Samba
George, Putting the repository itself on a networked drive (Samba or NFS or others) is generally not recommended. Aparently there is a possiblity with data loss. If you're running a server anyway, I'd just run CVS from the same server and do the checkouts and such via the client-server style of using CVS via SSH or RSH (or pserver, but you didn't hear ME sugest that ;) ). We have a development server here that hosts both home directories mapped via Samba (for those silly people here still using Windows), and runs the CVS server. Most people here actually keep their workspaces on the Samba'd home mount and use a local client to do checkouts from the CVS server. So, the files in the workspace end up on the same machine as the CVS repository, but we always use client-server to make it happen. Even when I work directly logged into the server via ssh, I use pserver to do my checkouts; This lets me use CVS the exact same way both locally and from my workstation via Samba. This seems to work well for us. - Steve George Abraham wrote: Has anyone tried creating a repository on a Samba mounted drive?. Please share your experiences, and points to be kept in mind while doing the same. Regards, George Abraham ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: A way to see who has checked out a module?
Again... this isn't going to tell you much. It basically gives you a log of certain activity with the system. I can run the same command and I get the following results: * I have 21 modules checked out. Of those 21, I only have directories in my sandbox for 15 of those (where did those others go? probably rm -r them at some point when I didn't need to work on them anymore) Of the 15, I haven't touched 6 of them in close to a year, and in the last two months I've only even looked at 3. * Someone who left the company almost 6 months ago has 8 modules checked out. * One person only has 1 module checked out -- From March last year. * No releases are ever done by anybody. So, what info does cvs history -ao give you? Basically that someone checked out a module for some reason at some point. Does that give you the info you're looking for? Maybe. If so, I'd just setup a simple cron command: 'cvs history -ao /var/www/html/cvscheckouts.txt' But it doesn't tell me anything useful. - Steve Phil Labonte wrote: But you can see who has checked out files and when via the command line so all I was looking for is something to add to apache... I guess I will have to write my own perl script for cgi cvs -history -a -o shows all users and all checked out modules... Greg A. Woods wrote: [ On Tuesday, January 13, 2004 at 09:25:52 (-0500), Phil Labonte wrote: ] Subject: Re: A way to see who has checked out a module? I use ViewCVS as well but there is no option to see a log of checked out files is there? If there is can you let me know where? Fundamentally there's really no such concept of checked out files in CVS. There is no file locking in CVS, so checked out does not mean what I think you think it means. Any number of people can have any number of working directories checked out on any number of clients. None of it really makes any difference to how anyone would know who's really working on what. CVS is not a replacement for good project management. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: A way to see who has checked out a module?
viewcvs - http://viewcvs.sourceforge.net/index.html It's what we use and we love it. - Steve Phil Labonte wrote: Is there a web add-on that we can use to see who has checked out a given module? I know you can use the command line but I have some users that would like to see who has checked out a given module, and I do not want to give them shell access to the box. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs commit/up's change file ownership in working dir.
Scenario: N system admins. they checkout a machine's configuration into their private working directory. they all are not currently root (or I'll shoot them) and so the files are all owned by them with whatever default mode per standard (umask etc) procedure. They do their edits, check them into the repository. Now when a process on the host goes to the respository to fetch it's new/updated configuration files the perms of these Read-only checked out files had BETTER have the right perms on them or the processes that read them will fall over and die. AFIK, CVS really doesn't support this type of operation, and in fact it would probably break normal usage. Perhaps some other versioning tool does, or you can use the various checkin hooks to modify the behavior. If I was faced with this situation, I'd consider it a build issue. I'd have a make file in with these files, and my process (I'm assuming you've got some process that would be similar to a script running from cron?) would run a script that would do a checkout (as whatever user is aproprate, maybe give it a valid user with a home directory) or export, then run make on the Makefile. The Makefile would have whatever commands in it that are necessary to install the files: .SUFFIXES: *.cf *.conf .cf: chown whoever $ chgrp wheel $ chmod 600 $ mv $ /etc/. .conf: chown whoever $ chgrp wheel $ chmod 600 $ mv $ /etc/. This is only an example, write your own (not 100% if my syntax is correct even; security issues may be in above; check your permisions; etc...). That's just how I'd do it if I was faced with the problem, but YMMV. - Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Read only access to cvs
Purushotham Komaravolu wrote: Hi, I am new to CVS administration.I need help in seting up the following. 1) Read only access to repository: Developers ger read/write access but QA and others get read-only access. As an alternative, give developers real access to the repository with full read/write access, but install ViewCVS and only give the QA/others access to that. If they only need to take a look at the code on occasion with no need to edit, why give them actual CVS access at all? Also, the deveopers will find that ViewCVS is handy anyway. - Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Please help..
David, Perhaps John could try this? A suggestion to untangle: 1. Create a repository properly. 2. Copy the .v.v files into the repository manually. 3. Checkout the files into a working directory. (getting a .v file) 4. Copy the .v files manually into the repository. 5. Checkout the files into a working directory. (hopefully getting back the originals.) This assumes that the creating the repository over the original files didn't muck them up too much. John, Don't just try the above suggestion till we get more input. I'm just floating an idea and I think the experts here might have something more to say about it. Understanding how the repository is different from the working directory is crucial. A few clif notes: * You create a repository in an empty directory. This repository is separate and very different from the data you actually work on. In our case our repository is in /swdev/cvsroot. This is what the CVSROOT environment variable is set to. * You use ONLY cvs commands to get data into and out of the repository. Ideally you'd never directly touch the repository data. * You work in a separate working directory (off of your home directory probably, in my case /home/derosier/projects) and you check out your source code modules there. When you've made some changes you want to check in, you do a 'cvs commit' command. * Even if you run CVS locally, think of it as a server. It's a black box where you store things. You make requests to get data out, work on it, and then make a request to store data back in. From an OOP point of view: It is encapsulated data with a very well defined interface or API. Use the interface, don't touch the data. * If the above doesn't make sense to you, then read it again, read the CVS manual again until it makes sense. Do not try to setup and use CVS without understanding this. Hope this helps, - Steve David Wood wrote: You need to spend some time with the manual, and/or the various tutorials on the subject. As you are discovering, if you're not understanding the manual, forging ahead anyway may not be the best decision. A repository is a database (that holds its data in RCS files - ending in .v). You create a repository in an _empty_ directory, somewhere separate (with cvs init), and then you import sources into it from wherever you have them (with cvs import). Then you do a cvs checkout to create a new CVS working directory from the repository - and that is where you then do your work. (Often people will move or zip the original directory they imported from, and then move their CVS working directory into its place.) You've created a repository right on top of where you are working, which is bad. I confess at this point I'm not sure what you've got in those files (perhaps someone wiser than myself can offer a shortcut?), but my best guess is that it will be easier to recover from backups than to reconstruct your sources from what's left of them now (.v.v files). At any rate, since you have backups, there is no reason to panic. In the future, just put your repository somewhere separate (/home/cvs/repository ?). And of course, have another go at the manual (or some of the other reading materials) to get a better handle on how the system works. John Wards [EMAIL PROTECTED] wrote on 11/26/2003 12:25:42 PM: On Wednesday 26 November 2003 4:57 pm, David Wood wrote: First, did you work for 18 months on something without making backups? Yes yes of course, but they are not with me currently and I am in a bit of a panic! Second, to get help you will need to be much more specific about exactly what you did when you figured out how to make a repository from your original source files. How did you set everything up (CVSROOT, etc)? What commands did you run? It sounds like you have some confusion about repositories versus working directories and the import process. Did you read the CVS manual before you started? I fear from your description you've gone pretty far down the wrong way. Yes I read the manual and I should have probably been a bit more detailed but I thought ah someone wil know an easy undo comand.seems not then :-( I got a bit confused with all the CVSROOT stuff etc. My source files are in /home/johnwards/www/sportnetwork I thought I should have done this: CVSROOT=/home/johnwards/www export CVSROOT cvs init Then: cvs import -m SportNetwork first import -d sportnetwork sportnetwork start This was wrong :-( I think. As its changed all my files... I am really confused by the manual...all I want to do is set up CVS using my source files...how on earth do you do it as I am really confused.. John ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: automatic checkout
How about a script on a cron job that periodically (whatever granularity you require from 1 minute to 1 day) checks to see if there's been any new updates and if so does an update to the production tree? Seems like a rather clunky work-arround, but it should at least get the results you're looking for. - Steve Roderick Bloem wrote: Hi, I want to use cvs for a directory that contains scripts. I don't want everyone to change the scripts in the directory: I won't have accountability. Thus, it is under cvs. People should check out, change, and submit. I don't want them to write to the directory itself, because they will forget to check in. I would like changes to propagate to the script directory immediately. Everytime someone commits, an update would be executed in the script directory. Is that possible? I have tried a loginfo script, but there is a problem with the locks: the cvs update runs when the commit has not released the lock yet. I have looked on the web and found some references, but nothing very satisfactory. I have seen ACU, but it seems more concerned with managing multiple machines (which is not a problem), than with the lock. I have also thought about putting a pause into the script that does the update, but that does not seem very safe, not do I know how to do it. (My shell programming is bad, and I don't know how to spawn a process from loginfo.) Is there a good solution for this? Should I consider a different setup? Thanks, Roderick Bloem ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ViewCVS vs. CVSWeb with CVSNT
Yes, ViewCVS does those also. One feature I love about it is the CVSGraph view. You can choose to looke at a file's history in a graphical graph, with boxes to indicate each version, and it shows the branches graphically. Clicking on any box will bring up the file as it was in that version; clicking between any box will bring up a colored diff between the two versions. Of course, all the same info and links are available in text information also on a different page. I just find the feature very useful. It does also handle showing the module file list by tags and branches, but I've found the interface implmentation of that to be a bit clunky (it works well, but it's not always obvious what state you're in or how to change it to the one you want). - Steve JacobRhoden wrote: On Fri, 8 Aug 2003 08:40 am, Steve deRosier wrote: We use ViewCVS and we love it. We use it for all sorts of things including tracking the CVS repository and just viewing source files in other projects (have you ever wanted a quick look or printout without checking out the module and opening it in an editor?). For best usage though, it is good to have both enscript and CVSGraph. We run it on a Linux server, not NT. You can't grab/checkout a module over the web, but you can grab the full source as a text file for a particular file version. Also, it's purely a viewer, there's no administrative functions or other CVS functonality to it. cvsweb does all those exact same things (: I dont know viewcvs but I am guessing they are fairly the same. One thing that wasnt mentined as being in ViewCVS but is in cvsweb, is that cvsweb can do diffs between versions of files either on revision numbers, dates or tags. And can view modules based on tag/branch. (: _ Jacob Rhoden - http://rhoden.id.au/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ViewCVS vs. CVSWeb with CVSNT
We use ViewCVS and we love it. We use it for all sorts of things including tracking the CVS repository and just viewing source files in other projects (have you ever wanted a quick look or printout without checking out the module and opening it in an editor?). For best usage though, it is good to have both enscript and CVSGraph. We run it on a Linux server, not NT. You can't grab/checkout a module over the web, but you can grab the full source as a text file for a particular file version. Also, it's purely a viewer, there's no administrative functions or other CVS functonality to it. I've never used or installed CVSWeb so I can't speak to that package. I hope that helps some. - Steve Portabill wrote: Hello all, Which web server is better/preferred for web access to the CVS repository? ViewCVS or CVSWeb? Reasons? I hope this doesn't start a religious war. Thanks, Bill ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: port not running!!!
If you're checking from an external box, don't forget to punch a hole in the server's firewall if one is running. A firewall that we didn't realize was running on our RH box tripped us up for a couple of hours. - Steve Kent Emia wrote: port not running!!! I ve checkec http://www.freeos.com/articles/4608/?PHPSESSID=a898a2e13956084daeb236798a405bad http://www.freeos.com/articles/4608/?PHPSESSID=a898a2e13956084daeb236798a405bad and in the # 13 ^ th it says to check if the CVS is running on the port 2401 but what if I can t see it? it doesn t tell what to do next . btw how do I do that? Kent ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
Phil, As you know, CVS doesn't version directories and frankly was never designed with that in mind (never mind the argument over if it should or should not, it simply doesn't). But...there is a program that does record directory structure: tar. Perhaps you could somehow use tar in conjunction w/ CVS to do what you want to do. OR Alternatively, since you're a Perl programmer, why not just write a simple script to parse the directories. You could write two scripts: Script1.pl - This one recursively parses the directories, writing a file (or to stdout) a representation (in text, best if easily human readable) of the directory structure. Script2.pl - This one parses the representation file and creates the directory structure. The representation since it is in text _could_ and in this scenario _should_ be checked into CVS and properly versioned. There may be a way to get CVS to handle a ci and co of the full ERP system using these scripts and the wrappers (not sure, I've never used the wrappers), but if not, you could always have a project 'ERP' that contains a Makefile and the representation file. You checkout the ERP module, run make, and boom, you've got your whole ERP retrieved from the repository. The Makefile would have the instructions to: 1. run Script2.pl on the representation file and build the ERP directory structure 2. run the necessary CVS co or export commands to grab the required files and put them in the right places. Maybe your Makefile could have both a ci and a co target so you could run 'make co' and 'make ci' to do what you want to do. Anyone with some competence in Perl and make should be able to build this little build environment in a few days (and don't ask me, I already have a full time job). Do it in house or hire a consultant. (And don't forget to check the scripts into CVS while you're at it). But, you've got to decide on a trade off - pay the big bucks for ClearCase or pay (either time or money) to have someone build you a custom build environment. And, you need to evaluate ClearCase to decide if it really does what you are trying to do, or if you're going to have to bend to their way of doing things. I don't know, I have no experience or knowledge with ClearCase at all. Really, this was all anyone was trying to suggest when they said that CVS doesn't do directories and you'd have to use a build tool to handle them (and frankly, this is the 'proper' way to do it from the CVS paradigm). As to the CVS paradigm, it's pretty simple: CVS versions files (text files primarily) and allows for multiple people to checkout and edit those files concurrently. CVS doesn't think anything about directory structure except that it is possible to nest Modules within one another. (Frankly it seems to work best and is happiest when the directory structure is relatively flat.) Directories have no purpose other than to be containers for files (which CVS does care about and will version) and as such, other than structure and name, are so un-interesting to be beneath notice. That's it. Don't think too hard on it. As is typical with Linux and other UNIX systems, CVS is a simple tool meant to do one simple job and nothing else. CVS versions files. If you want to do more, add more tools into the mix (tar collects files and directories into one large file, but doesn't compress them; gzip compresses single files but doesn't collect them; together the two can grab and archive a large swath of the filesystem and make it small enough to fit on one CD). I don't know if any of this helps, but I hope I gave you an idea that you hadn't considered. - Steve Phil R Lawrence wrote: Well, I want to say thank you to all who posted regarding my query regarding dir versioning. That was a heck of a discussion. My resulting perspective: CVS seems innapropriate for our real world needs, preferring instead to serve a purer versioning paradigm. (A paradigm which, by the way, seems too complex for me to easily understand.) To recap, I was looking for: - the complete history and versioning of every individual file - the ability to recreate dir structures, including hard and symbolic links These 2 things would have allowed me to checkout our whole ERP dir structure as of a given date. Sweet! Greg says to use the right tool for the right job. Well, I wish CVS were the right tool, because the two right tools I've read about have real problems! ClearCase: ClearCase costs a lot of money. I mean a *lot* of money. Now, my organization might pay for it, or they might not, I don't know. We are a University in the USA, so we do have money. But I guarantee most of this world would never in a million years be able to pay that sort of money. So while my org might get by, the rest of the world suffers for the lack of an open source solution. My own custom build tool, wrapped around CVS: Gimme a break. It's taken our ERP vendor a decade (more?)
Re: outsider's perspective
Greg, I wasn't trying to indicate that tar was the perfect tool for this, or even that it was or might be the right tool. I was simply suggesting that trying multiple tools in sequence might accomplish what was desired. tar was simply an example suggestion of a place to start looking. But, I would disagree that CVS already does effectively what tar does... No, tar creates a single binary file for archive purposes. CVS does not do this. Also, tar DOES handle directory information and can preserve owners, permissions and all other directory meta-info. CVS does not do this. tar DOES NOT handle versioning or history information. CVS does do this. I was suggesting that somehow combining the two tools it may be possible to create a system that did what he was looking for. I've been lurking on the list for a very long time, and it seems to me that the one of the largest perceived deficiencies with CVS is it can not handle directory meta information (in other words, it can't version directories). Perceived because some people consider this a deficiency while others consider it the right way. Now, I'm not willing to debate if CVS is right or wrong in this, but it must be conceded that CVS doesn't do this, and as such may not be right for everyone. I've never needed the functionality, so I don't have an opinion on it one way or another. Regardless, it doesn't really matter. CVS doesn't do as the poster wants. There may be ways to handle it using CVS + some other standard Linux tools, or maybe the poster will just need to move on to another tool. Also, if so many people NEED this functionality, why doesn't it get added to CVS? If people only THINK they need it, then why don't we tell them how to do what it is they are actually trying to accomplish while using CVS? Maybe this NEED is real, and maybe it's just marketing from commercial version control companies, but one way or another it gets asked for. Giving people on this list the usual if it doesn't work for you, well #*@ you, go somewhere else rant seems counter-productive. Perhaps if we all discuss it calmly and logically, we can find a way to give people what they want and remain true to the CVS-way. Some of the stuff on this list lately is beginning to look like a religious war, instead of useful discussion. Thanks, - Steve Greg A. Woods wrote: [ On Tuesday, May 27, 2003 at 11:39:22 (-0700), Steve deRosier wrote: ] Subject: Re: outsider's perspective As you know, CVS doesn't version directories and frankly was never designed with that in mind (never mind the argument over if it should or should not, it simply doesn't). But...there is a program that does record directory structure: tar. Perhaps you could somehow use tar in conjunction w/ CVS to do what you want to do. CVS already does effectively what tar does, and it already does it with support for recording the addition and deletion of files temporally, something which tar obviously cannot do. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
No concurrent versioning system with a shared repository, and particularly not one that can operate in a client/server mode, can ever possibly make any use of ownership, nor even of most permissions bits. Ownership information, and most permissions bits, MUST always be specific to the client and it MUST NOT be dictated by the repository. Yes, this makes perfect sense, and I agree with you. Frankly I'm not even sure what it is that various people are asking with keeping the other meta info. But it seems that there are other bits (not as in 1s and 0s) of meta information that people want to keep about directories. Are symbolic links kept and versioned by CVS? If people would learn two things then all this stupidity would disappear in a puff of smke: (1) CVS is a text file content change tracking tool, and _only_ a text file content version tracking tool; (2) all these things (file permissions, ownerships, symbolic and hard links, etc.) can far FAR more elegantly, simply, and clearly be managed by a build script, the source for which can be stored in CVS. Again, I agree with your point of (1). Also, I think that a build script is a good way to handle things (but I've always been a huge fan of the power of make and use it for many things beyond just building my latest C/C++ projects). But, what about large directory structures of a web site? The directory information is meaningful. And the person doing the maintaince can't always login as the psudouser the web server runs as. And a build script isn't necessarilly meaningful in this context either. tar DOES NOT handle versioning or history information. CVS does do this. I was suggesting that somehow combining the two tools it may be possible to create a system that did what he was looking for. How do you expect to meaninfully combine a tool that creates binary files with CVS?!?!?!? Frankly, I felt that was an exercise for the reader. But one idea (not necessarily the best idea or even a good idea) was the user could tar up the directory structure and put the tar archive into CVS (using the approprate -k flag of course). I would think you'd want to separtely ci your text files that were in those directories though so the changes could be tracked better. Perhaps not good and maybe not any better than just keeping a directory with date-munged-file-named tar files. As I said, example and not a good idea. :) Again, the point was missed. It was an example that by combining tools (using make or other build facility), the user could come up with something that would do what it was they were trying to do. And as I recall, isn't that the whole point you've been trying to get across - use a build facility of some sort to do the parts that CVS doesn't do? Also, if so many people NEED this functionality, why doesn't it get added to CVS? Have you not been paying any attention to the rationales I and others have given for why CVS is the way it is and why it doesn't do some things? Of course I have been. Considering that the same song and dance has been done here regularly to avoid making meaningful improvments in CVS, I could hardly miss it. Many of the rationales are perfectly valid, but sometimes it sounds like you (and others) are rationalizing out a reason it can't be done simply because you don't want it to be done. I'm often guilty of the same thing :) , but maybe we should try to be honest with ourselves and try to come up with a VISION of what CVS should be and where it should go in the future. These problems and questions won't stop simply because we rationalize that CVS was designed to solve this set of problems but not that set. I agree that CVS is for versioning text files. But there are many text files formats (XML, HTML, RTF and so on. All are text files.). And some of these do depend on directory structure to be meaningful. And some of these are occasionally not handled properly by CVS if the reports on this list are any indication. CVS is great, and it handles text files fine. But putting arbitrary roadblocks in front of your users defeats the whole purpose. - Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: pserver login problem to Linux from Win2k
Ok, got this figured out. Just incase anyone wants to know: I'm using a CVS binary from cvshome.org's download pages. Specially the one from: http://www.cvshome.org/dev/codewindow.html I did define the HOME environment variable and now it's creating the .cvspass properly. But still: J:\projects\ORHwBringUpcvs ci -m mycvstry Makefile cvs commit: in directory .: cvs commit: ignoring CVS/Root because it specifies a non-existent repository /swdev/cvsroot cvs commit: in directory .: cvs commit: ignoring CVS/Root because it specifies a non-existent repository /swdev/cvsroot cvs commit: in directory .: cvs commit: ignoring CVS/Root because it specifies a non-existent repository /swdev/cvsroot Here's what is happening: 1. J: is a networked drive connected to my home directory on our Linux server via Samba 2. I started doing my work telneted into the server and got checkin and checkouts working fine 3. CVS creates the directory CVS inside your workspace when you do your checkout; it also creates the file Root in that directory set to your CVSROOT where you got your files checked out from. In my case this CVS/Root looked like '/swdev/cvsroot' 4. I then tried to checkin some changes via CVS in a DOS box on my local machine, with CVSROOT=:pserver:derosier@engswdev:/swdev/cvsroot These failed with a message of: cvs commit: ignoring CVS/Root because it specifies a non-existent repository /swdev/cvsroot Reason: CVS stores your CVS Root in the file Root off of the subdirectory CVS in you project's working directory. It uses this file to determine where the files should be checked back into, ignoring the actual CVSROOT variable. This is normally not a problem, but it is in the case where you do the check out locally, then do the edits and try to check them in remotely (since this is a samba network drive to my windows 2k machine) using the pserver method. In this case it fails because CVS/Root has the wrong CVSROOT string. New question: Is there an easy way to fix this problem, so I can transparently use CVS in the same working directory both remotely and locally? Basically, my current fix is to only use one method, ie only do my work remotely using pserver. Thanks, - Steve -Original Message- From: Shankar Unni [mailto:shankar;cotagesoft.com] Sent: Wednesday, October 30, 2002 11:35 AM To: 'Steve deRosier' Subject: RE: pserver login problem to Linux from Win2k Looks like you should do these operations in a clean area. Also, which Windows CVS client are you using? The CVSNT client? Or the Cygwin CVS client? Try defining a HOME environment so that it has forward slashes instead of backslashes. (set HOME=c:/). -Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs-admin;gnu.org] On Behalf Of Steve deRosier Sent: Wednesday, October 30, 2002 9:38 AM To: CVS Discussion List Subject: pserver login problem to Linux from Win2k I have a CVS repository on our Linux development server that I need to access from my Win2k box. I can access that repository logged in locally on the sever via telnet, and I can also access it via WinCVS, but I need to be able to access it from the command line (trying psever). CVS from the command line is complaining about my CVSROOT variable. It's probably just a simple Win vs Unix syntax issue, but I need help. Version on the sever is CVS 1.11.1p1 and I just downloaded the binary for Win which is v1.11.2 Sample of my session via a DOS window (CVSROOT is set as an environment variable to be ':pserver:derosier@engswdev:/swdev/cvsroot'): --- J:\projects\ORHwBringUpcvs ci -m cmdline test Makefile cvs commit: in directory .: cvs commit: ignoring CVS/Root because it specifies a non-existent repository /swdev/cvsroot cvs commit: in directory .: cvs commit: ignoring CVS/Root because it specifies a non-existent repository /swdev/cvsroot cvs commit: warning: failed to open C:\/.cvspass for reading: No such file or directory cvs commit: authorization failed: server engswdev rejected access to /swdev/cvsroot for user derosier cvs commit: used empty password; try cvs login with a real password J:\projects\ORHwBringUpset CVSROOT=:pserver:derosier@engswdev:/swdev/cvsroot J:\projects\ORHwBringUpecho %CVSROOT% :pserver:derosier@engswdev:/swdev/cvsroot J:\projects\ORHwBringUpcvs login cvs login: in directory .: cvs login: ignoring CVS/Root because it specifies a non-existent repository /swdev/cvsroot Logging in to :pserver:derosier@engswdev:2401/swdev/cvsroot CVS password: cvs login: warning: failed to open C:\/.cvspass for reading: No such file or directory BTW--engswdev properly resolves to the IP of the server as it is set in my hosts file. Any ideas would be great. Thanks, - Steve -- Steve deRosier PianoDisc Design Engineer (916) 567- ext. 175 www.pianodisc.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http
RE: pserver login problem to Linux from Win2k
Well, I don't know that I can't do that, considering that it works just great for me. Though the editor that I'm using on my Win2k box (SNiFF+) understands UNIX line endings and has an option to save as Win/DOS, Mac, or UNIX line endings (which is of course what I have selected). So my code files get edited properly. I assume that the client CVS program actually contacts the server CVS program when a checkout or checkin is done. So...presumably it is the server CVS that handles the writing of the administrative files, so I would assume the integrity of the line endings would stay intact (UNIX style). Am I assuming too much? Unfortunately the two-sandbox thing doesn't work with the tools I'm using. But since I seem to be perfectly functional if I choose to do one or the other (local or remote), but not both, things workout fine. I just wanted to know if there was a way I could do both (have my cake and eat it too). See...the other two people in my development team will only use Win2k but as I'm very much a Linux person I'd rather have the option of doing both. But if not, oh well. The biggest problem was that I tried getting each piece up and running independently first than tried to get them to work together. Usually is a great idea to make sure two parts work by themselves first. Who knew? :) - Steve -Original Message- From: Kaz Kylheku [mailto:kaz;footprints.net]On Behalf Of Kaz Kylheku Sent: Thursday, October 31, 2002 4:12 PM To: Steve deRosier Cc: Shankar Unni; CVS Discussion List Subject: Re: pserver login problem to Linux from Win2k On Thu, 31 Oct 2002, Steve deRosier wrote: Here's what is happening: 1. J: is a networked drive connected to my home directory on our Linux server via Samba You can't do that, because Linux and Windows don't agree on the representation of text files. This affects the treatment of text documents on update and commit, and also the representation of the CVS/ administrative files. So even if you solve the location non-transparency problem by using a CVSROOT that works everywhere, you still have this problem. New question: Is there an easy way to fix this problem, so I can transparently use CVS in the same working directory both remotely and locally? You can simply maintain two separate sandboxes. To propagate changes from one to the other, commit in one, and update in the other. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
pserver login problem to Linux from Win2k
I have a CVS repository on our Linux development server that I need to access from my Win2k box. I can access that repository logged in locally on the sever via telnet, and I can also access it via WinCVS, but I need to be able to access it from the command line (trying psever). CVS from the command line is complaining about my CVSROOT variable. It's probably just a simple Win vs Unix syntax issue, but I need help. Version on the sever is CVS 1.11.1p1 and I just downloaded the binary for Win which is v1.11.2 Sample of my session via a DOS window (CVSROOT is set as an environment variable to be ':pserver:derosier@engswdev:/swdev/cvsroot'): --- J:\projects\ORHwBringUpcvs ci -m cmdline test Makefile cvs commit: in directory .: cvs commit: ignoring CVS/Root because it specifies a non-existent repository /swdev/cvsroot cvs commit: in directory .: cvs commit: ignoring CVS/Root because it specifies a non-existent repository /swdev/cvsroot cvs commit: warning: failed to open C:\/.cvspass for reading: No such file or directory cvs commit: authorization failed: server engswdev rejected access to /swdev/cvsroot for user derosier cvs commit: used empty password; try cvs login with a real password J:\projects\ORHwBringUpset CVSROOT=:pserver:derosier@engswdev:/swdev/cvsroot J:\projects\ORHwBringUpecho %CVSROOT% :pserver:derosier@engswdev:/swdev/cvsroot J:\projects\ORHwBringUpcvs login cvs login: in directory .: cvs login: ignoring CVS/Root because it specifies a non-existent repository /swdev/cvsroot Logging in to :pserver:derosier@engswdev:2401/swdev/cvsroot CVS password: cvs login: warning: failed to open C:\/.cvspass for reading: No such file or directory BTW--engswdev properly resolves to the IP of the server as it is set in my hosts file. Any ideas would be great. Thanks, - Steve -- Steve deRosier PianoDisc Design Engineer (916) 567- ext. 175 www.pianodisc.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
