Re: updating Entries files only
How about renaming the *repository* directory ABC to abc? Try it (in a copy of the repository) and see if it breaks anything that you care about. Fred Spiro Trikaliotis wrote: Hello Jim, * On Tue, Apr 19, 2005 at 03:31:33PM -0400 Jim.Hyslop wrote: If you get into that situation, then the solution is to (a) go rap somebody's knuckles, then (b) fix the collision in the repository. Well, renaming ABC/ to abc/ was a deliberate decision as all directories should be lowercase on our side. We did not know that CVS has such a problem with this. Removing ABC/ from the repository would break history and the ability to build old versions, thus, it is out of question. Yes, we use co -P, thus, I would have assumed that ABC/ is already gone before abc/ is tried to be checked out. Anyway, this is not the case. IMHO, this is a CVS bug, isn't it? If you want to use cvs, you HAVE to fiddle around with the Entries file. I would disagree completely with that statement. I'm sorry, this statement was not meant as it seems to be. It's my fault, I should have formulated it more precisely. Thus, I reformulate: IN THIS SITUATION [given above], if you want to use cvs, you HAVE to fiddle around with the Entries file [because CVS will not work otherwise]. Regards, Spiro. -- Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Restricting use of 'cvs rtag' 'cvs tag' commands [2nd try]
Install cvs in a different place than the version you are using. Make a script named cvs in the current location of cvs. That script should check the cvs commands vs. valid users. If everything is OK, then it should invoke the new cvs in the new place with the arguments passed to it. This won't protect you from truly malicious developers who invoke cvs directly from the new location, but you probably have already fired those people from your project. :-) Fred David Leskovac wrote: [I sent this msg 10 days ago noone responded. So, I'm trying again.] Hello, We are currently using an ancient version of CVS (1.11.1p1) on a rather old Linux server (Red Hat 6). I intend to upgrade to CVS 1.11.19 eventually upgrade the Linux OS. In the course of our CVS upgrade discussion we started discussing how to increase security with regards to CVS access. I am aware of the cvsacls script that provides fairly fine-grained permissions to do check-ins but is there also a way of restricting who is allowed to do certain cvs commands? In particular, we would like to restrict who can create/delete tags branch tags. Is it possible to restrict 'cvs tag' 'cvs rtag' on a user or group level? Thanks, -Dave ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: Q on keyword substitution]
Pierre Asselin wrote: Well, suppose you edit the file and add a line with a '$Rvision' marker, misspelled. You commit that, the bad marker goes in the repository. You check out or update, the keyword is not expanded/clobbered because of the spelling error. The information you need is still present in the repository and you can still see it, e.g. with 'cvs annotate', but someone will have to edit the file and manually correct the bad line. If you are going to depend on the expansion of a keyword, then your process should specify a check that the keyword is expanded correctly immediately after a commit. Your local file will have the expansion. If it doesn't, then correct the misspelling and try again. My suggestion was to use a spelling that can be checked by a utility, and to enforce that check in a commitinfo hook. You can do that anyway. Just make a commitinfo hook that tries to find the string '$Revision: ' in the file. Of course, that leads to extra configuration management work because you probably want to exclude some files from the check. That, of course, can lead to more errors. You still need pay attention to process. Fred -- Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore *.
Thomas Bornhaupt wrote: I want to ignore *. my C-Compiler creates binary files without extension. But this files are not nessesary in the CVS Are you running on a Unix system? If so, then *. matches files with a period as the last character. Files without an extension may not have that period. '*' matches files without a period, but it also matches all files. If you are running on a Windows system and using CVSNT version 2.0.51d (the one I tested with), then '*' matches a file without an extension. Unfortunately, it also matches all files. I'm not sure there's a way to specify all files without an extension that also doesn't match all files. Maybe this is a bug in CVS. But then, one could claim that your C compiler has a bug. :-) Just out of curiosity, what C compiler are you using? Fred -- Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Two different platforms sharing common code base: How to do so?
At 06:30 AM 11/29/2004, Spiro Trikaliotis wrote: No. 1 has been rejected, as the Linux guys thing: GNUMakefile is a name which is reserved for makefiles which use GNU-specific extensions. Choose a different name. ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: new user - do people store compiled code under cvs
At 04:39 PM 11/29/2004, Rachel Suddeth \(Bloodhound Software\) wrote: would you save versions of things like executables, p-code, or DLLs No. Not in CVS. It's a good idea to save a copy of whatever you release to your clients so you can recreate your client's environment. However, CVS is not really good at storing binary information. I just make tar or zip files of whatever I release, name the file appropriately, and put it in a well-known place. There are far, far fewer of these than versions of source files in CVS. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: how to check out a project which contains modules from different branches
I have done this for a project. It was very successful. It was in MS
Windows, too.
Also, useful to our environment, each of those cvs checkout commands can
have different CVSROOT values. Once the checkout is done, CVS keeps track
of the repository for each directory and there is no problem with update or
commit.
BTW, since the checkout.{sh,cmd} file is version controlled, this is one
way to get around the static module definitions in CVSROOT/modules.
Another beneficial side effect is that your build script (put it in the
X-wrapper module) can assume the directory structure created by the
checkout script, and it is version controlled along with that structure.
I also added a script to check for the presence of third party modules
required by the build script. If it didn't find something, it pointed to a
file with instructions on how to order/download/create the required software.
What's my measure of success? Well, I'm no longer working on the project (I
just did the SCM), but the project has grown and I see that the developers
keep files in the wrapper module up to date, AND nobody asks me to fix
anything.
Fred
At 08:30 PM 11/10/2004, Pierre Asselin wrote:
Would a two-step process work for you ? Recently I've been thinking
about a wrapper project. Something that would work thus:
$ cvs checkout X-wrapper
U X-wrapper/README
U X-wrapper/checkout.sh
and the README file would say:
Run sh checkout.sh to get the rest of the tree. Bye.
The checkout.sh script would contain these commands,
cvs checkout C
cvs checkout -r branch_2-5 A
cvs checkout B
and by running it you would get the correct revision of
each subtree. The script is rev-controlled, so it can track
changes in branch tags when subprojects get merged to
their trunks.
I guess this sort of thing (programmability) comes more
naturally in *nix. Bah, even Windows lets you write
a checkout.bat, so it will work there too.
___
Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How to format source code on commit
At 11:47 AM 11/9/2004, Matt Doar wrote: This works for me with indent on C source. It is a little disturbing to commit a file and then have emacs tell you the file has changed, because it was reindented. Will this work correctly with client/server CVS? The reformatting will happen on the server, but the client will never be notified. I would think that the next commit by the same client could get into trouble. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How to format source code on commit
At 12:46 PM 11/9/2004, Matt Doar wrote: We use client/server. I believe that the local file is formatted and then sent to the server. Perhaps I'm mistaken? commitinfo, loginfo, and other CVSROOT scripts run on the server. If they didn't then it would be impossible (or at least extremely difficult) to write a *info script for a heterogeneous development environment. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs bulk remove/add
At 03:47 PM 11/8/2004, Alex Valentine wrote: One of our developers has a simple task. He wants to move a boatload of files from one directory /lib to a new directory /src/lib. How can this be done in CVS without having to individually add and remove each file? CVS by itself does not help you automate this task. Write a script. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: how to delete a branch
At 11:29 AM 9/30/2004, Bill wrote: I created some branch for exercising. Now I have trouble to delete them. Is the presence of the branch interfering with something? Why not just let it be? Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS - brief summary
At 01:51 AM 9/10/2004, Erik Andersson wrote: Try cvs -q update He probably meant cvs -nq update Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Patch for CVS 1.11.17 and CVS 1.12.9 that allows for actions using specific versions of CVSROOT/modules
At 02:34 PM 9/2/2004, Mark D. Baushke wrote: Note: A CVSROOT/modules file that was not branched or tagged will also need to do something reasonable given a '-M rev' flag. Isn't the current behavior equivalent to forcing a head revision? That seems to be a reasonable default behavior. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Why's it a sandbox?
At 08:26 PM 8/18/2004, Doug Lee wrote: Hehehe...I think sandbox is a cool term and never thought of it as at all demeaning. Sandpit, on the other hand, quickly made me think maybe someone was trying to be politically correct or something. Personally, I much prefer sandbox over an overzealous attempt to be PC any day. :-) If we really want to be PC, we'll have to get rid of all of those offensive terms: execute, kill, abort, trap, dump, ... :-) I like the term sandbox, too. I've never heard an EE complain that the term breadboard demeans them as bakers. Lighten up! Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: /#cvs.lock): No such file or directoryctory for some directory inrepository
At 05:37 AM 8/18/2004, Jim Page - emailsystems.com wrote: I think I have expressed myself badly. Our developers are working on both windows and linux -at the same time-. Either with 2 dev boxes, or using VMware to run the other OS, with a partition shared between the 2. What is being suggested here is using commit to propogate changes between a given developer's OS-specific sandboxes during development. I am talking here about 'ok that fix builds under windows, lets see if builds under linux'. In our case right now this class of commit would not be done, and I can't see how this won't lead to an increased risk of nonsense in the repository. Maybe I'm splitting hairs but even if the risk is small it just doesn't seem a good idea. I can't believe our situation is all that rare. You might consider using branches. Make the commits on the branches, test, then if everything works correctly you can merge to the trunk. That way, the trunk has a high probability of not being broken. Yes, this has more steps. However, you are working in a more complicated environment than usual so you shouldn't be surprised by extra complexity in the development process. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: group permissions on parts of a module
At 12:34 AM 8/5/2004, Mark D. Baushke wrote: Failing that, have a crontab job run thru the tree every so often and change the group for you. I suppose another way around it would be to run the cvs executable on your server as a set-gid process. I don't recommend it unless you know what you are doing. Could you also put a chgrp command in a commitinfo script to change the group of files being committed? I'm not sure that will work, though. How about making a commitinfo script that starts a process in the background that sleeps a short time and then does a chgrp on all on all the files in the repository directory involved in the commit? That should do it and will probably be better than a crontab job. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: commitinfo file question
At 12:41 PM 8/5/2004, Tennis Smith wrote: I have a question concerning commitinfo and project standards. Is it possible to run an app (called by commitinfo) against a particular file in a specific sandbox at commit time? I'm trying to prototype a stylechecker and don't want anyone but myself affected initially. Commitinfo scripts can see only the files that are being committed, unless you are running with a local repository. Then the script can see all of your files. It's probably easiest to create a new temporary and test your commitinfo script in there. You could also check $USER in the commitinfo script. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: commitinfo file question
At 12:53 PM 8/5/2004, Frederic Brehm wrote: It's probably easiest to create a new temporary and test your commitinfo script in there. That should be a new temporary REPOSITORY Sorry, Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: using cvs history files e, g foo.c, v to clone a hierarchy and retain the history
At 12:58 PM 8/2/2004, sfgaijin wrote: I tried just adding the *,v files into cvs via cvs add and cvs update; but it did not recognize that the special nature of the files; i.e. I ended up having a bunch of *,v,v files. No, no. Just copy the *,v files directly into the new repository. For example, suppose you want to make a copy of MODULE/FILE from /OldCVSROOT into /NewCVSROOT. Just cp -r /OldCVSROOT/MODULE/FILE,v /NewCVSROOT/MODULE Of course, if the old and new roots are on different systems and you cannot just copy, then you can use any other mechanism to transport the file from one system to another. If you checkout both MODULE sandboxes and run cvs status FILE in both, then the output from both will be identical except for the CVSROOT directory path. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a way to Auto-Watch ?
At 01:05 PM 7/29/2004, Dan White wrote: The task manager has decreed that all changes to all files will be checked in on a daily basis. (Despite the attempted reasoning about how CVS ain't built that way) Give everyone a branch to work on and let them commit whenever they want. When they are ready to add to the baseline, have the task manager :-) perform the merge to the HEAD. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Any 'contrib' scripts have access to pre-commit source?
At 06:12 PM 7/26/2004, Peter Connolly wrote: In order to do this I need access to the source that is going to be committed. I think that the default directory of the commitinfo script is the tmp directory that contains all of the files being committed. Try an experiment with a script that just grep's for some pattern in the list of files being committed. If you see the output of grep, then that's the right place. Take it from there Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Probleme using CVS
At 10:59 AM 7/23/2004, you wrote: I can't add the file how have size equal or more than 500 Mo You might be running out of temporary disk space, or swap space. use the cvs -t switch on your command and post the result to the list. ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Setting up a new CVSNT or Linux server ??
At 08:46 PM 7/21/2004, Pierre Asselin wrote: Frederic Brehm [EMAIL PROTECTED] wrote: [ case-sensitive client with case-insensitive server] In your scenario, it appears to me that the only failure comes with the CVSNT server and UNIX client. In that case, the user knows that there are two separate files file and File in the directory and CVS should be able to add both but it refuses. But allowing the add would be worse for the developers on case-insensitive clients. For them, the next update would yield endless messages to move File, it is in the way. You are presuming a particular process model which is not universally true. Therefore, allowing the add is not, a priori, bad. Is anyone here old enough to remember the phrase The whole world is not a VAX? ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Setting up a new CVSNT or Linux server ??
At 09:01 AM 7/21/2004, Paul Nusbaum wrote: I am looking into the options CVSNT for a server, or possibly Linux. Well, on this list, you'll probably get recommendations for Linux. If you want a recommendation for CVSNT, just ask at [EMAIL PROTECTED] :-) But, it depends on a lot on your environment. Are you a Windows-only shop and expect to never use Linux (or Mac OS X, or Solaris, or many non-Unix type systems) for development? Then CVSNT is probably for you. If you will use any client that runs on something other than Windows, then you should probably strongly consider a Linux host. There's other reasons to consider a Linux or other Unix-type host, but watch out for religious arguments when you start talking about them. [Personally, I'm of the Unix-type persuasion.] Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Setting up a new CVSNT or Linux server ??
At 09:51 AM 7/21/2004, Jim.Hyslop wrote: If you will use any client that runs on something other than Windows, then you should probably strongly consider a Linux host. Now, just to be sure this doesn't come across as a religious-type argument, can you provide a reason for this recommendation? Filename case sensitivity. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Setting up a new CVSNT or Linux server ??
At 02:08 PM 7/21/2004, Jim.Hyslop wrote: OK, let's run through a use-case scenario: Scenario: Repository has a file named 'file'. User wants to 'cvs add File'. CVSNT server, Windows client: 'add' command ignored CVSNT server, UNIX client: 'add' command fails: File added independently by second party UNIX server, Windows client: add command ignored UNIX server, UNIX client: add and commit will succeed. In your scenario, it appears to me that the only failure comes with the CVSNT server and UNIX client. In that case, the user knows that there are two separate files file and File in the directory and CVS should be able to add both but it refuses. If I were that user, I would think CVS is broken. In all other cases, cvs add does the right thing, and another user will be able to recreate the sandbox of this user. So, the only problem comes when CVSNT is used as a server. Therefore, use a UNIX server. If you plan on sharing the same files between Windows and unix-like systems, then you have to make sure your filenames are OK on both systems. It doesn't matter if you use CVS to do the sharing, or if you send zipped directories back and forth. That's a problem that is independent of CVS. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: History move?
At 07:29 PM 7/16/2004, Mark Jaffe wrote: As an example, suppose foo/bar.c is at version 1.23, and the author has refactored so that she now wishes the file to become foo/barBase.c. How can the history of foo/bar.c be made part of the new file? http://www.google.com/search?q=rename+file+in+cvs+and+keep+history ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Identifying the user who tagged some files.
At 01:10 PM 7/15/2004, Jorge Godoy wrote: Is it possible to identify the user who added some tag? I might add something at taginfo for that, but I haven't seem an indication that the username was sent as a parameter on tagging operations... Have taginfo execute a script and use $USER ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Changes made to project
At 03:07 PM 7/14/2004, Murrgon wrote: Bascially what I want to do is set up a build machine that can check for changes made to the project Can you use loginfo to send a message or set a flag of some kind on a change? Then the build machine can check for the message/flag and build. You might also want to look at https://www.cvshome.org/docs/manual/cvs-1.12.9/cvs_18.html#SEC179 Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to tell CVS that it should use the proper date/time
At 12:56 PM 7/8/2004, marko wrote: I wonder how CVS can be convinced to set the original date/time of a file at checkin time when I do a checkout! Use the Source! But, really. Do you want to do that? Do you expect to use make? Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: coaxing scientists to use cvs
At 02:01 PM 7/8/2004, Hensley, Jeffrey L ERDC-ITL-MS Contractor wrote: So, my real question is coming (thanks for bearing with me thus far). Is there any way that the working copy directory that is created would be /project or /project2 depending on whether they are checking out the latest version, or using a tag and checking out the older version??? Can you teach them to do something like this: cvs co -d project1 -r v1 project cvs co -d project2 project You could also wrap these in scripts and let them use the scripts. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Do most people checkout read-only and use cvs edit?
At 02:01 PM 7/7/2004, Karr, David wrote: Other SCMs use the strategy that I'm used to as the primary strategy (checkout read-only, and do a specific operation to put the file into edit mode). Not CVS. That C stands for Concurrent. You can find out what that means at http://www.loria.fr/~molli/cvs/doc/cvs-paper.pdf The cvs edit functionality was put in place to help people deal with files that cannot be edited concurrently. Note that there are some people on this list who think very little of that capability. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: binary files bad idea? why?
At 04:09 PM 6/30/2004, Eric Gorr wrote: So, I'm sorry...what can go wrong here? Merging. Start with your test repository. Checkout two different sandboxes. In one, make a change to one part of the NIB, binhex, and commit. In another, make a change to another part of the NIB, binhex, and update. What happens? Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Undoing renaming a directory
At 03:16 AM 6/23/2004, Jean-Christian Imbeault wrote: renamed a directory from src to source What cvs command did the developer use to do this? I didn't think this was possible. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Deleting or disabling a user
At 09:07 AM 6/23/2004, Ramanuj Singh wrote: The information transmitted is intended only for the person or entity to whom it is addressed and may contain confidential and / or privileged Material. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your computer. Thank you for your understanding co-operation. You won't get much help when you put this at the end of your email. ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: $CVSROOT/CVSROOT scripts
At 02:07 PM 6/21/2004, Larry Jones wrote: If you don't care about revision control on the scripts Horrors! Heretic! :-) Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can one user develop concurent versions ?
At 08:16 AM 6/17/2004, Adrian Constantin wrote: I wish cvs not to rely to much on the assumption each user works on exactly one version, one copy. CVS keeps the local state information in the CVS directories in your sandbox. If you have different sandboxes in different states, then that's OK with CVS. CVS makes no assumptions about users and versions. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: strange cvs diff problem with pcl-cvs and viewcvs
At 02:40 AM 6/15/2004, Fabian Braennstroem wrote: The revision 1.10 is currently the last revision for 'main.f'. My problem is, that ViewCVS and PCL-cvs don't show any differences between revision 1.10 and 1.9; they say that there are no differences!? I'm not sure how ViewCVS and PCL-cvs run the diff command, but here's a clue. Suppose you update your sandbox and main.f 1.9 is the version you get. If you run cvs diff main.f you will see that there are no differences. That's to be expected. Someone checks in a revision to main.f, producing version 1.10. Now, if you run that same cvs diff command again, you will still get no differences! That's surprising until you remember that the diff command compares the local file with the version in the repository (1.9) that it's based on. To see the differences between the local file and the head version you need to use the command cvs diff -r HEAD main.f. So, if your tools are using the cvs diff main.f command, then the output you see is correct. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: ci/co on HEAD for specific files in a branch?
At 11:43 AM 6/14/2004, Doug Lee wrote: the HTML document describing the project should not branch but should be a part of all branches along with the code. How about not tagging the html file with the branch tag and always check out or update with the -f (force head version) flag? Would that work? Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs tag checkout
At 02:08 PM 6/14/2004, Khyati Nayak wrote: Is there some way I can specify wild card characters in the rtag command to tag some type of files? On a unix-like system, the wildcards are expanded by the shell using local files. Since rtag is supposed to work without a checked-out sandbox, this could be a problem. Also, rtag requires module names as arguments, not filenames. Wildcards will work with cvs tag for files in the current directory, though. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
scm module in CVS (was Reports generation in CVS)
At 10:04 AM 6/2/2004, Jim.Hyslop wrote: Fred, this sounds very useful. Would you be able to provide a more detailed description of this scm module, and perhaps the scripts as well? I use the scm module (it goes by different names in different projects) to encode the project specific software configuration for the project. The scripts are not general enough to share, and I couldn't share them without going through too many layers of approval. But, I can tell you what they do. First, some background. Sarnoff is a contract research organization involved in lots of technologies besides software. We used to be RCA Laboratories back in the day. We have a wide variety of clients with a lot of different requirements on the use of information. We have to guard customer information so it does not get transmitted to others. We also have to guard our own IP -- software, materials, designs, hardware, algorithms, etc. -- so its ownership is clearly ours. We use repositories on different servers (some belonging to us, some belonging to the client) to isolate ownership of software. A project for a client usually involves combining our IP in ways that fit their requirements. BTW, the reason they hire us is for our unique IP, not our high price. Also, there is no single library or other product (I wish there were) we can produce from our software IP that would fit all of the client needs. That usually means developers need modules from different repositories in their sandbox. So, one script is the makesandbox script that creates a sandbox using modules from multiple repositories. All of the other scripts depend on the structure of this tree. The makesandbox script often also checks for the presence of various third-party modules required by the project. Another script, build builds the software product (or products in some cases) in the current sandbox. It could be just a call to make, but it's usually more complicated than that (damn Windows). The script tag tags all the files in the current sandbox. The script may impose a particular syntax on the tag. A comment is usually a required argument to this script. Various information about the operation is saved in a file and committed to the repository. The scm module is also tagged. Finally, release takes a tag as an argument (and usually a required comment), 1. saves information similar to the tag script, 2. cd's to a directory devoted to creating releases, 3. checks out the scm module into a directory with the name of the tag, 4. runs makesandbox with the tag, 5. sets up the proper environment, and then 6. runs build. All output from the script is redirected to a log file at the top level of the sandbox. This guarantees that a final build is produced from a clean development tree, and that we can easily archive the build environment. The result of this build goes through QA (we don't call it that, but that's what it is) and may be combined with other products before being shipped to the client. If the software is shipped wrapped in some kind of installer, then the creation of the installer is usually in a separate script. This is because commercial installer packages are often licensed to a single person and we don't need to have every developer use the package. Different projects have different wrinkles on these scripts. For example, a project may require both some firmware (compiled on Solaris) and a GUI (compiled on Windows). In that case, there is more than one build and release script. Some steps may not be easily automated. The scm module always has .txt files describing the process required to perform standard actions. I've considered using SCM packages like ClearCase, but the orientation of those packages is to set up a single management policy that is used over a long period of time or over a wide variety of products. The requirements in our environment change so much between clients that CVS+scripts seems a less costly approach. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Reports generation in CVS
At 09:02 AM 6/2/2004, Ramanuj Singh wrote: name of branch or tag, date on which it was created, the author name and the name of the module CVS stores that information in the history file (cvs history -aT). A script that parses the output has to be aware that individual files can be tagged, not just modules. If you need more information than that, then your best bet is to collect the information yourself in a format that is easy for report generation. Write a script that developers will use for tagging. Collect the information you need along with the tag they use. Save the information in a convenient place. Generate your report from that data. One method that I use is to have a special module named scm that contains scripts for tag, release, and other configuration management operations. I teach the developers to use the scripts instead of the raw CVS commands. It's easy to get them to use the scripts if you make the scripts easy to use. The data gets appended to a file within the module and then the file is committed to the repository. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Newbie: update vs. checkout
At 01:31 PM 5/26/2004, Irving Kimura wrote: the difference between update and checkout Checkout creates a brand new sandbox (working directory) from some version of files in the repository. Usually this is the HEAD version, but you can specify others. Update makes the files in an existing sandbox correspond to some version of files in the repository merged with local changes if necessary. Usually this is the HEAD version of some branch, but you can specify others. I think that checkout can act like update (in WinCVS only?) if it is run from an existing sandbox. Ignore that behavior. It's too confusing. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: binary files bad idea? why?
At 10:28 PM 5/21/2004, Greg A. Woods wrote: If this isn't blatantly obvious to everyone who knows that CVS uses It's not blatantly obvious that everyone knows how CVS works. There's a lot of people here who are very smart people and very talented developers but view CVS as a black box. There's nothing wrong with that. But, because they are so smart, they ask questions. If I say Don't do that with CVS, then they ask Why?. If I can't explain it sufficiently, then they won't internalize my prescription and they will eventually do that anyway. We don't have a formal CM group here but I am the de facto expert. At least they are smart enough to ask me before doing something different with CVS. So, I always explain the reasons why one should treat the CVS repository or CVS commands in a certain way. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Check in and out a file.
At 08:03 PM 5/18/2004, Hon Seng Phuah wrote: For example, if five developers check in five different copied of abc.c at very short delay. I expect to check out abc.c file and rename them as abc.c.1, abc.c.2, abc.c.3, abc.c.4 and abc.c.5 respectively in a particular directory. Cvs doesn't have this feature built in. You can do it manually this way: cvs co -p -r 1.1 abc.c abc.c.1 cvs co -p -r 1.2 abc.c abc.c.2 cvs co -p -r 1.3 abc.c abc.c.3 cvs co -p -r 1.4 abc.c abc.c.4 cvs co -p -r 1.5 abc.c abc.c.5 But then, cvs has no recollection of those abc.c.* files so you won't be able to do any cvs operations on them. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Non-build files under CVS control
At 09:43 AM 5/19/2004, bill wrote: What is the best way to arrange things such that, at build time, I can check out only those files that are part of the distribution? Repeat after me: CVS is not a Configuration Management System. Good. Now, here's a couple of ways you can use CVS as part of a CM system. 1. Arrange files in separate cvs modules to separate distributed files from support files. This isn't always possible, though. 2. Use a build process (e.g., make release) that creates a distribution tree from a cvs sandbox. This is the better solution. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Q: commit to new repo?
At 09:18 AM 5/14/2004, kj wrote: Wow! Let me make sure I have this straight: do you mean that instead of doing ... ...(and losing all history info in the process, I suppose) I could simply do this % cp -pr original_repo/myproj new_repo Yup! You're a quick study. You get an A. :-) % rm -rf cvs_repository/project_to_remove ? Would this mess up the rest of cvs_repository in any way? I assume that's $CVSROOT/project_to_remove. It depends. You might have a problem if project_to_remove is part of a module definition in $CVSROOT/CVSROOT/modules. The modules file is, I believe, the only place where CVS creates dependencies on top-level directories in $CVSROOT. Mentioning a non-existent module in the *info files in $CVSROOT/CVSROOT is benign. Of course, deleting a module from the repository means that it's no longer there (Duh!). Don't expect CVS operations in a checked out project_to_remove sandbox to work. But, you knew that, didn't you? Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: Re: WinCvs Python macros]
Jim.Hyslop wrote: Well, let's see. I don't use WinCVS, but my first guess ... At 02:07 PM 5/14/2004, Paul Levin wrote: Are you referring to a different FAQ? You've probably exhausted the knowledge of people on this mailing list. You can find the right mailing list for your question at wincvs.org. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Q: commit to new repo?
At 03:58 PM 5/13/2004, kj wrote: I have a whole bunch of source code that I have been committing to one repository, and now I'm supposed to switch my commits to another (pre-existing) repository (long story). I know that I can just use cvs -d second_repo import, but I'm concerned about losing a lot of valuable revision history when I do this. Is there a way to avoid this information loss? The history of the file joe.java that you have been working on is in a file in the original repository. Do a cvs status joe.java and look on the line Repository revision:. It has the name of the repository file. It ends in the string /joe.java,v. Simply copy the joe.java,v file from the original repository into the correct place in the new repository. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: ignored 'core' directory (was: A newbie question.)
At 09:43 AM 5/10/2004, Jim.Hyslop wrote: I wonder if this could be solved by modifying the behaviour of .cvsignore - if we could tell CVS to ignore *files* named 'core' but not *directories* named 'core', then the problem would go away altogether. We still need a way to ignore directories, though. For example, I don't want to save those Debug and Release directories generated by MS Visual Studio. Perhaps the problem is that there is a built-in cvsignore list. Judging by messages to this mailing list, people seem to be surprised by cvs behavior due to this built-in list more often than behavior due to a CVSROOT/cvsignore list that they added themselves. At 12:23 PM 5/10/2004, Schrum, Allan (Allan) wrote: Such as core for files and core/ for directories? This is a reasonable approach. It doesn't address the surprise issue, but it does allow directories to be ignored. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Personal CVS repository?
At 10:06 AM 5/6/2004, J Krugman wrote: For reasons that I'm not too clear on, my supervisor has instructed me that he must review my code before each submission to the off-site CVS repository, and he wants to do this once a week. My only problem with this is that, even when I am the only programmer in a project, I prefer to keep a finer-grained version control than is possible with weekly submissions to the repository. You didn't say what platform you are using: Windows or Unix(-like). On unix, you can use RCS or SCCS. Either would work in this case. All unix-like systems that I know of come with either RCS or SCCS or both. Good luck with that boss of yours. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: looking for command line interface to CVS
At 06:19 PM 5/3/2004, Paul Levin wrote: I can write the asp or perl web page, but how to I get the WinCVS update functionality from a command line? Download version 1.2 of WinCVS http://prdownloads.sourceforge.net/cvsgui/WinCvs120.zip?download It contains a cvs.exe file. Put it in your PATH and then cd sandboxdirectory cvs update Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: how to checkin binary files
At 08:59 AM 4/23/2004, Gurpreet Singh (SCM) wrote: I have observed that code get from a branch is taking lot of time if compared to that involved in from the Main tree. CVS uses the rcs file format to store files in the repository. The doc/RCSFILES document in the CVS source tree describes how rcs stores versions. Basically, the head of the trunk is stored whole. Previous versions are stored as backward deltas from the head. Branch versions are stored as forward deltas from the branch point. The RCSFILES document contains the following: One common concern about the RCS file format is the fact that to get the head of a branch, one must apply deltas from the head of the trunk to the branchpoint, and then from the branchpoint to the head of the branch. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: strange it is in the way message
At 10:24 AM 4/22/2004, Doug Lee wrote: I've seen this kind of thing when the CVS server is a Unix variant, the client is in Windows, and the client's CVS\entries file contains file names in a different case than the actual names on the Unix host. Could another cause be a server clock that is two seconds ahead of the client? I'm seeing cvs update: move away ; it is in the way messages and the only problem I can find is the lack of time synchronization. This is with WinCVS 1.2 client and CVS 1.11.2 on a Linux box (the administrator hasn't yet taken the time to update to a newer version) using rsh. Thanks, Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: RES: CVS import
How is this the grep command? It doesn't support regular expressions which is kind of the whole point of grep isn't it? If you're lucky (!) enough to have a Windows 2K box handy, type help findstr in a DOS window. You'll see that it does support regular expressions. However, the way the strings argument is documented, I think that they're better described as irregular expressions. :-) Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CTRL-M and CTRL-J characters in files
At 02:31 PM 3/24/2004, Steve deRosier wrote: 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. You might also want to make sure that the files are not defined as binary. cvs status will show something like Sticky Options: -kb for binary files. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
loginfo and RSS feeds
Has anyone setup loginfo to produce an RSS feed? http://blogs.law.harvard.edu/tech/rss It seems that this might be a good alternative to using mail for notifying developers of changes in the repository. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [OFT] scripting removal of $Id:
At 10:57 AM 2/20/2004, Euan Guttridge wrote: Has anybody come across a shell script to parse a large number of text files, removing the CVS keyword replacement lines (all containing $Id:)? For example input: package com.shop.backoffice; import javax.servlet.http.HttpServletRequest; /** * Test class for blah * $Id: blah.java,v 1.2.2.3 2004/01/21 10:03:04 jwilson Exp $ */ If you have access to the repository, then you can use cvs export. It will turn that Id line into * Id: blah.java,v 1.2.2.3 2004/01/21 10:03:04 jwilson Exp (the $ characters are removed) There's also a -k switch (check the manual) you can use with cvs update(?) or checkout that would leave it * $Id$ Of course, if this is third party source, then you need a script. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to keep track of revisions of files based on another file?
At 09:54 AM 2/19/2004, Phil Labonte wrote: if I want to check out a previous version of one of the files how could I check out the corresponding versions of the other files Look at cvs tag ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: how to support symlinks?
At 05:27 PM 2/18/2004, Frederic Brehm wrote: Perhaps it is really, really simple: cat .symlinks | xargs ln -s I should never do this just before leaving for home. :-( That won't work. This has a better chance #! /bin/bash for file in $(cat .symlinks); do ln -s $file . done The rest is left as an exercise for the reader. Good night, Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: how to support symlinks?
At 04:58 PM 2/18/2004, Eric Siegerman wrote: a simple mechanism has been implemented Perhaps it is really, really simple: cat .symlinks | xargs ln -s Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Build Automation Issues
At 02:47 PM 2/16/2004, Dhruva B. Reddy wrote: I was hoping to conditionally tag each module, by checking the exit status of cvs diff -r tag_from_last_build, but it seems to return 1 even when there are no differences (I tried cvs diff, and it returned zero--which makes sense because I hadn't edited any files). Tags are cheap. Just tag everything. If you don't then you'll have problems checking out or exporting all the files you will need to build. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Help and info on line endings
At 10:58 AM 1/28/2004, Les Spam wrote: We have been having trouble with line endings because we check out files on a Linux server and zip them up for download by users who do not have CVS clients. Win9x users end up with line oriented text files that do not parse because the scanner sees one long line. Why don't you check them out on a Windows client? ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: what's to stop a developer from nuking the repository?
At 04:15 AM 1/20/2004, Andy Jones wrote: am I right in thinking that Greg's opinion does not reflect the majority view? No. And besides, Greg is one of the resident experts on CVS. Listen to him. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: automatic checkout
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? http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_18.html#SEC173 ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Deploying?
I wanted to know what exactly is meant by deploying software. I work in a project being developed in C (for Windows and Linux platforms) and we use CVS for version control. Can we use CVS for deploying? By deploying I assume you mean creating a product and shipping it to customers or users. As far as CVS is concerned, you would tag the files that will be used to create the product and then export (or checkout if you prefer) those files. After that, CVS is done and it's up to your other tools and processes. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ^M Characters - files in dos format
Lots and lots of people keep asking: Is there any way to detect files in dos format during check-in. and I'm tired of it. So, here's the solution The script pasted below should do the trick. I cut it down from a larger one that has more options, so try it first. The comments should tell you what's going on. I would be very happy if someone could put this into the CVS FAQ, the CVS contrib directory, and anywhere else that people who are looking for this solution can find it. Fred - Cut here - #! /bin/sh # SUMMARY # # cvs-no-cr # # A cvs commitinfo script to prevent files containing # carriage return characters from getting into the # repository. This script may not work for files # with spaces in their names without modification. # AUTHOR # # Frederic W. Brehm, [EMAIL PROTECTED] # COPYRIGHT # # None claimed. This script is free to use as you see fit. # INSTALLATION # # 1. Replace the ^M in the grep command below with a real carriage return. # 2. Change the error message to meet your local conventions. # 3. Put this script into $CVSROOT/CVSROOT. # USAGE # # Suppose you want to prevent all *.c and *.h files in module A # from being checked if they contain a carrage return. Put the following # line in commitinfo (without the leading #, of course). # # A $CVSROOT/CVSROOT/cvs-no-cr \.h$,\.c$ ### # the first argument should be the comma-separated pattern for the files # to check. The patterns are used in a grep command. PATTERN=`echo $1 | sed -e 's/,/ /g'` shift # the second argument, supplied by cvs, is the path to the repository. REPOSITORY=$1 shift # subsequent arguments supplied by cvs are file names. Ignore missing ones. OK=true for FILE in $*; do if test -f $FILE; then for P in $PATTERN; do if echo $FILE | grep -s $P; then # N.B. be sure to fix the next line before installing. See above. if grep -is '^M$' $FILE; then echo echo ERROR: $FILE contains a carriage return character. echo OK=false fi fi fi done fi done if $OK; then exit 0 fi exit 1 - Cut here - ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: additional fields
At 06:30 AM 6/18/2003, Patrick Kennedy wrote: Is it possible to add custom fields to the repository? No. But CVS is open source so you can extend it yourself if you are inclined. I want to attach some meta data (eg: description, synopsis etc) to files in the repository, If you want to keep metadata about files you can add a file (metadata.txt or something) that and keep the information in there. It's not ideal but periodic review can catch problems. Secondly, can the revision field by a string or does it need to be an auto-incrementing number? Don't mess with the revision number (1.n). That's the property of CVS. Use tags (cvs tag). They can be strings, subject to certain restrictions. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Using dos2unix on commit???
At 11:47 AM 6/13/2003, Andy Kriger wrote: I am trying to setup our Unix-based CVS repository to run dos2unix when files are committed, but I'm not having much luck and don't see any solution laid out clearly in the mailing lists. Don't attempt to use a commitinfo script to change a file being checked in. It won't work. So I thought that dos2unix would get the path combined with filename as an argument. man dos2unix Does anyone have an example of this that does work? Sorry, no. Here's some suggestions, though. 1. Write a script that greps for CRLF in a file. Print an informative error message telling the user to run dos2unix on the offending files, and then have the script return false (not zero). Use this script in commitinfo. You will have to read the documentation about commitinfo again CAREFULLY because the arguments passed to the script are not what you think. Use DEFAULT echo to experiment, and be sure to cvs add a new directory when you experiment. 2. If you are checking in from Windows, then use the correct cvs client. If you are using Cygwin with the default text type of Unix, then you will have to use a different cvs client. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Using dos2unix on commit???
At 03:25 PM 6/13/2003, Andy Kriger wrote: As background, what is prompting this need is multiple developers with different IDEs making connections to CVS. Since there's no way to be sure what line format is being used, I'm looking for consistency. Good luck. The way to decrease the chances of line ending problems is to use a CVS client that always uses the local system native text format. All editors that I am familiar with that are multilingual with respect to line ending formats will preserve the original format of the file by default. A reasonable IDE will create text files in the local system native format. If an IDE gives you a choice for line endings, always choose the local system native format. Watch out for users who checkout on one system and edit the files on another system using a cross-mounted file system. Also watch out for editors or IDE's that insist on doing text the one true way that's different from the local system native format. I can't think of any of those, but maybe you know of some. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
At 10:08 AM 6/5/2003, Larry Jones wrote: There's nothing I hate more than software that thinks it knows more than I do and refuses to let me do what I want to do. The principal of least surprises should be Commandment #1 of the Software Engineers Ten Commandments (requirements for the other nine are still being collected :-) I agree that cvs add does just what it should do, but I can understand the desire for a cvs add-with-ignore command. It wouldn't be too hard to write a shell script cvs-my-add that trimmed the list of files on the command line based on the contents of ./.cvsignore and called cvs add. In order to get the build-in list and the $(CVSROOT)/CVSROOT/cvsignore list, you would have to do ugly things in a shell script, or build a new command into cvs. The current list of CVS maintainers does not seem to have the inclination to do this. Hey, it's Open Source. If you want it bad enough, you can add it. If you make it a separate command (or possibly enabled with a special option to add), then there's a chance it might be accepted by the current maintainers for the next release. I think that there's some file named Hacking or something like that which has requirements for getting something into cvs. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Removing sticky tag 'HEAD' in cvs
At 01:14 PM 6/4/2003, Eric Siegerman wrote: Occasionally one might want a sticky tag on HEAD -- probably not for an entire sandbox, but for a file or two. This came up a couple of months ago: http://mail.gnu.org/archive/html/info-cvs/2003-04/msg00023.html (The only reason I didn't suggest typing exactly -r HEAD is that I didn't think of it at the time...) Hmmm. Let me see if I understand this. Typing the command cvs update -r HEAD file.c will cause the following behavior (until the sticky tag is changed): 1. Updating file.c from the repository will always work. 2. Committing a changed file.c to the repository will never work. So, how would I use it? For example, suppose I need to add some temporary code to a file for debugging or to make some kind of measurement. If I update -r HEAD then I can prevent the temporary code from accidently polluting the repository. When I'm done, remove the file and update -A (assuming there were no changes of value in the file). Sweet! Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs commit behavior
At 10:25 AM 3/7/2003, you wrote: I was thinking the file itself would get updated, not just the ,v file. If the file is in $CVSROOT/CVSROOT, then you need to put the name of the file in $CVSROOT/CVSROOT/checkoutlist. See http://www.cvshome.org/docs/manual/cvs_18.html#SEC176 If the file is in some other module of the repository, then the ,v file in the repository is what gets updated. The file in your sandbox doesn't change unless you have one of the RCS keywords in it. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: security question
At 10:51 AM 12/12/2002, Phil R Lawrence wrote: Now, about security. We would be a multi-client shop, so I need SSH to encrypt sign-on info. Also, to make auditors very happy, we need to grant and deny write security to various projects in the repository. We are a multi-client shop, too. We use a combination of group membership explained in http://www.cvshome.org/docs/manual/cvs_2.html#SEC13 and completely separate repository roots. A loginfo script runs to insure that permissions are correct after every commit. Every commercial client gets their very own separate repository. Government unclassified clients may or may not share modules within a repository depending on the nature of the projects. Our own proprietary software has its own set of repositories. We use multiple repositories to make it easier to audit where things came from. It's also easier to archive all of the software that goes with a single client when all of the software is under a CVSROOT unique to that client. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Adding maillog.pl script to checkoutlist causes it to loose permissions
At 11:06 AM 11/7/2002, Brian Kowald wrote: I have added a perl script to checkoutlist in CVSROOT. When its extracted, it does not have the execute permission. Is there a way to get ot to extract with the execute permission, or would I have to have a script triggered off of somewhere to modify the permissions after its extracted? chmod +x $CVSROOT/CVSROOT/maillog.pl,v Then delete the file in your sandbox and cvs update. It should now be executable. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: erasing history
At 03:08 PM 10/25/2002, [EMAIL PROTECTED] wrote: Suppose I was experimenting with a few cvs features and later wanted to delete any record of my checkins and updates etc. ... Is this everything? Is there a better way? Make a private repository with just the module you are interested in and blow the whole thing away when you are done. That way there's no chance you will accidently mess up your production repository. For example, if you want to experiment with features on the foo module... mkdir temproot cp -r $CVSROOT/CVSROOT deleteme cp -r $CVSROOT/foo deleteme setenv CVSROOT `pwd`/deleteme cvs co foo CVSROOT ... hack away ... rm -rf deleteme Note that if someone was updating foo or CVSROOT while you were copying, then you might get some weirdness, but you can recover by starting over. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problems with Attic permissions
At 01:49 PM 10/14/2002, Anne McCaffrey wrote: To implement additional security, I have made all Attic directories in the repository read only ... but today when a developer tried to add a new file,cvs add was aborted with the error,Cannot read Attic directory.Permission denied. Only when I gave permissions to Attic in that directory,cvs add succeeded. Was the developer was adding a file to a branch? CVS puts those files in the Attic. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvswrappers questions
At 08:13 PM 10/2/2002, Ken Williams wrote: Use your build system (make?) to fix the type/creator codes. I'm not using a build system. I'm just sharing project data. This file is a database that the people working on this project need to access. We each update it often, potentially, so we use 'cvs watch on' and 'cvs edit' to manage concurrency. In this way CVS is a good tool for sharing it, *except* for the fact that the file breaks every time we do updates. How about making a simple two line script that performs the update and then fixes the type/creator codes? It shouldn't be hard to get other people on the project to use the script since it will make their life easier. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvswrappers questions
At 06:04 AM 10/2/2002, Ken Williams wrote: Original problem: I have a binary file that I'd like to store in CVS. It's a file used on Mac OS X, and needs to have type/creator codes set properly in the filesystem. These codes don't survive a pass through the CVS repository (they are empty when the file is checked out). Use your build system (make?) to fix the type/creator codes. Second problem: now my CVSROOT/cvswrappers file is unusable because of the above error, and I can't commit changes in order to fix it - because of the same error. How can I fix it if I can't commit changes? When something like this happens to me, I resort to brute force (a.k.a. CVS voodoo). Replace the file $CVSROOT/CVSROOT/cvswrappers with the fixed version. Then commit your changes. You'll need direct access to the repository files to do this. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs import of (symbolically) linked files
At 10:32 AM 10/1/2002, Jayashree wrote: Can I cvs import symbolically linked directories or linked files in a directory? No. At least it shouldn't. I haven't tried to do that. Maybe you'll get the linked file or directory in the repository, but you won't get a link. CVS does not manage symbolic links. If you really need symbolic links then you will have to use your build system to create them. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and permissions (Unix)
At 12:57 PM 9/27/2002, Mullican, Catherine wrote: Some files were checked in with the permissions set to 644. They need to be 755. I tried changing the permissions, making some whitespace changes, and checking the files back in, but they're still 644 on checkout. Other files in the project have the correct permissions on checkout; this only affects two directories. How can I fix them? You need to set the execute bit on the ,v files in the repository. Don't worry about the fact that the ,v files do not have the write bit set. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout multiple tags
I suppose that I could change the process so that we tag everything, Yes, you should. CVS tags do not identify change sets. CVS tags identify versions. for every patch but then how can I easily know what was actually changed in this particular tag. Use two tags: one tag on everything to identify the version, and another on just the files that were changed. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Including file version during checkout
You can use the keyword $Revision$ as explained in cederqvist (§12). Though I've read unhappy comments about this feature in this list. I don't remember many unhappy comments about $Rev$ or its cousins $Id$ and $Name$. There are many reasons to avoid $Log$, though. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Newbie question : common/shared objects
At 10:15 AM 9/26/2002, Jay Yarbrough wrote: To build release 2.1 of Product Y, I will use release 3.4 of product A, release 5.3 of product B, and release 2.0 of product D. How is this typically handled within CVS? Make each product a separate module. Then you can tag each release of each product and export them independently. Here's a way to build your product Y: Keep each released version of every product in some well-known place. This goes for third party products as well as your internal products. For example, build release 3.4 of product A and put it in /company/product/V3_4/A.zip or something like that. To create a release of product Y, your build procedure can use the released versions of the products it depends on. There doesn't have to be a distinction here between your internal products and third party products because they are all referenced in a similar manner. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Sharing files across directories
At 02:33 PM 9/25/2002, Matt Lyon wrote: Is there a way to share a single source file across multiple directories in CVS, so that if it gets committed/merged in one directory the update registers in both locations? I know that VSS has this concept, and was wondering if CVS offers any sort of similar functionality. I was thinking that perhaps this could be achieved with some symlink trickery on the server-side? At 03:05 PM 9/25/2002, Douglas Finkle wrote: Yeah, this is possible using Ampersand modules. See Actually, Ampersand modules share whole directories, not single files. CVS has no built-in way to share a single file across multiple directories. I suppose that you could share a single file by putting it in its own directory and using ampersand modules. It might be easier to collect all of your shared files into a single directory and make it into some kind of library (object modules, include files, whatever) module. You would have to adjust your build system appropriately. Don't use symlinks in your repository. They may sometimes when the phase of the moon is right work for directories, but you don't want to deal with the sometimes part. Symlinking files is a way to suffer much pain and agony. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Issues with network file systems and CVS
At 08:01 PM 9/17/2002, Adam Bregenzer wrote: AFIAK the issue is not with where the working copy is stored, as long as you are the only one accessing the working copy. The issue is where the repository is stored/accessed from. That's correct. I misunderstood the original question and thought it had to do with how the repository was accessed. Letting CVS touch a repository mounted on a network filesystem is a bad idea. Using client-server CVS where the server accesses the repository through a local interface is the recommended method. The diagram by Alan Dayley shows the recommended method. Where you put your sandbox is a different matter. For performance reasons (I/O throughput during compiles and network traffic) you might want to put it on a local disk. Policy makers don't always understand performance issues, though. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Issues with network file systems and CVS
At 02:57 PM 9/17/2002, Matthew Navarre wrote: Could someone explain to me the issues with mounting the repo via a network filesystem? Here's what happened to us: a file was corrupted and we could not recover older versions. (Our backup administrator failed to verify that the backup system was in fact backing up the disk.) It delayed our development for nearly a day while we tried to recover. Do you want something like this to happen when a deadline is looming? Even if your backup system is good? I thought not! Use client-server CVS. The technical reason for the failure has to do with locking in the repository. Locking is a tricky thing to do in a distributed system. Implementations often have subtle bugs. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Issues with network file systems and CVS
At 04:10 PM 9/17/2002, Matthew Navarre wrote: That's why I'm basically collecting ammo. They want us to use wincvs with a SMB mounted repo. Since I use FreeBSD this presents something of a problem. Bad, bad, very bad idea. I hope you have enough ammo, now. Have a CVS server running on the same _physical_ system that has the disk drives with the repository. Use CVS clients (e.g., WinCvs on Windows, cvs on FreeBSD) to operate on the repository. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Issues with network file systems and CVS
At 04:54 PM 9/17/2002, Larry Jones wrote: Frederic Brehm writes: The technical reason for the failure has to do with locking in the repository. Locking is a tricky thing to do in a distributed system. Implementations often have subtle bugs. A number of people have now said that and, while it may be true, it doesn't apply to CVS. CVS's locking scheme ensures that only one process is writing to a repository directory at a time, even across network filesystems. The only known potential failure mode, which has never been reported as actually occurring, results in *eveyone* being locked out of a directory, not allowing two servers to write at the same time. But, isn't a network filesystem a distributed system? I wasn't referring to CVS by itself as a distributed system with the bug. It's the distributed filesystem that CVS uses where the bugs are. No, the problem is just that network filesystems, particularly those that run over unreliable connections like NFS traditionally does, are extremely tricky to get right. They're even trickier when you don't control both ends of the connection, as when the client software is supplied by a different vendor than the server software. All the problems I've seen seem to be either handshaking bugs -- where the client and the server don't communicate reliably -- or simple housekeeping bugs in the server -- where data intended for the disk never actually gets there. Why CVS should be so good at triggering these problems, I don't know. I do know that the commercial CAD/CAM/CAE system my employer produces is also good at triggering them, though. Yup. We agree. It's the filesystem. I suppose that we could get into a semantic argument where we quibble over whether CVS+NFS is an example of a distributed system. But, let's not go there. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout without modifying the Entries file
At 01:58 AM 9/13/2002, Matthew Herrmann wrote: cvs co proj cd proj release PROJ_V_1_1_1 which does: cvs co -rPROJ_V_1_1_1 -d%TEMP%\proj_temp cd %TEMP%\proj_temp build the problem is that since the checkout happened inside the project folder, the temp directory gets added to the entries folder and cvs tries to update the temp folder whenever the project folder gets updated. Maybe, cd to the temp folder (outside the project folder) before the cvs command? You'll have to set CVSROOT for the command, though. In Unix, you would do something like this: CVSROOT=`cat CVS/Root` export CVSROOT cd $TEMP cvs co -r$TAG -d proj_temp In Windows...well, maybe you can use cygwin. i'd rather not use cvs export because i like the idea of the release script updating version numbers based on the sticky tag. I'm not sure what you mean by this. You can do something similar (I think) by using $Name$ with cvs export. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: branch access control
At 01:06 PM 9/3/2002, Douglas Finkle wrote: Yes, you're right... you can use either of the two methods mentioned, 'cvs status', or the Entries file. Still, both of these methods are client side and their success depends upon software (e.g. Perl) that may or may not be present on client machines. The script named in commitinfo executes on the server side. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: branch access control
At 01:33 PM 9/3/2002, Douglas Finkle wrote: At 01:06 PM 9/3/2002, Douglas Finkle wrote: Yes, you're right... you can use either of the two methods mentioned, 'cvs status', or the Entries file. Still, both of these methods are client side and their success depends upon software (e.g. Perl) that may or may not be present on client machines. The script named in commitinfo executes on the server side. Sure, but what about the data that the script looks at? On the server side of things there is no CVS/Entries file, and 'cvs status' will fail if there's no checked out sources. Somebody said: The commitinfo script is running in a directory where the files given on the command line reside as local files. There is also a copy of the CVS directory present and the CVS/Entries file contains the branch information if you want to parse it. There are two ways you could get that information. I believe that is a true statement for both client/server and local modes. ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: make cvs text agnostic?
At 09:58 PM 8/28/2002, Matthew Herrmann wrote: re this conversation of file types -- why autodetect them, isn't that the whole point of a file type, given in every file's extension? heuristic detection of binariness -- yuck! Exactly! a mechanism already exists to tell with this problem -- why don't people just make a whopper of a cvswrappers file and then be done with it? I assume that you are talking about filename extensions on a Microsoft operating system. That mechanism isn't very reliable. Quick, what kind of file is a .dat? You may have local shop procedures that define the type of all files you deal with and give them unique filename extensions that are enforced in some way by your culture. That's fine. You can now make a whopping cvswrappers file and be done with it. Try taking your cvswrappers file to a different shop, especially one that uses a variant of Unix, and see what happens. I'll avoid the rant about overloading filenames with semantic information about the contents of the file. That discussion doesn't belong here. CVS is nice because it doesn't try to enforce that particular way of using filenames on shops that do not or cannot use it. It does, however, provide a mechanism (cvswrappers) to allow you to do it in your shop, though. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Error while opening a zip file in Wincvs
At 10:35 AM 8/28/2002, Jayashree wrote: I am using Wincvs1.1 version. I tried to checkout a x.zip file into my local directory. But I get an error when I try to open the zip file. Please note that in Linux I am able to co and open the zip file without any problem. Why is it giving error in Wincvs?Could somebody help me ! This could be because the zip file has not been marked as binary. Try cvs status x.zip. You should see Sticky Options: -kb. If you don't then you have to go to your linux box and tell CVS that the file is binary. Do it on the linux box, not on the windows box where the file is corrupted! I'm not sure of the exact command, but it is something like cvs admin -kb x.zip Someone will probably correct me if I am wrong. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: a question about defining modules
At 04:04 AM 8/27/2002, Isaac Claymore wrote: My situation is: 3 projects, A, B and C, share a common library X. They all need to make changes to libX, so I forked 3 branches from libX main trunk: branch-A, branch-B and branch-C. Any hint or suggestion is greatly appreciated ;) Clay, CVS doesn't work very well as a configuration management tool. Use CVS to save your source code. Use something else (configure, perhaps) to configure the source to match the needs of the product during a build. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: make cvs text agnostic?
At 06:59 AM 8/27/2002, Matthew Hannigan wrote: I've been lurking on the list for a while, and have noticed that many of the questions seem to hinge on text files and storing and extracting them the right way for your platform. The CVS clients already do this. The problem comes when people use a file system cross mounted on several different kinds of OS, checkout on one OS, and then edit and commit on another OS. Autodetection of binary There are enough times when autodetection gets the wrong answer that many people on this list will vigorously oppose having CVS doing this automagically. You can always write a script for yourself that will autodetect and do a cvs add -b or cvs add as appropriate. I personally would suggest a manual confirmation step for each file, unless you are really 100% sure that your script always gets the right answer. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: make cvs text agnostic?
At 09:20 AM 8/27/2002, Matthew Hannigan wrote: JH: This is exactly how CVS works now, except that the format used in the repo is fixed to be the unixish text file format. Disclaimer about the CVS NT server: this may or may not be true...I don't know. Even when the client and server are Windows? If so then CVS does do some automagic detection? No, it just defaults to text mode. If you want CVS to keep the bytes in a file exactly the same on all systems then you have to tell CVS that the file is binary. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Make cvs ignore some changes in files
From: Christian Andersson [mailto:[EMAIL PROTECTED]] the problem I have is that these files often gets generated when there is nothing changed to them (it is part of some compilation sections) what happens is that I get new generated files that has only one difference, a remark in the file telling when it was generated.. From: Riechers, Matthew W Again, why does something generated by a build need to be revision controlled? The generated files don't need to be revision controlled, but they need to be available to people or tools who cannot run the tool that generates the files. The most convenient way to make the files available is to put them into the repository alongside the other files that are also needed. The side effect of this is that the files become revision controlled. I have a similar need where a tool from a real-time OS vendor generates a makefile that has embedded path information. Compiling and linking don't require the tool if the makefile is available, but the path information has to be adjusted if the base directory is different. The vendor tool (a project builder GUI) does not work well in an automated build script. Therefore, the automated build scripts that I use for creating a release requires the generated makefile, but appropriately modified. My solution was to write a simple program (sed did the job well) that changed the generated makefile into a canonical form. I store the canonical form in the repository under a different name: Makefile.cache. The build procedure manages the local makefile. - If the local makefile does not exist, then the build procedure creates it from Makefile.cache and updates the date of the local copy of Makefile.cache (with touch). - If the local makefile has changed (test that it is newer than Makefile.cache), then the procedure creates the canonical form and compares it to Makefile.cache (with cmp). --- If the two files are the same then the date of the local copy of Makefile.cache is updated (with touch). --- If these are different, then Makefile.cache is replaced with the new version. The next cvs commit will commit the new Makefile.cache along with any new or changed source files. Fred _ Fred Brehm, Sarnoff Corporation, [EMAIL PROTECTED] http://www.sarnoff.com/digital_video_informatics/vision_technology/index.asp ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Make cvs ignore some changes in files
From: Riechers, Matthew W Again, why does something generated by a build need to be revision controlled? I wrote: The generated files don't need to be revision controlled, but they need to be available to people or tools who cannot run the tool that generates the files. The most convenient way to make the files available is to put them into the repository alongside the other files that are also needed. The side effect of this is that the files become revision controlled. but then I wrote: --- If these are different, then Makefile.cache is replaced with the new version. The next cvs commit will commit the new Makefile.cache along with any new or changed source files. I just realized that this explains why, in this case, the files *must* be revision controlled. The new version of Makefile.cache corresponds to the new versions of the other files in the directory. Fred _ Fred Brehm, Sarnoff Corporation, [EMAIL PROTECTED] http://www.sarnoff.com/digital_video_informatics/vision_technology/index.asp ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Make cvs ignore some changes in files
At 07:06 AM 8/22/2002 -0700, Noel Yap wrote: Have you tried: 1. Version control the generated file. Yes, I version control a canonical form of the generated file. 2. Build the generated file if the necessary tools are available. The tool does this without asking when it is run. It's a GUI, though, so it doesn't run in an automated (no manual intervention) build. 3. Copy the generated file to a place where the rest of the build will use them. A simple copy won't work. The file has to be version controlled with the other files in the directory. See my previous message. Fred _ Fred Brehm, Sarnoff Corporation, [EMAIL PROTECTED] http://www.sarnoff.com/digital_video_informatics/vision_technology/index.asp ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
