Re: disable changes of local file
[EMAIL PROTECTED] wrote: Got large data file in project that I've imported to the repository along with other files. I'd like this file to be kept in repository, but that local changes (this file is changend often locally, because of testing) do not change the copy in repository and that during an update from repository local copy doesn't change either. Not easy. Anyone can commit new revisions. What you should do (should have done) is import the file under a different name, that makes it clear that it is a template for the tests. Developers would have to copy the template file to the correct filename before running their tests. Since the copied file is not in CVS, they can make any change they want. If it's early enough in the game, the path of least resistance is to rename the ,v file in the repository --but that breaks any checked out sandbox, so people should check out new ones and delete the old. Now, I know that I can accomplish later trough putting this file name in .cvsignore file, but is there some more proper way and further how to accomplish first. Actually, no. Files listed in CVS/Entries are never ignored. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add new files to branch
Mei-Xing Zhao [EMAIL PROTECTED] wrote: Thanks. cvs tag works. But after running this cvs tag command, do I do a cvs add to add this file the the branch? It's already added. Just switch your sandbox to the branch, cvs update -r release-1-patch and you'll find that the file is now present. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: merging branch to HEAD when branch contains partly trunk changes already
HK [EMAIL PROTECTED] wrote: Suppose the following situation. +-1.25.2 .. -- 1.25.2.2 -- 1.25.2.5 | ^ | |merge in 1.25 -- ... -- 1.27 -- ... -- 1.31 At 1.25 I created a branch. Later I merged the changes between 1.25 and 1.27 into the branch at 1.25.2.2 to have minor updates of the main trunk also in the branch. Now I want to merge the branch back into the trunk. If I remember correctly, the correct merge would be -j 1.27 -j 1.25.2.5 (or the equivalent with instead of hard revision numbers). I tried a straighforward merge of the tip of the branch with the tip of the trunk and get only minor conflicts. Yeah, sometimes that works. Other times I get bogus conflicts with the same text on both sides of the conflict. I just clean those up by hand. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add new files to branch
Mei-Xing Zhao [EMAIL PROTECTED] wrote: [ ... ] cvs rtag -b -r release-2 release-1-patch A Just use cvs tag instead of cvs rtag (and do it from a trunk sandbox where the A file is present). -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs update $Name: $ expansion
[EMAIL PROTECTED] wrote: I can't get $Name: $ to expand on an update in my script below. It works when checking out. But, do I really have to do a checkout? I think it works on update, *if* the working copy is missing and the update has to get a new copy from scratch. (And, of course, if the sandbox has a sticky revision tag.) So if you use $Name$ in a single file, you can get that file to expand correctly without having to check out the entire project. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Server Change
Soo-Hyun Choi [EMAIL PROTECTED] wrote: I am a beginner in using CVS, and have a question on to change the CVS server. [ ... ] Would this work if I simply copy the CVS's ,v files with the directory to the machine S's cvsroot directory? Yes. This also makes your existing sandboxes nonfunctional, so be sure to delete them after committing any pending changes. Check out new sandboxes from the new server after the move. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Cron process to schedule CVS check in as another user ???
[EMAIL PROTECTED] wrote: We would like to version PLSQL code, but we don't want the repository to be updated until code has successfully been compiled and deployed to the DB. Would branching do ? Develop and test on a branch and merge to the trunk when the tests are declared passed. [ snip ] Granted, as I write this code - I realize it's backwards, but here are my questions: 1. is it possible to check in code as common user telling it to use another for CVS history and logs? I don't think so, but I may be wrong. There is always sudo(8), where you *authorize* user X to run some class of commands as user Y. 2. Can a common user cd to the developers working CVS directories and even do a check in? I think so, if he has write permission to the working directory tree and if he uses the -d option to override the access method stored in the CVS/Root files. For the permissions, use set up the groups appropriately and set the umask to something like 002 so the cvs operations don't clobber group flags. 3. I'm not really a Unix expert, what's the best way to run a script as another Unix user ? we are an HPUX 11 shop. I'd say sudo, as configured in the file /etc/sudoers . -- pa at panix dot com ___ 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: Is it possible to roll back the version of the currently used CVSROOT/modules file? [ correct description of amperstand modules conundrom ] As Jim said, you're stuck. You can always do this, cvs checkout CVSROOT cd CVSROOT cvs update -j HEAD -j oldrev modules cvs commit modules followed by a repair as soon as you have your old project checked out, but it has bad drawbacks. I wonder if there are hacks... The Linux man page for mount(8) says: Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is mount --bind olddir newdir After this call the same contents is accessible in two places. So if you're on Linux, here's a hack: * cvs init a brand new directory, say ~/cvsrepair. * Bind-mount the real cvsroot under ~/cvsrepair. So your directory structure is ~/cvsrepair/ CVSROOT/ modules ... real_cvsroot_bound/ CVSROOT/ modules ... project_1/ ... Now check out CVSROOT from cvsrepair, copy the CVSROOT/modules from the real cvsroot and change all the paths to prepend a real_cvsroot_bound/. Commit that. It seems to me you can now check out projects from either cvsroot. Even locking ought to work, since the locks are going to be visible from both cvsroots ! To get the back-revision of your project, just put the *old* revision of the real CVSROOT/modules in cvsrepair/CVSROOT/modules and edit the paths in the same way. If you check out from cvsrepair, you'll get the old set of amperstand modules. Meanwhile, your production cvsroot is never defaced. Devious enough ? (Hem, I'd back up the repository before trying that stunt.) -- pa at panix dot com ___ 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 [EMAIL PROTECTED] wrote: 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, Yes. even if I have changed only a single line of code Yes. - and even if the code is buggy. Yes. If you commit a bug, fix it and commit again. Try not to commit buggy code, but if it happens once in a while it's not that big a deal. You will want to tag the project when you believe there are no bugs, so you have a well-defined baseline to begin serious testing. You can also create a stabilization branch where you will do the bug fixes, or you can wait till you are ready to move the code to the production server. You *must* tag the state that you move to production and you *must* fix any post-release bugs on a branch, to isolate production from continuing work on the trunk. Having a trunk and one active branch will complicate the commitinfo script but it's doable. Can you run two instances of the testing server ? Then your loginfo hook can maintain two sandboxes, one on the trunk and one on the active release branch. You can use a floating tag name for the active branch to avoid rewriting the loginfo script all the time. There are ways; it's just normal hacking. 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. So you upload instead of cvs-commit, and something goes wrong right at that step and the remote sandbox loses its CVS subdirectories. Which is worse ? Like this I can always be sure, that code in the repository is actually code that is working correctly. No, the code can still be buggy, just not obviously so. You will commit buggy code every once in a while even if you can test before committing. Like I said, it's not that big a deal. The best solution would be to fix your IDE's habit of clobbering the remote CVS directories. Failing that, my proposal is quite workable once you get used to it. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Importing new vendor release from RCS
Berthold H?llmann [EMAIL PROTECTED] wrote: I'm trying to import a new vendor release into a CVS repository. I would like to keep the RCS history provided with the project. Is there an easy way to achieve this? Do you mean they gave you a directory tree populated with RCS ,v files ? If so, just copy the lot to a new subtree in your repository. (That's not absolutely guaranteed to work, but the odds are good.) -- pa at panix dot com ___ 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 [EMAIL PROTECTED] wrote: [ ... ] The problem is the following: the cvs server is at the same time the web server where the application runs. So I have to checkout to the web server. But: My IDE runs locally on my machine and it needs the complete source code to enable it to use code completion etc. Between my local machine and the server there is only a DSL connection so I have the local changes mirrored to the web server (using the SFTP client) and then do the commit from the web server. Any better ideas? 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 -- pa at panix dot com ___ 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 [EMAIL PROTECTED] wrote: When I do a checkout everything is fine and a CVS directory is present in every directory of the checked out module. However as soon as I upload a changed version of of my code using my SFTP-Client the CVS-Directory disappears from the directory to which I have uploaded the file. As a result of this CVS always thinks that the directory is not yet under CVS-control. Let's see if I got this straight: 1) You start with the CVS/ directories present. 2) You run an SFTP client. 3) The CVS/directories are gone. Based on these facts, I would say that the SFTP client removed the directories. May I ask why you are mixing CVS and sftp ? Why can't you have a CVS sandbox checked out on the machine from which you were uploading changes ? Instead of uploading, you would just cvs commit from there. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS misc questions
Fabio Miranda Hamburger [EMAIL PROTECTED] wrote: I have a misc list of CVS questions regarding web development: 1. Let's say you have 10 developers uploading files from dreamweaver to a apache server (let's assume no testin). If you implement CVS, how can you implement CVS in these situation when you have designer and developer without unix knowledgement and without shell access ? I would use TortoiseCVS. You will probably have to install it on their computers. If necessary, write a detailed memo on where to download the files and what buttons to click to perform the install. You should also place the first version of your site in CVS yourself. CVS is very easy to use once everything is set up, but starting something takes more work, which you don't want to impose on your web developers. 2. Where can I find 'best practise' articles about control versioning? how to know you reach a milestone? well, in fact, how to define one?, how to assign number to the versions with a logic sense? like linux kernel versioning That's a long story, and it may not apply to your web site since from what you say the files get deployed to a live server without going through a formal testing stage. Only you can tell when you've reached a milestone. When you do, the simplest thing is to tag the project so you can return to that state if need be. 3. How to deal with binary files when checking out a sandbox against a repository_ For examples, images that belongs to the project, binary logs, etc. that are inside the sandbox as a part of ther project Just make sure they get cvs-added as binary files. With TortoiseCVS, this means having a good CVSROOT/cvswrappers file on the server. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: problem importing directory called 'tag'
Peter Dobbs [EMAIL PROTECTED] wrote: I'm importing someone elses code and part of the tree has a directory called tag. Everything imports except this directory.. Is there some way to get this to import ? I don't remember that name being reserved anywhere in CVS. Check to see if the tree you are importing has a .cvsignore file with the word 'tag' in it. If that's the problem, remove the .cvsignore and repeat the import (i.e. the exact same import command, with the same release tag). -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: $id automatically inserted in file
Klaus Hebsgaard [EMAIL PROTECTED] wrote: Russ Sherk [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Have a look at cvs admin command. Specifically the -k option. (-kto?) Sorry for not writing this from the beginning - I knew about this option, however i access cvs through tortoise, and am not able to send commandline options, is it really not possible to set this up on the server? Sure you are. Put the Program Files\TortoiseCVS\ folder on your Windows path. There is a cvs.exe in there. If it is on your path, you can run cvs from a command prompt window. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to undo a commit?
Christian Hujer [EMAIL PROTECTED] wrote: What is the best way to make the HEAD revision of the files being the previous revision? I've read the faq, they say if the last version is 1.31, checkout 1.30 and recheckin as 1.32. But I cannot imagine how to do this. cvs update -j 1.31 -j 1.30 the_file or cvs update -p -r1.30 the_file the_file When I try cvs update -r 1.30 file and then cvs commit file it of course does not work. Because it has a sticky revision. To recover from that, cp the_file tempfile cvs update -A the_file mv tempfile the_file Any one of these three methods will give you a file with the content of revision 1.30, ready to be committed as revision 1.32 . -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: sandbox on NFS-mounted directory?
Terrence Enger [EMAIL PROTECTED] wrote: I have seen lots of warnings against accessing a repository through an NFS mount. But I do not remember seeing any comments about accessing a sandbox through an NFS mount. (Although, until today, I did not think I cared, so could easily have overlooked warnings.) I would welcome your advice. I do it routinely. Just synchronize everybody with ntp or the clock skew will wreck your build system --which is not a CVS issue. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: trouble with cvs add
Russ Sherk [EMAIL PROTECTED] wrote: Pierre, Why so complicated to merge a file from head to a branch? I just ran a little test and my recommended method works. Martin has some files that exist in HEAD but not in BRANCH_1_2. Since they exist in the repo, cvs says 'can't add this file because it exists'. Since it already exists, it only has to be merged into BRANCH_1_2: Duh, yes I do think you're right ! -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: moving directories within CVS
[EMAIL PROTECTED] wrote: I need to physically move a directory within the repository, without losing any delta history. So far, my process looks like this: [ snip ] And that process works *fine* so far in my tests. But I was wondering if there was a way to simplify this process, to be able to move folders behind the scenes so that the developers wouldn't have to do a release and checkout? The problem is that working copies have CVS/ subdirectories with metadata that is based on the layout of the repository at the time of the checkout. If you remodel the repository you have to hunt down all those working copies and edit the metadata to match (not recommended). The path of least resistance is to wipe out the working copies and obtain fresh ones after the reorganization, as you do. Another thing to keep in mind is that you can no longer recreate old releases that predate the reorg. If you try, they will come out under the new layout. This is a show-stopper if you are still supporting old releases. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: trouble with cvs add
Mart?n Marqu?s martin@bugs.unl.edu.ar wrote: El Dom 10 Abr 2005 18:55, Pierre Asselin escribi?: One way is to add them to the branch first, and then merge that change to the trunk. But it's too late for that. How would this be done? By deciding ahead of time that the files should be committed to the branch first, and only then merging that commit back to the trunk. Starting from a trunk sandbox, cvs update -r the_branch_tag and the sandbox is now on the branch. Create the files in this sandbox. Then, cvs add file1 file2 ... cvs commit Finally, return to the trunk and merge cvs update -A cvs update -j the_branchpoint_tag -j the_branch_tag This cvs adds the files to the trunk sandbox cvs commit In your case it is too late to do that since the files are already present on the trunk. However, I think you can make them appear on the branch just by tagging them like the rest. (on the trunk) cvs tag -b the_branch_tag file1 file2 ... cvs update -r the_branch_tag (sandbox is now on the branch and the files should be there) -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: how to undo import
Kevin Rodgers [EMAIL PROTECTED] wrote: Should I infer from the complete lack of responses over the last 5 days that my only option is to delete the distribution directory in the repository itself, and start over with the current version? That may be, or possibly the original question wasn't clear. :-) Kevin Rodgers wrote: I'm trying (for the first time) to track a large 3rd party distribution. So of course I screwed it up: I unzip'ed the distribution in the working directory itself and then imported it, which resulted in all the CVS subdirectories being imported into the repository. Are you sure ? The CVS subdirectories should be ignored by default. Still, it's probably a good idea to undo the import. First, back up your repository. Check out a temporary working copy somewhere else. Don't worry about conflicts from the second import, just do a plain checkout to get a working copy. Use cvs status -v file by file to find the revision numbers associated to SAXON_B_8_3 and SAXON_B_8_4. *) For files where the two tags are present and are the same, just delete the SAXON_B_8_4 tag. cvs tag -d SAXON_B_8_4 some_file *) For files where the two tags are present and are different, delete the bad revision and bad tag. This is a little tricky because the revision you want to delete is often the one checked out in your temporary working copy. The following should work: cvs update -r SAXON_B_8_3 some_file cvs admin -obad_revnumber some_file cvs tag -d SAXON_B_8_4 some_file cvs update -A some_file where bad_revnumber is the revision number of SAXON_B_8_4. I'm pretty sure you have to give it numerically instead of using the tag, but you can try that too. *) For files with only SAXON_B_8_4, go delete the ,v file in the repository. *) For files with only SAXON_B_8_3, do nothing. Needless to say, be very careful not to mix files, revision numbers and tags on those command lines. Now wipe out the temporary working copy. Check out a working copy again. It should be identical to what you had before the bad import. Leave that working copy aside. Go unzip somewhere else and re-import your freshly unzipped copy. Further, I had committed a local change to a few files (including some binary files) in the original distribution, so the import complained about conflicts and That's normal. I followed its advice to checkout the original version of the distribution. That's not quite what it says, but your checkout command cvs checkout -jSAXON_B_8_3 -jSAXON_B_8_4 public/3rdParty/java/saxon is correct, provided you first go to an empty directory. Edit the text files to resolve the conflicts. For the binary files, work it out. CVS can't help you there besides providing you with copies of the old, your changed version, and the new. When all the conflicts are resolved, commit. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Newbie Query: Command line option for checking out to local comp from cvs server
Balaji D [EMAIL PROTECTED] wrote: Can I checkout files from cvs server(Linux) to my local machine (Windoaw based) through commandline? Sure. Just make sure the command-line client (cvs.exe) is on your Path. (If you installed one of the GUI front-ends, you almost certainly installed a command-line client with it, probably cvsnt.) -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: trouble with cvs add
Mart?n Marqu?s martin@bugs.unl.edu.ar wrote: I have a project with some branches. One of those branches is a posible 1.2 release in which we are working out some problems. The thing is that I add some files to the HEAD which I need in the 1.2 release, but I just can't add it to the branch because it says that the files (and directories) already exist. One way is to add them to the branch first, and then merge that change to the trunk. But it's too late for that. I think you can go to a trunk sandbox and tag -b the added files so as to put them on the same branch. Then go to a branch sandbox and update. You may need to give a -d flag to the update command. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management?
Doug Lee [EMAIL PROTECTED] wrote: Now for why... I write scripts for a screen-reading program called JAWS For Windows (JAWS stands for Job Access With Speech). JAWS scripts must all exist and run in a specific directory, say c:\jaws510\settings\enu. JAWS scripts are named after the applications to which they apply; thus, a script for WordPad will be named WordPad.jss (source code; the compiled version is WordPad.jsb, and there are other associated WordPad.* files as well). Every script for every application that needs special handling goes in the same directory. This is how it comes to pass that I often have multiple simultaneous projects in the same directory with no overlapping file names. I see. Well, allow me to pontificate a little. Your files are scripts and require no compilation, so you make the common mistake of confusing the *source tree* of your project (your scripts) with the *installed version* of your project (your scripts in jaws510\settings\enu with all their other script friends). The source tree goes into CVS, the installed copy doesn't. You should be doing a make install or some such to install your files... ... except that it sucks, because you can't even *test* your scripts without installing them. Which is why the above qualifies as pontification. Bottom line: JAWS is not nice, and there is nothing you can do about it. Or does JAWS understand shell links (aka Windows shortcuts) ? If yes, you could plant shortcuts from the installation directory to your CVS sandbox. Is there a tool to plant shortcuts programmatically? One other thing: are you the only one involved that uses CVS? if so I guess your approach is okay, but your initial post said something about telling everyone else to stop committing to the trunk while you were away. That negates the C in CVS, which is a shame. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: nameless branch with cvs
Alexandre [EMAIL PROTECTED] wrote: due to an error a branch containing many version of a file has been moved to one of its file therefore creating what look like a nameless branch.. Is there a way to move back the branch ( name ). cvs admin -NBR_MYBRANCH:x.y.0.z the_broken_file for suitable values of x, y and z. Verify with 'cvs status -v'. Was Main Tr | 1.1 | 1.2--/ BR_MYBRANCH \ | | 1.3 1.2.1 ... | 1.2.2 | 1.2.3 Can you redraw the diagram carefully ? The revision numbers on the branch can't be what you say, since they must have four components. They are probably of the form 1.2.2.n instead of 1.2.n, but I can't be sure since you may have other branches rooted at 1.2. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management?
Doug Lee [EMAIL PROTECTED] wrote: I use CVS to manage a number of projects. When possible, I use a central repository and link to it either locally or through a tunnel. But sometimes I have to work on a CVS project at a location that has no Internet connectivity. For that, I've routinely carried repository trees around as follows: [ snip ] I check out a sandbox on a laptop and tag it before I leave. I take the laptop with me and work without the benefit of CVS (but see below). When I return I create a branch off the departure tag and update my modified sandbox to it (vacuous update, the just-created branch is empty and there is nothing to merge into the sandbox). I commit the modifications on the branch. I return to the trunk (cvs update -A) and perform a normal branch merge. I can work without CVS per se, but I'm really addicted to the safety net of revision control, so I use RCS behind CVS' back. mkdir RCS ci -l some_file_I_want_to_hack ... hack ... ci -l some_file_I_want_to_hack ... When I return, the RCS subdirectories are skipped silently because they are in the default .cvsignore . All I have to do is commit by modified sandbox to a branch as outlined above. All the modifications made on the trip are committed as a single change without the intermediate history, but this is usually not a serious drawback. Someone, I forgot who and when, posted a gutsy move where a sandbox coexists between two CVS repositories. 1. Commit before you leave. 2. Move all CVS subdirs to something like .CVS The cheched-out tree is no longer a CVS sandbox ! 3. Import into a local repository, created with cvs init if necessary. 4. Check out from the local repository. The resulting sandbox has its CVS subdirectories but it also has .CVS subdirectories from the import, with the metadata of the original repository. 5. Hack normally off the local repository. 6. Commit before plugging back into the main network. 7. Run a script to swap every CVS with .CVS. What was an up-to-date sandbox relative to the local repository is now a modified sandbox relative to the central repository, with extra .CVS subdirectories. (Do not cvs-add these to the central repository.) 8. Do your cvs update and fix the conflicts, then commit. Once again the entire modification set ends up committed as a unit. You could even swap CVS--.CVS multiple times and alternate between two repositories that way. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Help with CVS
asdf qwer [EMAIL PROTECTED] wrote: I am a graduate student at Illinois state university, USA. I am writing a research paper on SCM and web development. One part of the paper talks about different tools. I need some information from any of you who has worked with CVS in a web development project. I am looking of rinformation like how good CVS will be for this kind of a project, what are pros and cons You can look at http://philip.greenspun.com/panda/ , in particular Chapter 4 which has this link: http://philip.greenspun.com/wtr/cvs . This second link in turn has references at the end. I worked on a web site for a while; I was one of a half-dozen developers. We each had our own copy of the site and our own instance of the web server but we shared the same development database. I don't remember how the graphics designers worked, but I think they ended up moving to CVS as well. So a little more elaborate than what Greenspun describes. Basically CVS (or any other rev control system) works great with the html, scripts and SQL queries. It doesn't do much good with database schemas; changes to those end up being managed outside of CVS. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: how to make branch alias for HEAD branch
Victor A. Prylipko [EMAIL PROTECTED] wrote: I.m trying to make branch alias for HEAD branch using cvs admin -n ALIAS:HEAD file2.txt Try cvs admin -nALIAS:1 file2.txt. This assumes that your trunk revision numbers are still of the form 1.n . -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Using SSH with WinCVS
EdJ [EMAIL PROTECTED] wrote: I can't figure out how to use WinCVS to connect via SSH to a Linux-based CVS server. I need to use the ext protocol, because pserver is not secure. I've been using TortoiseCVS for months, but WinCVS seems like it just wants to talk to CVSNT as a server. Install PuTTY and make it work. Use public-key authentication. You can find more details in the TortoiseCVS FAQ, http://www.tortoisecvs.org/faq.shtml with links to the PuTTY web site. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Setting up first repository
Roddie [EMAIL PROTECTED] wrote: [a test repository] is a good idea and I've been trying it. I can log in OK, but when I try to import a trial project using cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/CVS import myProj no-vendor release-0 I get cvs [import aborted]: reading CVS/Tag: Not a directory. pserver ? Why not just :local:/usr/local/CVS ? No xinetd, no login, no passwords to set up... When you put a cvs server on your colocation box I recommend :ext: with CVS_RSH=ssh and public key authentication. I assume you already have the ssh part set up ? Othwerwise how do you reach your colocated machine ? I may also have Unix permission problems - I had to make CVSROOT chmod 757 (though there may be lesser options - Unix permissions are not instinctive yet!) The usual directory permissions are 770 + setgid to a group to which all the developers belong. The setgid bit (on Linux) is to make sure any subdirectories inherit the group of their parents. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVSIGNORE file help?
OTESAO [EMAIL PROTECTED] wrote: I have a whole bunch of files in my local client directory that I wanted to ignore whenever doing and update or commit to the server. [ ... ] Not sure what you want to do but: once a file is under CVS control, you can't ignore it. The .cvsignore and related options are for files *not* known to CVS. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Again: multiple vendors
Baurzhan Ismagulov [EMAIL PROTECTED] wrote: On Fri, Mar 04, 2005 at 02:42:56AM +, Pierre Asselin wrote: The multiple vendor branch was not funny, so I agree with Greg. I had to manually reset many admin -b values, move files in and out of the Attic (I think), etc. When I got to the point where a plain trunk checkout gave me a current main-vendor release, I could start working. Do I understand you correctly: it did work for you with import -b, right? Do you mean it would be easier to do with normal branches, applying upstream patches by hand and committing? That's one way, if you are careful about added and deleted files. In particular, I don't see why you had to reset admin -b values and move files in / out of the Attic; do you remember concrete scenarios? Because you get an inconsistent trunk. Example with two vendor branches: first bothimported to 1.1.1 both second imported to 1.1.3 If you check out a trunk sandbox, you get all three files, which doesn't correspond to anybody's release. The both that you get is the 1.1.1.1 revision, not the 1.1.3.1, because its admin -b branch is 1.1.1 from the initial import and was not reset by the second import. Hm, maybe it's not as bad as I think. I just tried this example and cvs warned me of a conflict. I don't remember that from before. Maybe the conflict detectors have improved ? This is cvs 1.11.17 . First import -- date first date both cvs import -m'main vendor' test VENDOR main-1_0 N test/first N test/both No conflicts created by this import -- Second import -- rm first date both date second cvs import -m'variant' -b 1.1.3 test VARIANT var-1_0 N test/second C test/both 1 conflicts created by this import. Use the following command to help the merge: cvs checkout -jprev_rel_tag -jvar-1_0 test -- I guess the broken trunk is just the normal result of an unmerged import. To standardize on the main vendor branch, cvs checkout -d test_main -j var-1_0 -j main-1_0 test and I get a test_main/ sandbox consistent with the first import. If I commit that, file second gets a dead trunk revision 1.2 and its admin -b branch is reset to empty. So maybe I could have saved myself all that surgery by doing proper post-import merges. Note that I gave my checkout -j options in the opposite order from the cvs suggestion because I want the trunk to look like the main vendor branch, not the 1.1.3 variant. Okay, so select a favorite vendor (you can't treat them symmetrically) and import all his tarballs normally. Do all your post-import merges religiously in order to take care of deleted files. THEN, start importing alternate vendor tarballs to secondary branches. Always do the post-import merges to trunk, but merge from -jjust-imported to -jfinal-main-import. After that, a trunk checkout should give you the equivalent of a fresh tarball from your privileged vendor. All the other tarballs are in CVS with unique import tags (keep good notes as you import) so you can start merging tarball deltas. BTW, you can do this in a private cvs repository on your own computer, accessed in local mode. If you stumble, wipe out the whole thing and start over. If you succeed, scp your repository tree to the real cvs server. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Setting up first repository
Roddie [EMAIL PROTECTED] wrote: I'm new to CVS, and I've been reading up about it for some weeks. [ ... ] I'm a one-man website developer. As things have turned out, I do relatively complex on-going work on a small number of sites. Development is on my OS X Mac laptop, and deployment is on my own RH Linux co-lo. The repository could be on either computer, but I plan to put it on the co-lo. You may want to dry-run this on your laptop. Run cvs init to start a repository, use it locally for a while, wipe it out when you have enough experience to init a new repository on your co-lo. The dry run is just to play with cvs commands for a while. You have a pretty strong incentive to switch to your final repository so you can distribute files to the live site through cvs. [ ... ] The shared directory holds libraries and other files needed by all the other sites. Each site uses symlinks so that the shared files appear to be in the correct place for that site. Sometimes it helps to think of your sandbox as the *source tree* of your web site rather than the web site itself. Planting the symbolic links is now a trivial compilation step that you perform after checkout or update. This should be scripted, and the script should be part of your sandbox, under revision control like the rest. I plan to have the sites directory as the project. There would be three sandboxes to start with: a development sandbox on the Mac laptop; a test sandbox on the co-lo (to iron out any MacLinux issues); and the live sites in a sandbox on the co-lo. Sounds good. Normally, development will take place on the Mac, be committed, the test sandbox updated, tested and committed, and then the live site sandbox (and the Mac if necessary) updated. Or you could have a scripted installation step to copy the test sandbox to the live site, which may or may not be a CVS sandbox. Occasionally I make changes direct to the live site. These are usually trivial updates of content, but remembering to make them also in the development files is a nuisance. In this instance I would make changes to the live site, commit them, and then update the development sandbox. Then your live site should be a sandbox, and it should be on a branch. Otherwise, you won't be allowed to commit your trivial tweaks without first running an update, and that would force you to deploy changes sooner than you would like. Having a release branch is pretty standard. You fix bugs on the branch and merge them back to the trunk so you don't have to fix them twice. When your trunk is good, you cut a new release branch and update the live sandbox to the new branch. Post again if the process is not clear to you. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Again: multiple vendors
Greg A. Woods [EMAIL PROTECTED] wrote: Multiple vendor branches CANNOT work for what you want. Period. Maybe with the new import -X in cvs 1.12.x ? This was touched upon briefly in another thread. https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_16.html#SEC154 I once did a two-vendor series of imports after gathering historical tarballs from the net. The main vendor went on 1.1.1 and the secondary went to 1.1.3 . The purpose was to merge some of the patches in the secondary line into a late main-vendor release. The multiple vendor branch was not funny, so I agree with Greg. I had to manually reset many admin -b values, move files in and out of the Attic (I think), etc. When I got to the point where a plain trunk checkout gave me a current main-vendor release, I could start working. The net result of all the imports plus surgery is that I had my tarballs in CVS, each with a unique tag. I could diff any two of them, examine the patches, decide what to apply, etc. That part went very well ! The fact that the tarballs were on vendor branches was pretty irrelevant. The new -X import seems to create independent, non-interfering vendor branches (and an empty trunk!). The OP could try that, merge one of them to the trunk and start merging deltas. It might work without surgery. Then again, I havent' actually done it, this is just an impression from reading the docs. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Again: multiple vendors
Baurzhan Ismagulov [EMAIL PROTECTED] wrote: Could a Branching Expert please help me drawing the same for my needs? I've got 4 upstream vendors and want to keep them in different branches. I have two goals: importing new upstream versions and merging the deltas into the main trunk, and tracking which change introduced a particular bug. [ complicated, reticulated branching diagram omitted ] Maybe something simple: /1.1.1 / MAIN 1.1 \ |\ LINUS | \1.1.2 | \ |\ RMK | \1.1.4 | \ |\ PXA | \1.1.6 | \ \ HWVENDOR\1.1.8 That is: ALL of them branched from 1.1 . The MAIN series is imported on a vendor branch for convenience, but all others are regular branches off of the first trunk revision. (Maybe the MAIN series should be a regular branch too.) Or maybe the common branch point can be the tip of the trunk after the main import, so you'll have weird branch numbers like 1.1.1.12.8.x different for each file. Doesn't matter, don't look at the numbers. I don't think the actual branch structure matters. What you do want is all the various releases *somewhere* in the hierarchy, and *tagged*. Keep good notes about your tags. Your notes *should* have the filiation of the various releases if known, but only for reference. With tagged sets in your repository you can look at diffs and merge abritrary deltas to your trunk. That should be enough (but you have a hell of a lot of vendors !). To start a new vendor series you would probably do something like this. cvs checkout -rCOMMON_BRANCHPOINT the_mess cd the_mess : : start new branch cvs tag -b LINUX cvs update -r LINUX : : remove all files, keep CVS metadata : (not tested) find . -type d ! -name CVS | while read d; do (cd $d rm *) done : : Overlay first tarball cp -r path/to/fresh/tarball/* . : : See what files are new or removed cvs -nq update -I! -ICVS : : U or P files need to be cvs-deleted : ? files need to be cvs-added : ? directories need to be recursively added M files can stay : cvs commit cvs tag LINUX-1 : : remove all files again, : overlay second tarball, repeat As Greg Woods said, if your vendors do a lot of file renaming and directory remodeling CVS will lose. You won't be able to do effective automated merges and you'll need a more powerful tool. Looking at your branch names, this may be a job for bitkeeper... I know nothing about bitkeeper, other than it was designed for insanely decentralized development. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: vendor/local files in CVS
Mark D. Baushke [EMAIL PROTECTED] wrote: New imports are always on the vendor branch with -X and 1.2 is always dead. So, the trunk is no longer ever potentially broken. Hmmm, I see. I had read the 1.12 documentation at https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_16.html#SEC115 and it didn't occur to me that all the files are new during the initial import. So if you check out a trunk sandbox after the initial import -X, you get an empty ? I can see a new FAQ being born. How do you do the initial merge, with just one -jVENDOR ? Hey, multiple vendor branches should work now. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: vendor/local files in CVS
Mark D. Baushke [EMAIL PROTECTED] wrote: Pierre Asselin [EMAIL PROTECTED] writes: ... It's important to understand that each import after the first *breaks the trunk* until the merge has been successfully committed. Note that if you are using cvs 1.12.x, you may find the -X option to be of interest as it does NOT put an import branch into the mainline directly. Instead, a dead version 1.2 is created on the first import. So files added by the vendor don't show up on the trunk, but in the meantime the trunk is still potentially broken. Suppose the vendor made changes to several closely related files, some but not all of which had been modified locally. Immediately after the second import, the two classes of files are no longer in sync on the trunk. The locally modified files are still at revision 1.2 and have only your changes. To pick up the new vendor changes in these files, it is essential to merge the import and commit a new revision 1.3 . -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: vendor/local files in CVS
Bob Fyfe [EMAIL PROTECTED] wrote: We receive source code from a vendor which consists of many files (call it version 1). Ok so far. That source code requires running a 'make' to set up the environment from the tar file they distribute. Fine, but the 'make' has nothing to do with CVS. Subsequently, several files have been changed. Additionally, several files have been created. So at this point you have vendor source files and several localized files (i.e. vendor files modified and new locally created files). Still ok, this is a fairly routine use of CVS. This would be an easy scenario to put things into CVS - you could just put all of it, vendor and locally modified files there. Not like that. There are several steps. 1) Import ONLY the vendor files into CVS. 2) Check out a sandbox. 3) Work in the sandbox. Change files, add new files, run make. 3b) Do *not* run cvs add on the products of the make. Those are generated files and it is best to manage only source files. 4) Commit the changes in the sandbox. The problem I am trying to conceptualize before it happens is when the vendor provides a new release with new vendor source files and new versions of the locally modified set of files. You tag your trunk, import the newly received files, and merge the import to the trunk. https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_13.html#SEC103 This takes a bit of getting used to. It's important to understand that each import after the first *breaks the trunk* until the merge has been successfully committed. Sometimes the vendor changes don't merge cleanly, so it is a good idea to tag the trunk before importing. Having a tag allows you to recover your last good copy while someone figures out how to finish the merge. In extreme cases you can branch from the last good trunk point and continue working as if the import hadn't been done. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Latest Versions in Separate Folder than Repository
[EMAIL PROTECTED] wrote: I've had a CVS set up, but an idea crossed my mind. Is there a way to make it so that cvs will keep the latest versions of the files in the repository (in their working form, not diff form) on the server in a folder separate from the repository? With the loginfo file. The on-line manual has a worked example that updates a reference sandbox on every commit. https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_18.html#SEC158 The reference sandbox can even be on another machine, if the server has the ability to run remote commands on it. For instance, with a repository folder 'C:\CVSRepo' with module 'code', whenever someone commits a change to the module would it be possible to have the module 'code' be checked out on the cvs server in a folder separate from 'CVSRepo'? Ie 'C:\latestCode'. On Windows ? Oops. Well, the loginfo file should work as everywhere else, but you'll have to translate the bash example in the docs to some other scripting hack supported on Windows. I wonder if the wincvs folks have a similar example in their docs? I found the exact same example on their site, but not translation to Windoish. Basically, your loginfo hook has to *schedule* an update of the reference sandbox after a small delay and exit before the update begins. That allows the triggering commit to release its repository lock before the update fires up. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Which combination of CVS-Tools can be recommended in a (Windows-Linux) Client-Server environment?
Christian [EMAIL PROTECTED] wrote: I'm currently installing a linux-server with red-hat 9. There are a few clients that run on Windows XP or Windows 2000. Now I have to make thoughts which CVS- tool to take, because it is planned to use CVS for source control. Has someone made experience in such a client-server environment? Yes. Server: stock CVS on Redhat 7.2, access through ssh with public key authentication. I create user accounts as needed and copy public keys to the ~/.ssh/authorized_keys files. Oh, and I installed viewcvs under apache because some users find it useful. Linux clients: stock CVS and ssh. Windows clients: TortoiseCVS, with PuTTY for the ssh access. Can someone recommend a combination that runs stable. Currently I would tend to install cvs-1.11.18-cvshome.org.9x.1.i386.rpm but I would appreciate very much if someone could give me a hint which versions/tools to take. Like I said, I just used the stock binaries that came with my boxes. This is not a big team and software development is not our primary function by a long shot, so we're not exactly stress-testing the setup. The RH 7.2 dates from my starting day. I know it looks old now, but it still works fine. This is on an intranet, so I don't have to be too paranoid about security. The apache is probably the biggest hole ! At my previous job we had a Linux server and various clients with a small but very active team (as in: update three times a day or you'll be left behind). As far as I know the server was whatever Redhat release was current at the time and the CVS was the stock install. Worked fine. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: user permissions of files and directories
Matthias Friebe [EMAIL PROTECTED] wrote: I was unsuccessfully checking several CVS documentation for user permissions in CVS. Larry already pointed you to the docs on cvshome.org, so start there. Note the bit about LockDir in CVSROOT/config, which is necessary if you plan to give read-only access to some people. What we want to do is give explicit read permissions to users for files/directories. By default a user should have no read or write access to files/directories unless we specify that they do. Set up a LockDir and give write access to everyone. I think the LockDir should be 0775 + setgid and everyone should be in the LockDir's group. The project directories should be 0775 + setgid, with one group per project. The project developers need to be in the group in question so they have write access. Everyone else has read access, which is more than you want. To block read access selectively, place each project tree under a gatekeeper directory, permission 0750, with yet one new group per project. People with read-only or read-write access access need to be in this gatekeeper group. Others aren't, and this is where they lose their read access. /var/ cvslock/rwxrsxr-x lockgrp $CVSROOT/ proj-1-gate/rwxr-x--- proj1grpR proj-1/ rwxrsxr-x proj1grp proj-2-gate/rwxr-x--- proj2grpR proj-2/ rwxrsxr-x proj2grp A user not in group lockgrp has no access. A user in lockgrp only still has no access. A user in lockgrp and proj1grpR has read access to project 1. A user in lockgrp, proj1grpR and proj1grp has read-write access to project 1. Any other combination of lockgrp, proj1grpR and projgrp would be an error. Since each project is buried one directory deeper than normal you would set up appropriate definitions in CVSROOT/modules to skip the intermediary gatekeeper directory. If this is to be retrofitted to an existing repository, moving each project down is going to be a one-time nuisance. Either tell everyone to commit their work before the move and check out new sandboxes afterward, or let the braver ones edit their sandbox CVS/Root directories. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: RV: Newbie question. How to manage replaced files
N?stor Bosc?n [EMAIL PROTECTED] wrote: I have been using CVS for some time and have encounter problems when somebody gives me a file that I have to replaced in my CVS sandbox. This always happens because sometimes I have people outside the organization and they send new versions of files that I have to replace in the sandbox and try to update and commit to the CVS Repository. What is the best way to manage this case? I would figure out what revision of the file the external user started with. Then I would create a branch at that revision, commit the modification to that branch and see if I can merge the branch back to the trunk. By extension, if people send you patch of the entire source tree, *based on a released version*, you can branch the entire tree off the corresponding release tag, apply the patch, commit, and decide whether you want to merge the branch. If you can't determine the revision or tag from which to branch, you probably need to tighten your controls a little... -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cancel the last commit
Jehan PROCACCIA [EMAIL PROTECTED] wrote: [ ... ] $ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs update -A [ ... ] RCS file: /var/cvs/trombintDev/easyExtract.php,v retrieving revision 1.3 retrieving revision 1.4 Merging differences between 1.3 and 1.4 into easyExtract.php easyExtract.php already contains the differences between 1.3 and 1.4 RCS file: /var/cvs/trombintDev/identification.php,v retrieving revision 1.9 retrieving revision 1.11 Merging differences between 1.9 and 1.11 into identification.php rcsmerge: warning: conflicts during merge cvs update: conflicts found in identification.php C identification.php It's hard to reconstruct what happened from where I sit, but you must have been on a branched sandbox *with uncommitted changes* before you did the update -A. An update is always a three-way merge between 1) the files in your sandbox 2) the files you started from 3) the files in the repository at the tip of the trunk or branch you are updating to. If you commit before the update, (1) and (2) are identical, so the update amounts to replacing (1=2) by (3). I assumed that you committed all pending changes to the branch before returning to the trunk so I'm not sure what happened. (Of course nontrivial updates are the bread and butter of normal work on the trunk, where cvs forces you to update *before* committing your changes. Conflicts happen in those cases, too, that's normal. But you were on a branch by yourself, I thought you could commit everything. Bah.) Okay, you can see what kind of damage there is and try to repair the conflicted files, or ... I was wondering if I could do something simpler: 1) I save the manipulations above: [EMAIL PROTECTED] /var/www/html/ldap] $ mv trombintDev trombintDev.update-A 2) Get the trunk code [EMAIL PROTECTED] /var/www/html/ldap] $ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs checkout -r trombint-2-0-0 trombintDev Yes, much easier, but see below. 3) Then copie/replace from my backup of the new/beta feature set every newmodified files to that fresh checkout $ cp /tmp/trombintDev/identification.php ./trombintDev/ $ cp /tmp/trombintDev/cas-header.php ./trombintDev/ Be careful, the trunk seems to have advanced while all this was going on. Make sure that identification.php and cas-header.php haven't been modified by others, or you will be clobbering their changes. I say, was that how the conflicts happened ? If so you may be better off cleaning up the conflicts in trombintDev.update-A. In any case, what you want is a sandbox that 1) is on the trunk, and 2) has all the new/beta/semibroken changes in it. 4) After I have put back all the newmodified files into the sanbox (./trombintDev), I will just have to commit ! no need to put -r trombint-2-0-0 it will go there (trunk) anyway ? Right. Just plain commit, to the trunk. I don't really understand this -A option but I tried it ... (see above) Think of it as a strange way to say update -rnothing. (Actually it's more like update -rnothing -Dnodate -kdefaultkeywords ) If view of the confusion, I would double-check that the trunk didn't lose any work. Run cvs log on the affected files and note which revisions were committed by you and which ones by others. Run cvs diff between consecutive revisions and make sure that your changes don't include rollbacks of other people's changes. Similarly, on the stable/bufix branch make sure that all the new/beta stuff is completely gone. You more or less have to do that anyway, since having beta stuff would be a bug and on that branch you're fixing bugs. Good luck. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: FW: can I checkout up to three branches into one workspace?
Mark Hanna [EMAIL PROTECTED] wrote: Pierre, We don't ship src, but are currently in the situation where we have numerous branches all with customer specific areas which are pulled into the build. The maintenance of these branches with fixes having to be merged between several branches has become time consuming for our small development team, so I've been tasked along with the chief architect to come up with a sensible solution which can quickly improve things before a new batch of customers comes on line. I'll tell you how I would do it, but *it does not scale well*. I'd say it's O(N) in the number of customers and I don't think that's good. Now if you already use a branching scheme that's O(N^2) I suppose that's an improvement, but still... One alternative I'm looking at is a method of checking out the build combination (stable point + patches +customer files) into different directories and using ant to script the compilation. Do think this is reasonably easy to achieve or would you suggest something better ? See, thats what I don't understand. ant is like make for Java, right ? Why can't the ant script be parametrized by customer and take appropriate actions using the appropriate parts of the source tree ? *That* scales well. Anyway. Avoid long-running branches. Get a trunk with generic features only. At some point, tag the trunk and create a branch for each customer. cvs tag base_1 cvs tag -b customerA-1 cvs tag -b customerB-1 ... Go on each branch and put the custom feature for the customer. cvs checkout -r customerA-1 the_project cd the_project make custom changes for customer A cvs commit cd .. cvs release -d the_project # repeat for the other customers Your revision tree now looks like a linear trunk with N little stubs at the basepoint. *-- generic only /|\ / | \ / | \ A B C Now the release process looks like this: 1) Tag the trunk. 2) Start a release/bugfix branch. 3) Stabilize the release branch. 4) Tag the release branch when ready to release. So far this is standard CVS fare but it handles only the generic code with zero customizations. (on a trunk sandbox) cvs tag product_release1_bp cvs tag -b product_release1 cvs update -r product_release1 (stabilization begins) cvs commit cvs tag product_release1_0 Now the O(N) customization process begins. For each customer, 4i) Create a branch off the release point. 5i) Merge the little stub to the new branch.e cvs checkout -r product_release1 the_project cd the_project cvs tag -b product_release1_0_customerA cvs update -r product_release1_0_customerA cvs update -j base_1 -j customerA Conflicts ? Deal with them. You have to expect conflicts and you have to fix them by hand, therefore this process *can not be automated*. When the conflicts are fixed, you are not done. You just made nontrivial changes to a sandbox and you need to test the custom functionality. You also need to test the generic functionality in case it got wrecked by the customizations. WHEN all testing is complete, you can cut a custom release off the branched release branch. After a while your revision tree looks like this: ---*---Xtrunk /|\ \ / | \ \ / | \ \ A B C *-*--release /|\ /|\ / | \ / | \ / | \ / | \ A B C A B C So you keep SHORT branchlets with customizations and ONLY customizations. You re-graft those branchlets up the release branches by the techniques shown above and you test. Eventually the original branchlets become too rusty to keep up with the trunk and you get too many conflicts at release time. When that happens just stop using the originals and declare that the branchlets of the last successful release are now the references for customer-specific changes. That's my process and I think it sucks. It's ok with three customers, but what if your company grows to 20 ? 100 ? 1000 ? I would MUCH rather have a unified project tree with customer-specific features segregated to subdirectories, say. I would create the customized releases *at build time* with parametrized scripts. I would also maintain a unified test rig to keep all the variants under control between releases. I understand that Java tools like to impose a directory layout that may interfere with what I say, but there must be a way. The ONLY good thing I have to say about my branchlet scheme is that it is harder to leak intellectual property between customers that way because the trunk and release branches are completely
Re: cancel the last commit
jehan.procaccia [EMAIL PROTECTED] wrote: Great I've managed to rollback to a stable revision with the above doc. Now I want to keep that stable revision in production, and create a branch for new/beta features or a branch for the *stable* codeline, leaving the new/beta stuff on the trunk. But it's up to you. Personally, I only branch new stuff when it is really speculative and there is an even chance that it will be abandoned. Otherwise, it goes on the wild trunk. so I tagged that revision : [EMAIL PROTECTED] /var/www/html/ldap/trombintDev] $ cvs tag -c trombint-2-0-0 . Excellent. I want to keep patching if needed that production revision an keep developping new features, so I created a branch: $ cvs rtag -b -r trombint-2-0-0 trombint-2-0-0-patches trombintDev Excellent. Your branch is for the stable codeline and the new stuff goes on the trunk. It really is easier that way. If your new/beta is too speculative for the trunk, post again and we'll see how to branch that. From the CVS doc I can see how to update from any different branch : https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_5.html#SEC57 But how do I commit to one branch or an other ? After you update -r trombint-2-0-0-patches as the above URL directs you to do, try a cvs status somefile. You'll see that the file (every file, in fact) has a sticky tag of trombint-2-0-0-patches. This stuff causes endless confusion. The tag is stuck to your sandbox; what it means is that when you run a cvs command from that sandbox, there is an implied -r trombint-2-0-0-patches as if you had typed it on the command line. In particular, any changes you commit from that sandbox go to the branch and not the trunk because of the implied -r. Similarly if you update, you get changes that others committed to the branch and nothing from the trunk. When working on the production files, I want to commit to branch trombint-2-0-0-patches so just commit from the branched sandbox and when I work on the new features working set I want to commit to trombint-2-0-0 branch correction, commit to the trunk. trombint-2-0-0 is not a branch, it's a (set of) revisions and you can't commit to that. Do a cvs update -A and try a cvs status again. You'll see that the sticky tag is gone. You will also notice that any changes you committed to the branch have been undone. You're back on the trunk. An alternative to flipflopping your sandbox like that is to go to another directory and checkout a brand new sandbox. One sandbox is for the stable line, the other is for the new stuff. ! The problem is that the new features working set was checked out before I tagged and branched the repository. but you rolled it back ! Or so you said at the beginning of the post. You must have, otherwise the tag -c would have complained that you had uncommitted changes. The branch really starts at a stable point. Your most difficult task will be to un-rollback the beta stuff on your trunk sandbox (and it probably won't be that difficult). Your revision tree is perfectly fine, it just has a little wart: wart | | v stuff---stuff---betastuff---rollback---betastuff--- ... | | +bugfix---bugfix--- ... I read from online doc https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_16.html#SEC126 section : A.9.2.2 Creating the branch after editing [[ hacked sources are present ]] $ cvs tag -b EXPR1 $ cvs commit -r EXPR1 You don't have that problem. Your hacked sources were already committed, so it was too late to follow these directions. It doesn't matter because you rolled them back. Your branchpoint was a clean, stable baseline. I recommend that you update -r trombint-2-0-0-patches if and only if you want to work on the *stable* code. Otherwise, update -A. Now about un-rollingback the unstable code you rolled back. You know what the files were, don't you ? the same ones you rolled back. Do them one by one. cvs update -A # just to be safe cvs status -v file_number_one The -v will give you the low-level revision numbers corresponding to all your tags. Let's say trombint-2-0-0 is revision 1.48 for this file. 1.48 should be identical to 1.46 and 1.47 is the one you rolled back. So, cvs update -j 1.48 -j 1.47 file_number_one and you have the unstable file_number_one again, ready to be committed as 1.49. Repeat for the other files, cvs status -v file_number_two cvs update -j 1.11 -j 1.10 file_number_to # or whatever cvs status -v file_number_three and so forth. When this is over you will have returned right back to your starting point: broken code in the sandbox. Clean it up if you can and commit. If you can't clean it up yourself go ahead and commit the broken code, tell the other
Re: can I checkout up to three branches into one workspace?
Mark Hanna [EMAIL PROTECTED] wrote: We want to reconstruct our code base within one module that already exists. Currently we branch a copy of the entire src of the module onto a branch and develop it specifically for each customer but due to the increasing number of customers we want to change the way we work. Before we go any further, do you ship sources ? If not, why can't you have an integrated source tree supporting all variants and select the customer variant at build time with conditional compilation and similar tricks ? [ ... ] The idea is to keep a generic branch and at a validated point, branch off individual files onto customer specific branches (i.e. customer_A, customer_B, etc). This point will also be used to create a branch for fixes. [ ... ] Yeah, it can be done, but it's a lot of trouble. I would look at alternatives first. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: Q on keyword substitution]
jsWalter [EMAIL PROTECTED] wrote: It's -kv, not '-ko'. '-kv' removes the keyword (and the bracketing $$) and leaves only the value. OK, but doesn't this strip ALL the keywords? Yes. It's all or nothing. and you have to be *very* careful with the spelling of '$Revision: $' when you add a new line in the file you're editing. [ ... ] OK, you lost me here. 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. My suggestion was to use a spelling that can be checked by a utility, and to enforce that check in a commitinfo hook. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Advice regarding Branches
jeetu mahtani [EMAIL PROTECTED] wrote: [ ... ] Since we may need to do patch releases in the interim I have both of them working in their own branches to isolate Main. The usual approach is to start a support branch at every release point. Your patch release would be done off the support branch and (probably) merged to the trunk. Your support branch would contain zero new features. Features belong to the trunk, in preparation for later releases. Doing it that way, both of your enhancements could probably have been done on the trunk. Doing development on a branch is a bit of trouble, as you are finding out, so it is normally done only if the work is speculative and you want to isolate the trunk from it. [ ... ]. The first developer with the long term enhancement needs to see the enhancement done by the second developer (for some reason) so how I bring his branch up to do? The way I said before: transfer his work to a new branch and kill the old one. : (initially on the oldbranch...) cvs commit : to oldbranch cvs update -A : return to the trunk cvs tag newbranch_bp: mark where you are cvs tag -b newbranch: start a new branch cvs update -r newbranch : get on newbranch : bring in the work from the old branch cvs update -j oldbranch_bp -j oldbranch : fix conflicts cvs commit : to newbranch I guess by tagging the Main at the appropriate point in times, I can update his Branch but it just seems such a cumbersome and time consuming process (of continuouslly tagging and keeping track of tags). Updating the branch is not the problem. The problem is when you try to merge that branch back when the work is finally done. Unless you planted tags at just the right places and use them in your merge, you'll get spurious conflicts. It's best to merge unidirectionally, always from branch to trunk. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: Q on keyword substitution]
jsWalter [EMAIL PROTECTED] wrote: Try 'cvs admin -kv'. Try it on a test repository first. Well, doesn't this tell CVS not to proces *any* keywords on this particular file? It's -kv, not '-ko'. '-kv' removes the keyword (and the bracketing $$) and leaves only the value. Your files will end up looking like this: * Since $Revision: $: still working * Since 1.24: ladidda badabba * Since 1.23: tamtidelam and you have to be *very* careful with the spelling of '$Revision: $' when you add a new line in the file you're editing. I recommend ending it with a colon and space before the dollar, as above, so you can verify the presence of the keyword with the RCS command 'ident' before you commit into cvs. Maybe even in a commitinfo script ! -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: Q on keyword substitution]
jsWalter [EMAIL PROTECTED] wrote: I'm using phpDocumentor and would like to have the '@since' tag auto insert the CVS file version, but not change it the next time the file is submitted. this... * @since $Version: $ to become... * @since 1.24 not... * @since $Version: 1.24$ Try 'cvs admin -kv'. Try it on a test repository first. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can't download CVS!
Larry Jones [EMAIL PROTECTED] wrote: TortoiseCVS (http://www.tortoisecvs.org/) is another GUI that runs on top of some CVS implementation, but I don't know whether they bundle a CVS implementation with it or not. When I installed mine, it came with a CVSNT binary. You then have to hook this binary up in the TortoiseCVS Preferences menu. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Advice regarding Branches
jeetu mahtani [EMAIL PROTECTED] wrote: We have several developers working on various branches. One of the developers is done with his fixes so I merged his branch into the Main trunk. Now the other developers who are working on their respective Branches need to also get these fixes. Why ? Why can't they finish their branch and merge them too ? Why are they working on branches if they don't need to isolate themselves from the trunk ? How do I make this Merge so the various developers are up to date with Main trunk updates? Thanks. Start new branches up the trunk and merge the old branches into them. cvs commit # to oldbranch cvs update -A cvs tag newbranch_bp cvs tag -b newbranch cvs update -r newbranch cvs update -j oldbranch_bp -j oldbranch cvs commit but I repeat: something's fishy with your approach. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Newbie Questions
Larry Jones [EMAIL PROTECTED] wrote: If you want to use CVS outside of Eclipse, you may also be interested in WinCVS which provides a nice GUI and includes CVSNT: http://www.wincvs.org/ I would recommend that the OP try http://www.tortoisecvs.org instead of WinCVS. In my opinion WinCVS is more complicated than the command-line interface! TortoiseCVS has reduced functionality but also has a much shallower learning curve. I would also recommend 1) learning CVS independently of Eclipse; 2) finding a better forum than this place for the inevitable Eclipse questions. We just don't have the expertise here. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Trying to recommit lost commits due to hard disk failure
Edd Barrett [EMAIL PROTECTED] wrote: I have an issue with my cvs repository. I had a disk failure and I lost it. After recovering a backup from about a month ago, I thought Id be able to simply re-commit the changes. If itry it gets furious that there is a huge gap in revision numbers. What is the best plan of action in this case? Development has come to a complete halt due to this... hum... I vote for checking out brand new sandboxes off to the side, copying the latest files you have from your old sandboxes, and committing the lot. You lose the history between the crash and today, but that's what crashes do to you. If all developers do that independently, the first one to finish gets in and the others have to deal with amusing conflicts. So deal with them. I really think this is the path of least resistance. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge and CVS Headers ... best practice?
MumboJumbo [EMAIL PROTECTED] wrote: I keep getting merge conflicts in CVS headers ... its not a big deal ... but it is very annoying ... is it common practice to use CVS headers branching together ? I use update -kk -jstart -jfinish when I do my merges, where the -kk option prevents any keyword expansion conflicts. After I commit the merged sandbox, I get rid of the sticky -kk with an update -A. ps my cvs header is a nice simple: [ ... ] // $Log$ Except that one. Don't use $Log$, it's a conflict generator. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: ## Need help to configure CVS ##
[EMAIL PROTECTED] wrote: i'm the newbe to CVS. I'm working in a project that needs to use CVS. I have linux server and windows workstation. We r doing projects in Eclipse IDE under windows. The only thing I can tell you is that you will need to run cvs init on the Linux server. After that, your problem becomes an Eclipse question and you're not going to find much expertise on Eclipse here. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs ignore feature
Jeff Decker [EMAIL PROTECTED] wrote: [ ... ] My question is I am getting the project from a repository that already has files in it but once I get the file I want cvs to ignore any future changes I make to the file. As others have told you, cvsignore won't do that. The reason I need to do this is because we have build scripts that I will modify to work on my system but if I commit the changes then it won't work on the official build machine. What you should do is try very hard to modify the scripts so they work on all systems. Writing portable code is such a joy. If you break a script, I'm sure your colleagues will let you know. Having said this, you could deliberately plant a sticky release tag on the files that get changed, to make sure you never commit the changes. I think this will work, cvs update -rBASE file1 file2 ... but you may have to do it manually by revision number, cvs status file1 cvs update -r1.whatever file1 ... If you now try to commit one of these changed files, you will be tossed out. To commit your tree wholesale, minus the bad files, you'll have to get the unmodified versions, rm file1 file2 ... cvs update file1 file2 ... U file1 U file2 ... cvs commit If the files have changed in the repository, the only way for you to get the new versions is to remove the sticky tag and plant a new one. rm file1 file2 ... cvs update -A file1 file2 ... cvs update -rBASE file1 file2 ... # I hope Omit the rm command if you want to merge your changes into a local copy of the latest, instead of starting from scratch. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: problem adding files to a branch
Jean-Pierre Sevigny [EMAIL PROTECTED] wrote: $ cvs add test.txt cvs add: cannot add file on non-branch tag uwap_3_1-RELEASE Do you have a CVS/Tag file ? If so, what does it contain ? -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Tagging files
Kristian Bisgaard Lassen [EMAIL PROTECTED] wrote: $ cvs tag test cvs server: [17:52:46] waiting for krell's lock in /users/cpntools/repository/cpn2000/sml/statespacefiles What can I do to get the files tagged? Did you look specifically, on the server, in $CVSROOT/users/cpntools/repository/cpn2000/sml/statespacefiles ? That's where you're likely to find the stray lock files. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: [QUAR]Re: CVS, RCS, System Files
Larry Jones [EMAIL PROTECTED] wrote: Pierre Asselin writes: Yes, it is routine. You can even use RCS and CVS at the same time on the same project, they will mostly ignore one another. That's not quite true. It's perfectly safe to use both to *read* files, but you can lose changes if you use both to update the same file at the same time because they don't use the same locking mechanism. Good grief, not like that ! I mean using RCS in a sandbox, behind CVS' back. sandbox mkdir RCS sandbox ci -l sandboxfile sandbox cvs update sandboxfile sandbox ci -l sandboxfile sandbox cvs commit sandboxfile stuff like that. It never occurred to me to run RCS commands on $CVSROOT/path/sandboxfile,v because my $CVSROOT is usually remote. Using RCS that way is a little like creating a private branch in CVS, but more lightweight --and less organized. I do that when I am making intricate changes, I want the option to backtrack, and I don't want to commit broken code to CVS. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: pserver access with IP
Clevo [EMAIL PROTECTED] wrote: The reason why I need [ to refer to the server by IP number ]: We have a CVS server with fix IP. And users with various PC, notebooks where we can not (or must not) change system and network settings. As the CVS server has it's own domain name only in the copany office private network I can't access the CVS server from a Windows notebook(can not resolve the name) You say that, but the error below is not a domain name resolution problem. We connect with pserver: :pserver:[EMAIL PROTECTED]:/home/cvsroot That should work. The error message: cvs commit: failed to create lock directory for xx Permission denied which says that you *did* connect to the server, and it returned an error because its directory permissions aren't set up right. All cvs users should be in some group created for the purpose, and all directories under $CVSROOT should be writable by that group. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS, RCS, System Files
Call, Wayne [EMAIL PROTECTED] wrote: Is it feasible to have both CVS and RCS on the same computer? Yes, it is routine. You can even use RCS and CVS at the same time on the same project, they will mostly ignore one another. I would like to control the source code files for various projects using CVS, and control the system files, such as files in the /etc directory, using RCS. I maintain my system files through RCS all the time. What I do is create a directory, populate it with symbolic links to the system files, and RCS-manage the symbolic links. # mkdir configuration # cd configuration # ln -s /etc/hosts .# for example # mkdir RCS # ci -t-/etc/hosts hosts # rcs -ko hosts # in case there are RCS keywords in it # co -l hosts # ./hosts is now a copy # ln -fs /etc/hosts . # ./hosts is now a symbolic link again # # vi hosts # make changes ... # ci -l hosts # ... and preserve the history RCS knows how to follow symbolic links. Note that CVS doesn't (by design) so you couldn't use it that way. The little chore of setting the '-ko' flag and creating the link a second time is to make sure that 'ci -l' doesn't try to rewrite the file in order to expand keywords like $Id$. If it did, it would also break the link. The CVS is used to archive the source code files, and the RCS [if it works with CVS] is used to archive the system files on a file per file basis. Will the CVS work together with the RCS? As I said, they work together just fine. Your case is even simpler, because you want to use them separately. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: not all files get imported
Spiro Trikaliotis [EMAIL PROTECTED] wrote: * On Tue, Nov 30, 2004 at 06:56:04AM - manisha r sankpal wrote: [EMAIL PROTECTED] test_prj import -m log msg test_prj username start but this command fails to check in one directory into the cvs. this dir contains only one *.o file. [ ... ] If you want to circumvent this, use -I ! on your cvs import. Spiro is correct. To this I add: if you want to repair your import just *repeat* it, this time with the -I! option. Be sure and use the same release tag as in the initial, partial, import. Oh, and this assumes that you do want the .o file in your repository. If you just want the directory but not the file, that can't be done. CVS won't import empty directories. Workarounds would be 1) modify your build system to create the directory after checkout, if it is missing; 2) add an empty .dummy file before the import, so the directory is no longer empty. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs vs. clearcase?
Mike [EMAIL PROTECTED] wrote: I have a director asking why I don't want to user the company's clear case server. One item I mentioned is the lack of integration into unix tools and the lack of a unix client. Are these good/valid reasons? What are other reasons? No Unix client ? I thought there was one, you'd better research that a little more. I need more context here. Is the rest of the company already using ClearCase, supported by the IT staff and with a pais up license ? Would you be working on joint projects ? If so, get the staff to install the client on all your machines, get yourself trained, join the team and add the bullet point to your resume. If however *you* would be in charge of administering CC locally, the picture changes. You can draft an estimate of conversion costs, including: licenses, training, staffing. CC doesn't run itself. You didn't list the alternatives. What rev control system would be using if CC wasn't in the picture ? -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Where am I at this moment?
Galen Boyer [EMAIL PROTECTED] wrote: I ran an import and then tried to checkout and it failed cannot find module (yes, I didn't commit). That's a little confusing. Can you cut and paste the exact commands you are using and the exact error messages ? -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Importing then checking out?
Galen Boyer [EMAIL PROTECTED] wrote: $ cd ecb-1.93 $ cvs import -m Import of FSF ECB v. 1.93 grersrepository/ecb FSF_DIST ECB_1_93 I get the following: No conflicts created by this import That's better. So far, so good. Okay, now I try to commit this (I assume I need to commit?) No. Don't commit, you can't. cvs commit cvs1 commit: in directory .: cvs1 [commit aborted]: there is no version here; run 'cvs1 checkout' first See ? There is nothing to commit. Okay, so I try to check this out: $ cd ../ecb $ cvs checkout ecb Try: 1) cvs checkout grersrepository/ecb or 2) cvs checkout -d ecb grersrepository/ecb or finally, 3) cd /some/where/else cvs checkout CVSROOT cd CVSROOT : edit the modules file and add a line, :ecb grersrepository/ecb : and save that. cvs commit cd /some/clean/directory cvs checkout ecb Our repository name is grersrepository. What is the / for? Is ecb a module, or do I consider it a new repository? Ok. Your repository is whatever your $CVSROOT environment variable was when you ran cvs init on the server. The subdirectories under that are modules. Actually, any subtree starting as deep as you like can be a module, provided you set things up that way. After the cvs init, there is a single module, CVSROOT. Not $CVSROOT, just CVSROOT; yes, it's confusing. That predefined module contains the cvs administrative files. After your import, there is a new module grersrepository/ecb, which you can check out by that name. That's my suggestion (1) above. However, checking out in this way will give you a sandbox buried one directory deeper than necessary. To avoid that, you can say check out grersrepository/ecb, but put it in a newly created local directory ecb. That's my suggestion (2) above. Finally, if you put a definition in the modules administrative file, you can have a module called just ecb, that you can check out as such, but that really begins at grersrepository/ecb in your repository. That's my suggestion (3). So how do you get to the modules administrative file ? by checking out a copy of it from the built-in CVSROOT module, adding your definition of ecb, and commiting the changes. (The real fun begins when you download ecb-1.94 and you want to do a second import. Post again before you do that. Really.) -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: line of command in windows
Gleidson S? Barreto [EMAIL PROTECTED] wrote: How do you do execute command cvs in line of command in windows. You make sure the directory holding cvs.exe is in your PATH. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with importing third-party sources and adding/committing changes
Allen Sturtevant [EMAIL PROTECTED] wrote: % cvs import -ko -m foobar v1.11.17 pub/foobar-1 foobar-1 foobar-1_11_17 So far, so good. Later I import a newer version of this software: % cvs import -ko -m foobar v1.12.9 pub/foobar-1 foobar-1 foobar-1_12_9 Side note: if you never made changes on your trunk, you're ok. If you ever committed changes to 1.11.17 on your trunk, you need to perform a merge, as in https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_13.html#SEC103 [ ... ] I later need to fix a bug in foobar-1_11_17, so I check it out to modify it specifically: cvs checkout -r foobar-1_11_17 pub/foobar-1 This results in the following Sticky Tag on all files in my working copy, again as reported by cvs status -v: Sticky Tag: foobar-1_11_17 (revision: 1.1.1.1) Yes. You won't be able to commit changes, until... Now I add a new file called new.c and modify a file called build.c, but when I try to add or commit my changes back to CVS, I get the following errors: % cvs add new.c cvs add: cannot add file on non-branch tag `foobar-1_11_17' % % cvs commit -m fixed a bug build.c cvs commit: sticky tag `foobar-1_11_17' for file `build.c' is not a branch cvs [commit aborted]: correct above errors first! ... until you create a branch to hold your bug fix. Without doing a 'cvs update -A', do this: cvs tag -b foobar-1_11_17_bufgix cvs update -r foobar-1_11_17_bugfix Check the sticky tags again, you'll notice a change. cvs commit and this time the commit will go through. If you want to propagate the change to the trunk, tag it then return to the trunk then merge. cvs tag TEMP cvs update -A cvs update -j foobar-1_11_17 -j TEMP (resolve any conflicts and test) cvs commit cvs tag -F -r TEMP foobar-1_11_17_MERGED The last command is to plant a moving revision tag at the tip of the branch that you just merged. You'll need it if you discover more bugs on 1.11.17 and want to merge them again to the trunk. But I digress... your problem was the sticky revision tag and the solution is to branch. -- pa at panix dot 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
Li Chou [EMAIL PROTECTED] wrote: Hi, I tried to figure out a single step of check out a project that contains modules from different branches of different project. For example, Project X has 3 modules, A and B which are from other projects. I need to check out module A's of Project Y branch_2.5, and module B of Project Z's main trunk. If they both were in the main trunk, I know I could add X C A B in modules file. Now how do I check out them both at the same time? is it possible? Thanks 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. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: history of version changes
Saad Sheikh [EMAIL PROTECTED] wrote: I am a new to CVS. I wanted to know if there is a command that will list all the versions of a project. There is a perl script, cvs2cl.pl, that consolidates the log messages of a sandbox in chronological order. Try Google. I wanted a history of versions of the project AND the files that have changes from one version to the next, like the history command in VSS. From the VSS comment I infer that you're on Windows. If cvs2cl is the right solution you'll have to install perl first, either by Cygwin or from www.activestate.com . It can get messy. I always find it painful to integrate new tools into Windows integrated environment ... Different culture, partly. For what it's worth, I run cvs2cl.pl from Cygwin all the time. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: DOS Command to get current branch?
Talos [EMAIL PROTECTED] wrote: My question is: Is there a DOS command that let's you know what branch name the sandbox you're currently is? Run cvs status some-file-or-other and look for any sticky tag listed in the output. If your sandbox is on the branch, you'll see your branch name there. If you're on the trunk, it will be empty. Of course that only checks the one file, not the entire sandbox, but if you only tag and branch entire projects it's a good sanity check. (This assumes that you have cvs or cvsnt installed somewhere on your path as cvs.exe'.) -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merging question - from and to
Jeeva Sarma [EMAIL PROTECTED] wrote: I have a file soa.pc, branched out at 1.2, now at revision 1.2.4.1 on branch, and 1.2 on trunk. I check-out from trunk, then do [ ... ] cvs update -j 1.2 -j 1.2.4.1 soa.pc Yes, like that. The command means, merge all changes that occurred between 1.2 and 1.2.4.1 into the working copy, which is what you want. What is confusing you is that there are *three* revisions involved: the base of the changes to merge, here 1.2, the endpoint of the changes to merge, here 1.2.4.1, and the working copy, which doesn't need to be called out by revision because it is the file sitting in your sandbox at the moment. In your case, the working copy is identical to the base, but this isn't always true. RCS file: /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v retrieving revision 1.2 retrieving revision 1.2.4.1 Merging differences between 1.2 and 1.2.4.1 into soa.pc After which the soa.pc in your sandbox should be identical to 1.2.4.1, but once again this was a special case because your starting point was identical to 1.2 . cvs update -j HEAD soa.pc RCS file: /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v retrieving revision 1.2 retrieving revision 1.3 Merging differences between 1.2 and 1.3 into soa.pc If you omit the first -j, it defaults to the most recent common ancestor of the given -j and of the working copy. Here HEAD means 1.3, because you or someone else committed changes after you checked out the sandbox with 1.2 . The common ancestor of 1.3 and 1.2 is 1.2 so once again you end up with a special case where the base and the working revision are identical. You are grabbing the changes from 1.2 to 1.3 and injecting them in 1.2, the result being identical to 1.3 . BTW, if you lose track you can always do rm soa.pc cvs update soa.pc to get a clean copy of the HEAD of the moment. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: setting up branch with code changes already in it
Royce [EMAIL PROTECTED] wrote: (from top directory within tree) cvs tag v2_0_unstable_root cvs tag -b -r v2_0_unstable_root v2_0_unstable followed by cvs update -r v2_0_unstable I have not checked in the files because I wanted to be sure they will check into the branch. How can I verify the code will check into the branch? I'd do a 'cvs status | less' and make sure every file has the sticky tag. Maybe also 'cvs -nt commit' (-n to block the actual commit, -t for a trace of what would happen), but I'm not sure that will show you what revision numbers would be used by a real commit. cvs log doesn't seem to show that info. I read somewhere that the branch gets created on commit - is that true? Yes, if you really commit to the new branch. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
Robin Rosenberg [EMAIL PROTECTED]@dewire.kom wrote: Pierre Asselin wrote: Hm, my language was ambiguous. What the loginfo would trigger is one script, running on the test machine, that updates the test sandbox, builds, runs the tests, and finally moves the tag if the tests pass. Trigging rebuilds for every commit is insane. Well, the OP wanted to trigger a test build in the pre-commit check. I was proposing a less heavy-handed solution. Not that it's entirely free of gatchas. [ sane process elided ] -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Using moving tags
Doug Lee [EMAIL PROTECTED] wrote: Er...now maybe I'm the one missing something. I don't see the problem: Say the LastGood tag was applied on Monday. Tuesday someone removes a file and commits that, but LastGood is not moved yet. But the tag *is* moved, if the testing robot succeeds with its post-commit build. If it weren't for deleted files, the robot could be just this: #! /bin/sh cd /the/reference/sandbox cvs update make test cvs update -F LastGood If files are removed, that's not enough. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
Maarten de Boer [EMAIL PROTECTED] wrote: What you *could* do is trigger the build from loginfo (post-commit) and update a moving tag if the build is successful. [ ... ] But why would you to that from the loginfo? Wouldn't it be easier to have that tag moved by a virtual user, the dedicated test build machine, which is building and testing in a loop, everytime the compilation is correct? Hm, my language was ambiguous. What the loginfo would trigger is one script, running on the test machine, that updates the test sandbox, builds, runs the tests, and finally moves the tag if the tests pass. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Using moving tags
Yamuna Ramasubramaniyan [EMAIL PROTECTED] wrote: I have a question about using moving tags. You tag the repository with LAST_GOOD today. Someone removes a file. This file still contains the LAST_GOOD tag. The next person checking out the module with the LAST_GOOD tag will get this deleted file. Do you use a commitinfo trigger to remove the moving tag from the deleted file? Are there any other ways to handle this case? D'oh. I hadn't thought of that. Maybe the tag mover could look for files that are 1) dead on the trunk, 2) not added on a branch, 3) still have the tag; and then remove the tag from those files. Not so easy to do from a sandbox from which the file has been removed. Well, it wasn't my requirement so I'm still ok ;-) -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
Ones Self [EMAIL PROTECTED] wrote: I'm running a CVS server which compiles and tests the current files in CVS every hour. I would like to make new checkins available _only_ if they compile and pass the tests. So, if a user checks in something which does not compile, for example, other users who check out at that time will not get the new version until the problem is fixed. Everytime you do an update, you know you're getting a clean version of the source; one that compiles, and in which the tests pass. I don't think you can do that. Well, you could trigger a full recompile from commitinfo and allow the commit only if the build succeeds, but your commits would be a bit sluggish that way. What you *could* do is trigger the build from loginfo (post-commit) and update a moving tag if the build is successful. That way your trunk can contain garbage, but the last successfully built commit will have an unambiguous marker on it. Your users can choose the unstable tip, cvs checkout foo or the last known good version, cvs checkout -rLAST_GOOD foo but in the latter case they won't be able to commit changes. (Well, they could start a branch, but that's taking us off-topic.) The loginfo trigger would be asynchronous, as in https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175 and there would be negligible delay to a commit. Simple question: why can't the developers do a top-level make test before committing, and sidestep the question ? Or do the unit tests take that long to run ? If the latter, you'll have to guard your build-test-retag script against multiple instances of itself. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question
Gleidson S? Barreto [EMAIL PROTECTED] wrote: 1-To take place the transfer of the files stored in the repository q they were modified for your work area, through a sicroniza??o operation. Like this, would to be in fact that sicroniza??o operation? I'm not sure what you mean, but... Synchronization in both direction has to be requested explicitly, by running a command. cvs update to receive changes made by others, and cvs commit to send changes made by you. 2-CVS counts with a mechanism capable to control the simultaneous accesses and the parallel modifications, guaranteeing like this the integrity of the modifications and atomicity of the operations. Would be in fact that atomicity of operations? If I remember correctly, commits are atomic within any one directory but are not atomic across entire hierarchies. Commits are certainly atomic on a file by file basis, so you do not get corrupted files. The lack of atomicity occurs when a developers performs an update (receive) while another developer performs a commit (send). The receiving developer may get an inconsistent snapshot with some files just before their commit and some other files just after the commit. The workaround is to repeat the update. It would be a little difficult to notice in practice, because when working on an active project one has to update many times every day. Also, the trunk tends to be somewhat unstable since it is being actively modified. 3-CVS possesses mechanism capable to identify and to solve conflicts. However those identified conflicts are merely textual, not existing any analysis of the logical consistence. Here I didn't understand the expression textual conflicts very well. A textual conflict occurs when two people modified lines at overlapping locations in a file, or at nearly overlapping locations (~3 lines apart or so). These conflicts have to be resolved manually. Modifications in distant parts of the file are accepted uncritically. You are correct that this could introduce logical errors in the merged file; the amazing thing is that it almost never does, because of the way people write software. In any case, cvs always gives you backup copies of the two conflicting versions of the file. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Checkout./export a copy to /var/www
Anand Graves [EMAIL PROTECTED] wrote: I use WinCVS to checkout a copy on my PC. When I do a commit, the file checks in a linux server. I would like a committed file to be checked out/copied/exported to /var/www/myproject. When I search for this, I keep finding this (for the loginfo file): ^cyclic-pages (date; cat; (sleep 2; cd /u/www/local-docs; cvs -q update -d) ) $CVSROOT/CVSROOT/updatelog 21 But this will update the checked out tree in `/u/www/local-docs' and my checked out tree is on a windows PC. The checked-out tree is on Windows and the cvs repository is on a Linux box, but where is /var/www ? That sounds like Linux too. If your web server is also your cvs server, just change the /u/www/local-docs in the example to /var/www/myproject and you're done. The commit on Windows triggers the loginfo on the Linux server, which triggers the update on the Linux server. If the web server is another box, you need to make loginfo trigger an update *from the web server*. If the web server is Linux (/var/www ?) the standard solution is ssh, which when properly setup allows someone on the cvs server to run commands on the web server. If the web server is on Windows... well, I'd install Cygwin (http://www.cygwin.com) and still use ssh but that's just me. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Aliasing the trunk with a branch tag
Keith Refson [EMAIL PROTECTED] wrote: One problem I regularly face is: how to build two different versions of a project which differ in only a very small subset of files. One of these versions is obviously the trunk version. It would be extremely convenient if this could be achieved by simply cvs co (or update) -A myproject cvs co (or update) -r Version_B myproject to switch between them. [ ... ] I recenty came across a suggestion of how to do this, and it does work when I tried it out. The idea is simple - just add the branch at the numeric version 1: cvs admin -nVersion_B:1 [ ... ] I'm asking for any opinions on whether this is a safe thing to do, and any potential difficulties, mild or severe, which might arise. It should be ok, but I'm always weary of long-lived branches. After a while you might want to re-graft your branch higher up on the trunk (for the files that do change). If you don't see what I mean, do an advanced search on groups.google.com for Message-Id [EMAIL PROTECTED] . -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Permissions
Gaurav Vaish [EMAIL PROTECTED] wrote: I am using pserver to connect and more often than not, I get the error - Unable to create #cvs.lock, Permission denied. The reason is that a module or a subdirectory thereof will be created by the permission set of the permission who created it. Though the directory permissions are 775 and all the users are in the group cvs, but still the problem persists. I'm lost. 775 is the correct permission. Are you saying all the directories have that permission and you still have problems ? If subdirectories are being created with more restrictive permissions, it means that you forgot to turn on the setgid bit in their parent's permissions. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: any CVS clients, with a good user interface
shivraman giri [EMAIL PROTECTED] wrote: I have my repositories in UNIX. I m working on a machine with windows XP installed. Is there a good CVS client, preferably a freeware, trial version or a GNU product that gives a graphical user interface for running CVS commands. http://www.tortoisecvs.org/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Get the list of all modules of a given repository
Miguel Lopez [EMAIL PROTECTED] wrote: is there a cvs command that allows to retrieve all the modules of a given repository? If you mean the list of modules defined in the CVSROOT/modules file, then cvs checkout -c -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Import question
Lemke, Michael IZ/HZA-IOP [EMAIL PROTECTED] wrote: When I do a cvs import of a new vendor version the new files become the head revision. I'd like to do the import such that it doesn't affect HEAD. Only after I've tested the new stuff I want it to become HEAD. Of course, it should work with local changes merged in just like the standard way of doing it on the trunk. How can I do this? There is no way to avoid that. Your trunk is broken between the time you do the import and when you merge the import back to the trunk. To mitigate the problem, you should tag your trunk before you do the import. If the post-import merge gives you trouble, you can at least start a branch off your pre-import tag so you can continue your work in another sandbox while you sort things out. When you finally merge the import, you go on to merge the temporary branch. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: ***glaring*** flaw in cvs import?
Robert P. J. Day [EMAIL PROTECTED] wrote: following the instructions in tracking third-party sources, i downloaded a kernel source tree that i both want to update regularly from the source, and make local changes to. i pulled down the tree, cleared out all CVS directories to turn it into a regular directory tree, then used cvs import to check it into my local repo. Ok, so you checked out a tree from a public CVS server and you want to import that locally. You don't have to remove the CVS/ subdirectories. See below. in the process of doing that import, the cvs command apparently decided it didn't much care for the kernel source directory net/bridge/core, and threw it away! why? because it's called core? Because 'core' is in the default ignore list. I usually reset the ignore list to just 'CVS', like this, cvs import -I! -ICVS path VENDOR release-tag and then check out a fresh sandbox somewhere else. You can keep the original external sandbox untouched; that way, you can update it from the public CVS server and reimport any deltas to your internal server. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Multi-tier development CVS plan
adp [EMAIL PROTECTED] wrote: Did you get a response on this? We are looking to move from a single CVS branch (MAIN) to either a two- or three-tiered system. Would be happy with hints. We are thinking of this: unstable - stable - release The usual way to handle this on CVS is an unstable trunk with stable+release branches. ++unstable \\ \stable1-|-| \ rel-1.1 rel-1.2 \ \---stable2---|- rel-2.1 Every time your unstable trunk reaches a milestone, you cut a stabilization branch. On this branch you perform only cleanups and add no new features. Eventually you tag your stabilization branch and cut a release, after which the branch becomes a bugfix branch. Promoting a new batch of changes from unstable to stable is done by starting a new stable branch. Not shown on the diagram is how the bugfixes from maintained release branches would be merged to later releases and to the trunk, but that's standard CVS fare. You *might* make the original promotion model work in CVS with floating tags: cvs tag -F -r1.6 STABLE toto.c --oops no, cvs tag -F -r1.5 STABLE toto.c etc. You could then check out with the -rSTABLE flag to get an official stable tree without the unstable riff-raff. That said, I don't understand the promotion model well enough to give you sound advice. To recap: unstable: This is where our current development goes. The trunk, also the default. stable: This is where we merge our soon-to-be-released code so that QA can begin work. You don't really merge in the CVS sense, instead you fork a branch to isolate changes on it from the unstable trunk. release: This is where we merge from stable, tag an official code release, and then push the release. You could branch the stable branch, but ususually it's easier to just tag milestones on it. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Setting up a new CVSNT or Linux server ??
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. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: up-to-date check failed from a lower revision to higher revision
Antony Paul [EMAIL PROTECTED] wrote: I am new to CVS. I am using the cvs command line client in Linux. I have one file whose status is as follows cvs status: Examining . === File: one.txt Status: Locally Modified Working revision:1.4.1.3 Sat Jul 10 08:53:39 2004 Repository revision: 1.4.1.3 /home/cvsuser/cvsroot/work/base/one.txt,v Sticky Tag: 1.4.1 Sticky Date: (none) Sticky Options: (none) It is unconventional to have a numeric sticky tag ... Existing Tags: No Tags Exist ... and no symbolic tags. Anyway, I started with version 1.1. I created a new version using the command cvs commit -r 1.4.1 one.txt Are you sure that's what you did ? When I try something similar, I get $ cvs commit -r1.4.1 toto.c cvs commit: Up-to-date check failed for `toto.c' cvs [commit aborted]: correct above errors first! It seems that you started with revision 1.4, not 1.1 as you said. Either that, or the revision 1.4.1.3 in your status output is wrong. It looks like you cut'n pasted the output of cvs status, so I'll assume that 1.4.1.3 is correct and that your initial 1.1 was really 1.4 . Then I modified the file and committed several time using cvs commit one.txt That part works. Now it is in revision 1.4.1.3. The error occurred when I committed with the following command cvs commit -r 1.5 -m '1.5' one.txt What is wrong with it. I am the only person who works with this file and repository. I tried cvs update -C one.txt. Still it is giving error. To finish off and make revision 1.5, commit one last time to the branch, return to the trunk and merge your branch. cvs commit # creates rev 1.4.1.4 cvs update -A one.txt # returns to rev 1.4 and removes the changes cvs update -j 1.4.1 one.txt # pulls in the changes cvs status -v one.txt The status should look something like this: File: one.txt Status: Locally Modified Working revision:1.4 Result of merge Repository revision: 1.4 /home/cvsuser/cvsroot/work/base/one.txt,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: No Tags Exist The file contents will be that of revision 1.4.1.4, as if you had checked out a fresh copy of 1.4 and manually edited 1.4.1.4 into it. Hence the status of Locally Modified. Just commit the result. cvs commit # creates rev 1.5 . ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Shared Source
Chris Puccio [EMAIL PROTECTED] wrote: I need to be able to have one main Core Product code base, then be able to suck down only certain pieces of that Core Product code base, which will be the framework for another clients product. Possible, with restrictions. Bundle up the shared code in subtrees, so any client product can get shared subtrees grafted under it, rather than pick and select files at random. It forces you to organize your shared code, but that is probably a good thing. Two recommendations: 1) The Core Product should probably be a client like all the others. Its only distinguishing feature would be that it has all the shared subtrees under it. 2) Each shared subtree should be a self-contained entity that you can check out individually. It should have its own test suite, for example. That way you can work on it in isolation and later propagate the changes to the client products. This doesn't preclude you from making the changes you want from a Core Product sandbox, it just broadens your options. I then need to be able to have any changes made to the Core Product be sync'd with any Child products that received code from the Core Product code base. The sync would occur every time you run a cvs update in a Child sandbox. Hmmm, notice how I've been using client instead of Child ? If anybody can give me some proper keywords on the CVS term to do this, it would make googling much easier right now ;) Amperstand modules. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: line number to revision
WannaLeanOO [EMAIL PROTECTED] wrote: Is there a command line tool or command that would quickly translate filename + line number to revision number. cvs annotate ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: listing new files in a local directory
John Hanny [EMAIL PROTECTED] wrote: I'd like a cvs command that tells me what files in the current directory are new. One hack that I've been using is cvs update. The files that are prefixed by '?' are new. Unfortunately, this has the side-effect of updating my local directory files if they have been changed in the repository. Use the -n flag to turn off the side-effect. cvs -nq update -I! -ICVS | grep \^\\\? ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Project in a cvs, library in another
Ababccc [EMAIL PROTECTED] wrote: I'm wondering what people usually do, in case there is a project on CVS which uses a C++ library which is in a completely separated CVS. If the library gets changed (for its own purposes) the project might get screwed... In cases like that, I equip the client project with a big fat README file that explains how to check out a *specific release* of the library in a subtree. The subtree ends up with a sticky tag and a normal cvs update doesn't affect it. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: listing new files in a local directory
Jim.Hyslop [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Use the -n flag to turn off the side-effect. cvs -nq update -I! -ICVS | grep \^\\\? Why are you suppressing the ignored files? This could give a bunch of spurious new files that you want to ignore. Because that's how I interpreted the OP's question. I figured it would be easier to get a full list and filter the chaff later, rather than to chase files that were missed because they fell in cvs' default ignore list. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS and end of line characters
Jo Vermeulen [EMAIL PROTECTED] wrote: Op Wed, 26 May 2004 11:59:46 -0400, schreef Jim.Hyslop: - Always modify files on the same platform you used to check them out. Problem is, the people on my team use Windows, and I use Linux, so were kind of mixed :-) Don't share the working copies. You check out your copy on Linux, edit it on Linux and commit it from Linux; they check out their copies on Windows, edit them on Windows and commit them from Windows. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: binary files bad idea? why?
Jim.Hyslop [EMAIL PROTECTED] wrote: Spiro Trikaliotis wrote: This is no problem from my experience if the initial check-in was done from a Unix (LF-) based system, but it is a problem if it was done from a DOS (CR/LF-) based system. There is also a remote possibility that the binary file might _happen_ to contain what CVS thinks is a keyword, such as $Id$. Chances are pretty slim, but it _could_ happen. But the $Id$ expansion occurs on checkout. The repository copy itself would still be intact, and problems with the file would be fixed by a cvs admin -kb. Working copies could be restored with cvs update. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: RES: Checking out only files NEWER than given date/revision
Alek Lapuc [EMAIL PROTECTED] wrote: The reason is simple. At the begining of the project we had some sources and include files supplied out-of-the-box with a commercial product. Than we done some customizations -- some files were added, some were changed, some were untouched. The main idea is to filter out the untouched files, so they are separated from out-of-the-box ones. The reason for this is that files out-of-the-box can be automatically patched while patching the whole product with official patch. The patch is prepared outside to our project. Our changes are not known to the product vendor, and most propably would be corrupted during such a patch. But having original and customized files separated, we can apply the patch and merge it manually to our sources if needed. Tracking third party sources in the presence of local changes is what the 'cvs import' command does. The external sources are usually delivered as tarballs or zip archives, but applying patches will work too. So check out your last import tag, patch it, reimport the result and merge your trunk. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Module weirdness.
Carter Thompson [EMAIL PROTECTED] wrote: I have some really strange problems with my repository. I have the module adm with a subdirectory ui. I also have a module named ui. Both are part of a module alias, adm-suite. That is, == Modules == adm-suite adm ui adm adm uiui Your $CVSROOT/adm/ui/ collides with the ui/ that the ui is trying to create. You can't do that. It will *not* give you the union of $CVSROOT/adm/ui/ and $CVSROOT/ui/ . It just breaks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Personal CVS repository?
J Krugman [EMAIL PROTECTED] 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. Then you have to play by those rules. There may be intellectual property issues. 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. It occurs to me, though, that maybe I could set up a personal CVS repository off my home directory Yes, indeed. Create a directory under you $HOME and run 'cvs init'. You'll have to get familiar with 'cvs import' too. Read the docs at http://www.cvshome.org/docs/manual/cvs-1.11.15/cvs_13.html#SEC104 , slowly. The first import is easy, the imports following that are more complicated. In your case, you'll want to keep yourself in sync with commits from external developers. Here's what I would do. 1) Keep a checked-out sandbox from the public repository, preferably from a read-only account so you don't commit by mistake and bypass your weekly review. 2) Import the said sandbox in your own private repository, to the vendor branch. outside-sandbox cvs -d $CVSROOT import -I! -ICVS \ path VENDOR import--mm-dd 3) Checkout another sandbox from your private repo. This is the copy you work on. Hack and commit normally. 4) At review time, go to your inside sandbox, and inside-sandbox cvs commit inside-sandbox cvs tag review--mm-dd inside-sandbox cvs diff -N -u -rVENDOR ../to_review.patch Go over the to_review.patch with your supervisor. If approved, apply the patch to your outside sandbox. Commit from there, using a -d option to switch to the developer account they gave you, with read-write permission. outside-sandbox cvs -d :ext:blahblah commit Now there is the problem of keeping your outside sandbox up to date (easy) and of propagating those changes to your inside sandbox (takes some gymnastics). At least every morning, outside-sandbox cvs update outside-sandbox cvs import -I! -ICVS path VENDOR import--mm-dd-1 That was the import. Now the merge, inside-sandbox cvs commit inside-sandbox cvs tag premerge inside-sandbox cvs update -j previous import tag -j last import tag fix conflicts inside-sandbox cvs commit inside-sandbox cvs tag -d premerge The 'premerge' tag is in case something goes wrong with the merge. It represents your last good point before attempting the merge. If the merge is full of conflicts, you can start a branch off of premerge to continue your work while your figure out how to finish the merge. (although I'll readily admit that I've never set up a CVS repository of *any* kind before); I would use it for my fine-grain version control, while submitting new, boss-approved stuff to the real off-site repository only once a week... My knowledge of CVS is very limited; I know a few commands, and I never deviate from the most basic functionality. The potentially hard part is all those imports and merges. The bit about setting up your own repository is really trivial. One annoying bit is that when you reimport your fresh commits to the external site, your merge will show spurious conflicts with the same text on both side of the conflict. You'll just have to clean them up. This personal repository idea is far more adventurous than anything I've done with CVS before. Yes, but it's the perfect thing here. You commit to your private repository at your chosen pace and you generate diffs at review time. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: need to force username of cvs 'action' when using shared
Tim Grotenhuis [EMAIL PROTECTED] wrote: I am not allowed to run pserver. Not even on a nonstandard port, tunneled through ssh ? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
