Re: Locking CVS
S I wrote: Hi everyone, I'm planning to lock cvs today getting ready for our release. I realize with certain version control software nowadays you don't have to lock the repo and the developers can continue with their work. However, we're imposing and enforcing a few days for freeze and to regroup. Our repository resides on a linux box with :pserver method access from WinXP CVS DOS and Tortoise clients. Could I just lock the repo by executing cvs admin -l or -L or do I have to download some perl module to accomplish this? I need to lock our CVS repository today. Three projects reside in the repository, is it possible to lock them selectively or would admin -l lock the entire repo? If you want to lock all projects, then create an empty $CVSROOT/CVSROOT/writers file. I believe this will work for all access methods, not just pserver. Unlocking the repository is a simple matter of deleting the file. See https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC36 for details. To selectively lock projects, have a look at the cvs_acls script. It's in the source code distribution (available from www.cvshome.org) in the contrib/ directory. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How can I administratively freeze a branch?
[EMAIL PROTECTED] wrote: Why not just cvs rm all the files from it, so they no longer exist at the head of the branch? People would have to accidentally checkout old revisions before they could accidentally commit to it; that's pretty improbable I think. The problem is that files from old branch still exist in HEAD (in fact, what we did was to commit the branched files to HEAD). I don't understand your objection. 'cvs remove' on a branch will declare the tip of the branch dead, thereby preventing anyone from checking anything into the branch. It's exactly what you want to do. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smart CVS
Liquidchild wrote: I posted on here recently with regards to using SSH and SmartCvs, I have (i think) made a little head way in this but when trying to get the modules to read from smartCVS checkout project option i am getting the following: An i/o error occured, details: Unknown Compression method Turn off compression. There should be a checkbox on the check-in dialog for compression. There are known issues with compression on some versions of the CVS server. p.s. would have posted this on the smartCVS form but my company firewall blocks it! subscribe via email. Send an email to [EMAIL PROTECTED] Messages to the group can be sent to [EMAIL PROTECTED] once you're subscribed. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Undesirable Watch/Edit Behavior
[EMAIL PROTECTED] wrote: I've set up a CVS module with cvs watch on so that users have to use cvs edit to reserve files for editing. This works fine for serial editing of unmergeable binary files files. When users try to edit files already marked for editing by someone else they are told the file is unavailable for editing as expected. The problem that I've encountered is that if a user subsequently checks out the same module again to a different location (i.e. two different sandboxes for the same module) CVS forgets about any files that user marked for editing before the second checkout. Is this behavior by design or a bug? I'm using CVS version 1.11.1p1 on a Linux server? That's pretty much by design. Each checkout is completely independent of any other checkouts, and CVS does not make any attempt to coordinate between multiple checkouts. Thus, CVS has not forgotten anything - if your users go back to the first directory, they'll find that it is currently Edited by them. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: migration of CVS repositery from one machine to another
ravish agarwal wrote: Does that mean that by only copying the files of the repositery after installing the new version of CVS will do the needful. all the history-details will remain there.? also Is there any possilble version upgrade related issues. Please Help me out. As Todd Dennison wrote earlier in the thread, this is covered in the manual. Yes, that's all you need to do. There should be no other version upgrade issues. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Undesirable Watch/Edit Behavior
Todd Foster wrote: I am not sure I agree with that. The act of doing a fresh checkout of that file (either via a new checkout or update -C or what-not) makes CVS forget that you are editing that file. cvs editors no longer returns you as an editor of that file (regardless of where you run it from - either the first or the second directory). Personally, I consider that a bug. I believe I have even seen a patch submitted to change this behavior thought I don't remember what the patch did. Yes, I'd forgotten about that bug and patch - thanks for the reminder. I just checked the NEWS file, and it doesn't look like the patch has been released yet. My apologies for the misinformation. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to control the current version of CVSROOT/modules ?
[EMAIL PROTECTED] wrote: Hi. Is it possible to roll back the version of the currently used CVSROOT/modules file? Say that a product rev. A is built using Ampersand modules. Say that the product is updated to rev. B, and that the Ampersand modules is changed causing a change in the CVSROOT/modules file. If I would want to roll back to rev. A, I would have to restore the previous version of the CVSROOT/modules file, to ensure that the Ampersand modules are defined correctly. Unfortunately, yes, that's what you'll have to do. CVS's configuration management support in this respect is rather lacking. For maximum control, you could use a makefile or a script in the project itself, which checks out the required sub-modules. An advantage of this approach is that your script/makefile can specify exactly which tag to retrieve - you can't do that with ampersand modules. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Help Required in CVS
Hemant Thakre wrote: 2) Another problem which I'm facing after upgradation is *CVS Time stamping problem. *When I checkin or commit any file to cvs server. It shows diff. time stamp for checked in file which is around six hours less than current time. We use ntp for time synchronisation in our premises. So all the workstations and servers are having exactly same time (GMT IST). I dont know from where CVS is picking up this time. Please let me know any solution if somebody came across these kinda problem. Thanks in Advance CVS always stores files using UTC. UTC is, IIRC, the default time displayed for the 'cvs log' command. Which time zone are you in, and which time zone do your PCs show? Can you provide copy-and-paste examples of the time output that you're getting, and indicate what you were expecting to see? -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS-Directories disappear when uploading per SFTP-Client
Dennis von Ferenczy wrote: Yes. Get a CVS client for your local machine and do your cvs commits from there behind the IDE's back. On the CVS server == web server, use the loginfo hook to keep a reference sandbox up to date, from which the web site operates. https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC158 Thanks for your advice. But what will be the advantage? If I get you right, then I would have to do a commit every time I want to test the changes in my scripts, even if I have changed only a single line of code - and even if the code is buggy. Right now I work locally, have the files mirrored using SSH (I'm not sure if cvs can use SSH) can immediately try my changes and if everything works as desired I do a commit. Like this I can always be sure, that code in the repository is actually code that is working correctly. It sounds like you use your production environment for testing. Good configuration management practises dictate that you should never do that. Configure your local machine to behave the same way as the production machine. Test on your local machine. If you do not do this, then sooner or later you *will* crash your production machine. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: query
Russ Sherk wrote: You are correct Jim. It should be used together with other metrics to aid in determining the general health of a particular load or to see general trends. E.g. we used to parse the logs between builds and generate a list of changed files grouped by log entry and PR #. It provided a snapshot of the changes that was easy to scan. (You could see what changed, how much changed etc.) This was particularly useful for TV. Now _that_ sounds like useful information. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: login cvs from Linux on windows directory
Travos Xavier wrote: Hy all, I am using cvs from a linux platform and the cvs directory is on a server. My problem is that the cvs directory for the server in on a windows host D:\CVS. How to login ? Im doing :pserver:[EMAIL PROTECTED]: because it is not linux directory /usr/cvs for example. Sounds like your server is CVSNT. I _think_ the syntax is something like :pserver:[EMAIL PROTECTED]://D/CVS/ - poke around the cvsnt.com web site for details. If that doesn't work, you could always try the CVSNT client - it has been back-ported to UNIX. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: migration of CVS repositery from one machine to another
Todd Denniston wrote: [...] moving a repo is covered in the manual[1]. basically: 0) get everyone to do a final checkin and then release their sandboxes (mainly prevent confusion later). 1) Back up the repository [2]. 2) take the backup to the other machine. 3) restore from backup. 4) configure the machine to serve cvs. 4a) test the configuration, including all scripts. 5) update everyone's CVSROOT values. There is, of course, the possibility that someone might forget that the migration is happening, and check in a change to the old repository while the migration is in process. To eliminate this possibility, just create an empty file named CVSROOT/writers between steps 0 and 1. This also adds step 6: delete CVSROOT/writers file. Step 5 is actually a rather difficult task. In order to make future migrations easier, I recommend that your server's actual machine name is *not* the one that is published to the users. Instead, set up an alias, which your system's DNS resolves to the actual server. That way, you can eliminate step (5) in all future migrations. IOW, set up an alias in your DNS entries, called cvs.yourcompany.com. A DNS lookup resolves cvs.yourcompany.com to the actual machine. Then, in future migrations, you simply perform all the steps above, except step 5 now becomes: Change DNS entries to point to the new machine. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Working on sources in parallel
Paul Sander wrote: CVS notices the conflicting changes and produces a working copy of the file that contains Person1's removed lines and Person2's inserted lines, with special mark-ups to draw attention to the problem. It also leaves copies of both contributors in the user's workspace. Not quite. CVS will only rename your working copy to .#[filename].[cvs revision]. To see the other person's contributions you need to use 'cvs diff' on the pre- and post-modification revisions. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: query
Hridyesh Pant wrote: Hi All, Is there any way to find out how much liles added or removed in a file between two dates. [note: please choose more descriptive subject lines. query is rather vague.] Not easily, no. Between one revision and the next is quite simple - just look at the output of 'cvs log'. I'm curious - what use could this information possibly be, anyway? -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Repository Access
S I wrote: Hi Class! Currently our CVS repo has 3 main separate projects running under it. By default when I create a new unix user; I give them access to the whole repository, however, some folks have been editing files in projects they were not supposed to. How can I ONLY and specifically create or modify the access rights privileges of only few specific people w/o wreaking havoc on the whole repository? And by default if they're not listed in that file then that means they have access to all projs? Is there a way? Use your operating system's access control system. Create a group for each project, and assign people to the groups they are allowed to be in. You will have to determine, in conjunction with your project leaders, which projects new users will have access to, by default. And, of course, get the managers and project leaders on side to explain that changing project files they haven't been assigned to will result in disciplinary action, up to and including termination. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Repository Access
S I wrote: cvs_acls? Ok thanks. I have to research that. Is that a 3rd party tool or part of CVS? It's part of the source code distributed from www.cvshome.org. Download the tarball (or check out the source) and cvs_acls will be in a directory named 'contrib'. cvs_acls provides more fine-grained control over access - it allows, for example, control over who can check into branches, and so on. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: query
Russ Sherk wrote: On 6/16/05, Jim Hyslop [EMAIL PROTECTED] wrote: I'm curious - what use could this information possibly be, anyway? Usually this information is used by managers to determine churn. Bigger churn (more files/lines changed) means bigger risk. Not if there's a proper set of unit tests in place. I'm always skeptical of raw numbers like this being used for any meaningful analysis. I don't think simply counting the number of lines added or removed is a good indication of risk. Suppose the tool reports 100 lines added, 100 lines removed. Does that mean one line was changed 100 times? 100 lines were changed, one time each? Changing one line 100 times carries less risk than changing 100 lines once. And unless FishEye (or any other software) performs a fairly complex analysis of exactly which lines were added and removed, you won't know where on that spectrum your count of 100 lines added/removed lies. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Recovering from Attic
Aaron Jackson wrote: Ok, if there is a directory in a project that had three files in it and they were all removed to the attic with cvs rm at different times and you want to recover all three files (say 3 could be 100+ files in some cases) but they all have different versions on them. How could you check the version just before the version that was marked as dead and moved to the attic? I did manage to recover something that had been tagged, but in this case many of the files would not be tagged in a version. If there are many files, then I think you'll have to write a script to do this: - create a dummy file with the correct name - issue a 'cvs add' and captures the output of the add command, e.g.: cvs add: Re-adding file `test.txt' (in place of dead revision 1.3). - parse the above message to find the dead revision number - subtract 1 to get the last good revision number - issue the command cvs update -p -r[rev number] filenamefilename -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Retrieving dead files from the Attic
S I wrote: Here's another question I have on the same topic: If a file is removed from CVS properly (by rm, cvs rm, cvs ci), what gets committed to the Attic exactly? Both the file and its sister comapnion file,v or just the latter? The original file is never copied into the repository. When you 'cvs remove' a file, CVS adds a new revision to the ,v file, with the state dead, and the file is moved into the Attic. I still have not managed to retrieve my lost files from the Attic, executing the 3 commands I listed. They simply don't work and retrieve new files with zero or empty cotent. Help! Keep in mind that just because a file is in the Attic does not mean it is completely dead. It only means that the *trunk* is dead. Unless the file was explicitly checked into the Attic directory (which is unlikely, because the developer really has to go through hoops to do that) then everything can be done from your client. What does a 'cvs log' show for one of the files? (You can trim the log messages themselves, but please keep intact the header and the revision state info, e.g.: RCS file: /cvs_repository/conversations/factory/save.txt,v Working file: save.txt head: 1.1 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 1; selected revisions: 1 description: revision 1.1 date: 2003/03/09 16:26:19; author: Jim; state: Exp; [log message trimmed] = -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problems with branching
rakesh mailgroups wrote: Hi all, I have found branches that i have created in cvs are not showing for other users and vice versa. Does anyone know why this is? I have never heard of such a problem. What exactly do you mean by not showing for other users? Please provide more details: exactly what commands did you run, what was the expected output, and what was the actual output you received? Also, which version of CVS (both client and server) are you using? -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Restoring deleted revisions (was: Branch Numbers)
Hridyesh Pant wrote: Thanks a lot Jim. Is this version of cvs is stable? right now we are using cvs 1.11.17. Is is ok for me to go 1.12 version? It should be, yes. 1.12 is very close to being promoted to the next stable version. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: trigerring several actions on commit
Guillaume Rousse wrote: I had a small look in the list archive and in the on-line manual without being able to find an answer: can I trigger several actions with a single commit ? My own tries make me think that only the first line with a regexp matching the commit directory is used, and subsequent ones are silently ignored. I could use a wrapper scripts encapsulating the different tasks, however I don't want to use the same list of task for all the different parts of a repository. In other terms, I'd like to do something as: ^foo report-mail ^foo/www extract-website Meaning sending mail for any commit in foo modules, and additionaly extracting web pages for the www subdirectory. ^foo foo_commit.sh ^foo/www foo_www_commit.sh where foo_commit.sh and foo_www_commit.sh call whatever scripts you need. Or, have a single foo_commit.sh script, which uses `cwd` to determine if it's in the www subdirectory, and if so, invoke extract-website. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Restoring deleted revisions (was: Branch Numbers)
Hridyesh Pant wrote: Hi Jim, As per ur suggestion i made cvsadmin group.but now the user can not execute cvsadmin -l filename to lock the file. CVS 1.12 can be configured to allow non-admin users to execute specific cvs admin sub-commands. Have a look at the UserAdminOptions at https://www.cvshome.org/docs/manual/cvs-1.12.12/cvs_18.html#SEC206 -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to get started
Rondal Ellifritt wrote: I have recently been hired into an existing development group. One of my tasks is to get the group using version control. Quite a challenge, from your description. Maarten has given you some excellent tips. Out of all of these, I think your first priority *has* to be to separate the production environment from the development environment. I know you're new to the company, but I'm sure if you start enough casual conversations, you'll get a large number of horror stories about problems that occurred because of this mixture - use this as ammunition to convince people. Also explain that separating development from production is not _your_ way of doing things - it is a widely accepted, industry standard Best Practise. Nowhere have you mentioned developer training in CVS. Do the developers already know how to use CVS? If not, that is a critical step that must happen before you do anything. The developers must understand and be comfortable with basic version management concepts and the basic CVS commands if you want any hope of achieving your goals. Along the way, you will likely encounter many excuses for not doing things the new way: Oh, it's only one minor tweak. I don't have time to do it right - I've got a deadline (your response: If you don't have time to do it right, when are you going to have time to do it over? and don't wait for an answer - it's a rhetorical question). Gently but firmly remind them that these shortcuts are what got them into the current mess they're in (and don't be afraid to use the word mess - if the other developers have a shred of professional pride, they know in their hearts the situation is a disaster waiting to happen). As you progress, you will likely have dozens of questions. Feel free to post them here - that's what this list is for ;=) -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS update -j branch-tag failes to merge
Asbjørn Sæbø wrote: On Fri, May 13, 2005 at 03:58:12PM -0400, Jim Hyslop wrote: What version of client and server are you using? Both are 1.12.9 Hmmm... I just tried it with 1.12.12, and it worked OK. Can you upgrade to the latest versions and try again? -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS update -j branch-tag failes to merge
Asbjørn Sæbø wrote: On Fri, May 13, 2005 at 10:04:59AM +0200, Asbjørn Sæbø wrote: I have a CVS module (named ldas) where I would like to merge the contents of a branch into the trunk. According to the documentation, is seems that I should be able to du this using cvs update -j branch-tag. However, this does not work. No merging takes place, the files on the trunk do not receive the changes from the branch. [...] [EMAIL PROTECTED]:~/ldas/utvikling$ cvs update -j dev_20050413_b ldas However, when I changed into the ldas directory, and did the update, it worked: [EMAIL PROTECTED]:~/ldas/utvikling$ cd ldas [EMAIL PROTECTED]:~/ldas/utvikling/ldas$ cvs update -j dev_20050413_b . [Much retrieving and merging] Is this difference between naming the module/directory and standing in the module/directory expected behaviour? No. I just tried it with cvs 1.11.20, and it worked OK: C:\cvs-test\jimcvs -d \cvs_repository tag -r brach_base -b abranch cvs tag: Tagging . T test.txt C:\cvs-test\jimcvs up -r abranch cvs update: Updating . C:\cvs-test\jimecho branch changestest.txt C:\cvs-test\jimcvs ci -m branch changes test.txt Checking in test.txt; \cvs_repository/cvs-test/jim/test.txt,v -- test.txt new revision: 1.2.2.1; previous revision: 1.2 done C:\cvs-testcvs up -A jim cvs update: Updating jim U jim/test.txt C:\cvs-testcvs up -j abranch jim cvs update: Updating jim RCS file: \cvs_repository/cvs-test/jim/test.txt,v retrieving revision 1.2 retrieving revision 1.2.2.1 Merging differences between 1.2 and 1.2.2.1 into test.txt What version of client and server are you using? -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Questions on pserver authentication
Todd Foster wrote: I am trying to determine how pserver authentication works. I understand when you do a cvs login that it creates ~/.cvspass file. Therefore, I'm guessing that whenever you are running cvs commands cvs blindly combines the USER from whichever method wins (either using the pserver info found in the local working copy or in the $CVSROOT or in the -d) and uses the password from the ~/.cvspass of whoever is running the commands. Is this correct? No, there is nothing blind about this. CVS determines the user ID from the CVSROOT information. It searches for the CVSROOT information in this order: 1) the global -d option 2) the file ./CVS/Root 3) the CVSROOT environment variable CVS then parses the CVSROOT information, and if the :pserver: method is specified, it looks up the CVSROOT in $(HOME)/.cvspass (note that it is not necessarily ~/.cvspass - $HOME is frequently set to ~). So, if user1 goes into a cvs directory created by user2 and tries to do cvs commands in there, it uses the username found in the local working copy (user2) and combines that with ~user1/.cvspass and authentication fails. One way around that is to override the user explicitly to user1 with the cvs -d option. However, this is a very annoying way to get around the problem. You could delete the file CVS/Root, and make sure each user has the CVSROOT environment variable is set. If you're using *NIX, you could create an alias: alias cvs=cvs -d :pserver:[EMAIL PROTECTED]:/path on a per-user basis. Or you could wrap CVS in a script: # cvs-wrapper.sh cvs -d :pserver:$(USER)@server:/path $@ (or whatever the syntax is for 'all command line arguments - I'm not very experienced at shell scripts) and get everyone to use cvs-wrapper.sh instead of cvs. What I'm really wondering, is what does the pserver authentication do if the username is omitted from the pserver CVSROOT, then what happens? I haven't tried it, but you'll probably get an error, since the CVSROOT format for :pserver: requires a user name. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Restoring deleted revisions (was: Branch Numbers)
Hridyesh Pant wrote: Hi Jim, I need ur help,some how i deleted 1.1 revision of some files.can i restore this revision. The only way to actually delete a revision of a file is using the 'cvs admin -o' command. There is no way to undo that action, except by restoring the repository file from your daily tape backups. For example: if i have 1.2 revision of these files , can i make 1.1 revision which is copy of 1.2 revision? You could, but what would be the point? Is there any cvs command to do this. No. Unless revision 1.1 has critical information in it, I wouldn't worry about it. If you feel you absolutely must have the revision 1.1 available, then here's what I suggest (others may have better ideas): Before you do anything, back up your repository as it sits right now. That way, if any of the following steps screw up, you can simply restore from backup. If and *ONLY* if you are sure there have been no check-ins, tags, or other modifications to the file since the revision got deleted, then simply restore the ,v file from your tape backup into the repository. Make sure nobody else is trying to access these files while the restore is in process (you can create two empty files, called 'readers' and 'writers', in the CVSROOT directory to lock everyone out of the repository temporarily; delete the files when done). Otherwise, if there is any doubt, then restore the repository file *into a different location in the repository*, check out revision 1.1 of the file, copy it into the good working area, and check it in on a branch. It will not be revision 1.1, but at least it will be available for inspection. As an example, suppose the file you want restored is big_project/main.c. Have the file restored to, say, $CVSROOT/temp_for_restore/big_project directory. Then issue the following commands: cvs co big_project cd big_project cvs tag -b -r1.2 revision_1_1 main.c cvs up -r revision_1_1 cd .. cvs co temp_for_restore/big_project/main.c cp temp_for_restore/big_project/main.c big_project cd big_project cvs ci -m Revision 1.1 restored from tape backup main.c Right now i am not able to send mail to info-cvs@gnu.org.so pls help me. I've cc'd the list with my response. -- Jim p.s. it's always best to start a new topic by creating a brand-new message, not by replying to an old one. Your question has nothing to do with the previous discussion on branch numbers, and (assuming it made it to the list) might have been ignored by someone who's flagged that thread as not interesting. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS migration question
[EMAIL PROTECTED] wrote: I've been thinking about this since reading it on CM Crossroads this morning. I don't think it would be too terribly complicated. On the server side, I think it's just a matter of packing up the entire repository and ftp'ing it to the new server (or just copying it if you have a samba share). That's the bulk of it. You would have to update (or more likely rewrite) any scripts, such as commitinfo, loginfo, etc. My only concern is whether or not you'd have to worry about the ^M end-of-line problem between windows and Unix. Nope. RCS file format always uses a plain ASCII LF character as the line terminator, regardless of the platform the RCS file lives on. It's the client that translates LF into the appropriate line terminator for the client platform. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Images
Mychael Scribner wrote: I have a simply little question. I do a lot of web based project that often have images. Is their and do's or don'ts that I be watching for with images. Should I not include them when I import a project? There's no reason to exclude them. Just make sure you mark them as binary when you add them - either add the extensions to $CVSROOT/CVSROOT/cvswrappers, or explicitly use the '-kb' option with the 'cvs add' command. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: watch on dir
Pedro Hernandez wrote: Hello folks! cvs 1.11.20 on Whitebox Linux 3 I'm trying to make a directory watched by default, reading in Cederqvist Command: cvs watch on [-lR] [files]... ... Is this a bug in cvs, the doc or in my head? It's a bug in CVS. The workaround is to issue the command from within the directory, and do not specify anything for [files] when you issue the command: cd wt cvs watch on -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can't checkout to my C: root directly *PANIC* Admin Files Missing
Mark D. Baushke wrote: If you see that you are indeed configured to use TopLevelAdmin=yes, then Arno Schuring's analysis that you are unable to create and populate a C:\CVS directory is likely the root-cause of your problem. I think the analysis Arno provided is exactly right, and has nothing to do with the TopLevelAdmin option. From any working directory, if you create a directory named CVS (or 'cvs' on Windows, since it's case-insensitive) then _without changing directories_ issue just about any CVS command, you'll get the PANIC error message. The red herring in this case is the fact that the current working directory also happens to be the root directory. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: What exactly is HEAD anyway?
Andrew DeFaria wrote: The more I look into CVS the less I understand. Perhaps you can help me... When using -r HEAD I do not seem to get the latest revision on the trunk: As you've found, 'HEAD' means the latest revision on the trunk for all commands except 'diff', where it means the latest revision of the branch that is checked out. I don't know how this inconsistency came about, but for backwards compatibility it's not likely to get fixed. Instead, the feature branch (CVS 1.12.x) has added new special purpose tags so that you can always specify the tip of the trunk, the tip of a branch, the base of a branch, and so on. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Branch Numbers
SUBRAMANIAN, SARAVANAN (SBCSI) wrote: Hi all, How Branch Numbers are formed Internally in CVS. I read the manual it is really confusing. We have two branches, after we created the second branch, when the developers start committing the files, I found out that one file is committed with 1.12.2.1 And other with 1.1.4.1 Please help me found the why there is a difference in the above? Larry and Kaz have given some excellent basic information to answer your question. I will add this, though: forget about it. Revision numbers should, for the most part, be treated as black boxes that have no meaning to you and me, only to the program itself. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Locking a Branch
SUBRAMANIAN, SARAVANAN (SBCSI) wrote: Hi I need to lock a Branch, so that no one can check out or check in some information into it. First of all, do you really need to lock the branch? Can you not trust your developers? I don't have access to the CVS host machine, but I am connecting it through the CVS Binaries That will make it more difficult. You need to install scripts on the server in order to do what you want. One script is the cvs_acls script that is contained in the source distribution (download the source from www.cvshome.org). -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: contrib directory?
[EMAIL PROTECTED] wrote: This is like the third reference I've seen to a contrib directory... where is it? As I said, it's in the source code distribution. Download the source code from www.cvshome.org. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Renaming a branch
David Leskovac wrote: Sorry for the basic question but I need to implement a new branch naming scheme want to make sure I am doing this correctly. To start this process, I need to rename several existing branches. Would this work for each branch to be renamed?: cvs rtag -b -r original_branch_name new_branch_name module cvs rtag -d original_branch_name I am aware of the -B argument to rtag. But, the version of cvs that we use is so old (1.11.1p1) that it pre-dates that argument. That will probably get you where you want to be, although it doesn't really do what your stated goal is (to rename the branch). It will create a new branch and delete the old branch. The effect will be the same, but be aware that you will be branching off a branch. Suppose, for example, that the tip revision for a particular file on original_branch_name is 1.2.2.2: Before branch add and delete: 1.1 --- 1.2 --- ... \ + --- 1.2.2.1 --- 1.2.2.2 after branch add and delete: 1.1---1.2--- ... \ +---1.2.2.1---1.2.2.2---X --old branch (effectively dead) \ + ---1.2.2.2.2.1 -- new branch 'cvs co -r new_branch_name' will retrieve the correct branch. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Lock on Trunk
Dean Do wrote: Hi, I have a question on access control. Is there a way to prevent all commits on the main trunk and allow commits on branches only? Once the changes on the branch are reviewed and approved for merging into the main trunk, then the main trunk can be manually opened up temporarily for those changes only. Please advise if there's a way to implement this type of controlled access. Yes. Have a look at the cvs_acls script, in the contrib/ directory of the source distribution. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about binary distribution
(gnu.cvs.help trimmed from recipient list; I can't access it) HSP wrote: hello, i downloaded cvs-1-11-20.zip from https://ccvs.cvshome.org but i can´t find information about wich windows versions are supported. Is Windows 2003 server suitable for cvs server ? thanks in advance!! If you're using Windows as your server, then you probably would be better off using CVSNT on your server: www.cvsnt.org Clients can use either CVSNT or cvshome's CVS. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
Dr. David Alan Gilbert wrote: 2) I could do with a better under standing of the directory locks; pointers? I've read the top of lock.c but it still doesn't tell me enough; for example there seem to be multiple lock files used - but then surely the creation of them isn't atomic? Or is there one lock file used for both reading and writing? The locking process is explained in the manual, at https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_2.html#SEC17 -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Checkout after a change
[EMAIL PROTECTED] wrote: The example they give is with unix, how would I do it with linux (Fedora C3, I think it is). Same principle. Remember, Linus *is* a port of UNIX. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
