How can I view files with a specific tag in CVS?
Hi! Anyone knows if there is a CVS command that can be used to see which files (and their version) that has been tagged with a specific tag? If I do cvs status -v I get a lot of info on every file, including *all* tags. I guess I could write a script that extracs file name with tag, using awk/nawk/grep etc. But does it have to be that complicated? Rgds Peter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Merge Confusion
Ok, Based on 2 emails from this list, the CVS manual, and the Essential CVS book, I'm confused about the whole merge what tag where stuff. I hope I craft this email to get a clear answer to unfog my head. Project Name: testproj Local Sandbox is: rel_1/testproj while in local sandbox, issued cvs tag rel_1-before-branch then issued cvs tag -r rel_1-before-branch -b rel_1 then issued cvs tag rel_2_start Still in the rel_1/testproj sandbox I issue the the cvs update -r rel_1 command. This now updates the rel_1/testproj sandbox to contain the branch. I then backup a couple of directories and create a new directory called rel_2 and issue the command cvs checkout testproj (this then creates a local sandbox rel_2/testproj that contains the trunk. Now, I make bug fixes to rel_1/testproj and want to merge these changes into rel_2/testproj. The files in rel_1/testproj contain a mix of added, modified, and deleted lines. At this point, I'm not overly concerned about deleted or added files (to me they are much easier to deal with since the entire file is involved). I go into the rel_1/testproj sandbox and issue the following commands: make sure i have the latest sources - cvs -q up -dP tag the repository - cvs tag rel_1-20040630 I go into the rel_2/testproj sandbox and issue the following commands: make sure i have the latest srouces - cvs -q up -dP tag the repository - cvs tag rel_2-20040630 Now I'm ready to merge. Since I want to merge from the branch into the trunk, I'll be in the rel_2/testproj sandbox. Which command do I issue? 1 - cvs up -j rel_1-20040630 -j rel_2-20040630 2 - cvs up -j rel_2-20040630 -j rel_1-20040630 3 - cvs up -j rel_1 -j rel_1-20040630 4 - cvs up -j rel_2 -j rel_1-20040630 5 - cvs up -j rel_1-20040630 -j rel_1 6 - cvs up -j rel_1-20040630 -j rel_2 7 - cvs up -j rel_1-20040630 8 - cvs up -j rel_1 -j rel_2-20040630 9 - cvs up -j rel_2 -j rel_2-20040630 10 - cvs up -j rel_2-20040630 -j rel_1 11 - cvs up -j rel_2-20040630 -j rel_2 or something completely different? This looks something like a quiz, but I'm not the teacher, I'm just a horribly confused student and really don't want to screw up 10,000+ files that are under cvs control. I need all changes from the rel_1 environment to be merged into the rel_2 environment. I understand that after the merge, I'll have to resolve any conflicts and merge the files back into the respository from the local sandbox. I'm trying to follow the basically unstable philosophy with a long branch merging to the trunk. TIA, Rick Feldmann [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How can I view files with a specific tag in CVS?
[EMAIL PROTECTED] wrote: Anyone knows if there is a CVS command that can be used to see which files (and their version) that has been tagged with a specific tag? cvs -nq up -r tag-you-are-interested-in -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS tags
Khyati Nayak wrote: I have tags assigned to some of my files in the repository to mark them for something different. Now if one of these files is updated and committed, how do I get the tag on the latest version? Or get rid of it from the old and add it to new? Use the -F option. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge Confusion
work [EMAIL PROTECTED] writes: Ok, Based on 2 emails from this list, the CVS manual, and the Essential CVS book, I'm confused about the whole merge what tag where stuff. I hope I craft this email to get a clear answer to unfog my head. Project Name: testproj Local Sandbox is: rel_1/testproj while in local sandbox, issued cvs tag rel_1-before-branch then issued cvs tag -r rel_1-before-branch -b rel_1 then issued cvs tag rel_2_start Still in the rel_1/testproj sandbox I issue the the cvs update -r rel_1 command. This now updates the rel_1/testproj sandbox to contain the branch. I then backup a couple of directories and create a new directory called rel_2 and issue the command cvs checkout testproj (this then creates a local sandbox rel_2/testproj that contains the trunk. Now, I make bug fixes to rel_1/testproj and want to merge these changes into rel_2/testproj. The files in rel_1/testproj contain a mix of added, modified, and deleted lines. At this point, I'm not overly concerned about deleted or added files (to me they are much easier to deal with since the entire file is involved). I go into the rel_1/testproj sandbox and issue the following commands: make sure i have the latest sources - cvs -q up -dP tag the repository - cvs tag rel_1-20040630 I go into the rel_2/testproj sandbox and issue the following commands: make sure i have the latest srouces - cvs -q up -dP tag the repository - cvs tag rel_2-20040630 Now I'm ready to merge. Since I want to merge from the branch into the trunk, I'll be in the rel_2/testproj sandbox. Which command do I issue? Well, I didn't find a correct one in the list you've provided, so here is how I would do it: All you've made so far is OK, but I'd add one more tag that marks the last revision on the branch you've merged up to so far. For now, set it to the root of the branch as we didn't merge anything yet: $ cvs rtag -F rel_1-merge -r rel_1-before-branch testproj (maybe rel_1-last-merge is even better name for the tag) Then, the merge itself would be: 1. Tag current branch state with rel_1-tmp tag. $ cd ~/rel_1/testproj $ cvs update -d -P ... make sure you have no local changes ... $ cvs tag -F rel_1-tmp 2. Merge changes between rel_1-merge and rel_1-tmp into rel_2: $ cd ~/rel_2/testproj: $ cvs update -d -P ... make sure you have no local changes ... $ cvs update -d -P -j rel_1-merge -j rel_1-tmp 3. Resolve conflicts, commit changes back. 4. Move the rel_1-merge tag to the rel_1-tmp tag to record the point in the branch for the next merge: $ cvs rtag -F rel_1-merge -r rel_1-tmp testproj That's it. Rather simple in fact. Please note that all this business with rel_1-tmp tag is there to prevent troubles when some other developer commits something on the branch after you've invoked merge command but before you've moved the rel_1-merge tag. In your particular case, rel_1-tmp is the same as your rel_1-20040630, so you can substitute the former by the latter in the last two commands above. However, for me it seems easier to remember how to merge when involved tags are always called the same for given branch. This way every next merge of changes made on the rel_1 branch will look exactly the same. -- Sergei. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: listing new files in a local directory
[EMAIL PROTECTED] (John Hanny) writes: 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. Is there another way to do what I need to do without causing the udpates? The local cvsdelta utility is useful if you want to avoid a slow connection to the repository for cvs -n update http://www.gnu.org/directory/cvsdelta.html -- Brian Gough Network Theory Ltd, Publishing the CVS Reference Manual --- http://www.network-theory.co.uk/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge Confusion
Jim.Hyslop [EMAIL PROTECTED] writes: work wrote: [...] At this point, I'm not overly concerned about deleted or added files (to me they are much easier to deal with since the entire file is involved). You will have to use 'cvs add' and 'cvs remove' to have these files added or removed from the trunk. I don't think he will. At least for me it works automatically. I mean all the files are already added/removed after the merging command has been executed, so I only need to commit (after resolving conflicts, if any). -- Sergei. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge Confusion
Jim.Hyslop writes [re merging]: You will have to use 'cvs add' and 'cvs remove' to have these files added or removed from the trunk. Not so -- a merge with two -j options should handle that automatically. -Larry Jones What a stupid world. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Merge Confusion
Sergei Organov wrote: Jim.Hyslop [EMAIL PROTECTED] writes: You will have to use 'cvs add' and 'cvs remove' to have these files added or removed from the trunk. I don't think he will. At least for me it works automatically. I mean all the files are already added/removed after the merging command has been executed, so I only need to commit (after resolving conflicts, if any). Good thing you and Larry are here to keep me honest ;-) Sorry about the misinformation, Rick. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
[ On Monday, June 28, 2004 at 19:02:19 (-0700), Paul Sander wrote: ] Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) I have never, ever advocated changing the format of an RCS file in a way that would break the ci, co, rcs, or rlog programs. And although I strongly advocate the replacement of user-exposed diff and merge tools, I have never, ever advocated the replacement of the diff tool that computes the deltas stored in an RCS file. Indeed -- instead you would rather use different algorithms for storing deltas and for using them. That would be just plain stupid, if indeed not eventually dangerous to the integrity of a repository. The tools we now have for calculating and handling deltas are all designed to work _together_, not in isolation of each other, and that uniformity is as valuable to CVS as it is to RCS alone, if not more so. How about you go off and spend the next, say, two years or so intensively using such a scheme as you propose on a massively huge variety of projects. That should give you about 10% of the experience the rest of the world has with using diff and diff3 and rcsmerge uniformly for both purposes. Then if you still think it's wise to use disparate techniques for storing deltas and for using deltas then you can show your results and raise your proposal here again. In the mean time please keep in mind that there are not just a plethora of tools for using diff-style deltas, but there's also an enormous amount of human experience with them too. You (and a few others) seem to want to throw the baby out with the bath water, and all just so that a few hair-brained and lame mis-uses of CVS will work better. In the mean time if you (and others) had learned to use the best tool for the job in the first place then you'd never have had to dream up such a half-baked idea. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
User name on commit is not what I want
Whenever a module is checked in, the username is whoever did the commit. I want the user to always be cvs:cvs. I know there is a way to do this -- something in the passwd file I think -- but I cannot find it in the manual. I use cvs 1.11.1p1 witjh both :pserver: and :ext: connections -- Stephen Carville Unix and Network Adminstrator DPSI 6033 W.Century Blvd. Los Angeles, CA 90045 310-342-3602 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
[ On Tuesday, June 29, 2004 at 02:18:26 (-0700), Paul Sander wrote: ] Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) I.e. How do you propose to make it possible for the standard RCS tools alone to re-create _every_ revision from all files created by this hacked system? Simple: The delta text would not change. See above. It would be extremely short-sighted, if not downright stupid, to not keep the delta format compatible with that used by the new delta tools. You seem to have no appreciation whatsoever for the depth and breath to which this format (and its easily computed variants) is used and understood. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
[ On Monday, June 28, 2004 at 14:58:03 (-0700), Mark D. Baushke wrote: ] Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) Yes, but diff is not diff3. diff is used for the delta format. diff3 is used by rcsmerge, not for fundamental version deltas. I think you're confused -- the differencing algorithms used are fudamentally intertwined (and fundamentally based on units of lines of text). Pretending you can do merges using some other algorithm while still trying to store your deltas in unix diff format is just leading everyone down the garden path to a dark dank corner no-one really wants to be in. The uniform use of differencing algorithms and their corresponding merge algorithms (which are of course just editing scripts), is what makes it worthwhile to use something like RCS as the foundation for CVS in the first place. I.e. it is not sufficient to just use the RCS delta format as a means of archive compression -- that format is integral to the whole idea of detecting, reporting, and merging, changes in any RCS-compatible tool. Are there really utilities out there that try to to read RCS formats directly and do not allow for rcsfile(5) syntax to be used? If so, could you name any of them? Humans, for one. :-) (I know some folks can do manual merges of SCCS files, and though the same techniques won't work quite so well on RCS files because of the reverse delta thing, there are still a great many other valid reasons to read and even repair RCS files by hand.) There are a number of commercial software pacakges which are GNU RCS compatible, apparently without using RCS source code, with the most popular perhaps being CS-RCS (though I've not confirmed 100% that it does not use RCS source code). SourceCodeManager is apparently another, and P4D yet another. Perforce also uses RCS compatible files as its archive format, but I'm not sure if its core RCS handling was derived from RCS source code or not. I think I've just scratched the surface too, if any of the rumours I've heard are close to true. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Project in a cvs, library in another
[ On Monday, June 21, 2004 at 17:50:49 (-0500), Ababccc wrote: ] Subject: Project in a cvs, library in another 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... CVS is not a complete software configuration mangagement system. You'd do best to keep your management of third party libraries (and tools and other such things) separate from the management of your source code itself and to then use some additional procedures or processes to integrate these components into your final software products. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
[ On Tuesday, June 29, 2004 at 19:34:25 (-0700), Paul Sander wrote: ] Subject: RE: CVS corrupts binary files ... When you speak about how great NASA is and mention the antiquity of some of their processes, remember that the paper checklists have since contributed to the failure of several missions (some of which missed entire planets) and the loss of 14 lives. Have you not read the investigation reports on all those incidents? The concept of using paper checklists as part of their process did not contributed in any way to those failures. Indeed their ability to investigate those incidents is in no small part aided by the existance of those paper checklists. NetBSD is awesome! Of course -- that's why I've come to use it almost exclusively. ;-) But keep in mind that the reason they can do what they do is that they literally own the entire environment, from the OS and system libraries on up. Well, Duh! That's the whole point here! If you want to control your software development process from top to bottom then you must own the whole environment -- from the build environment and tools and such through to all directly included components of the system. Yes, they have to build cross environments, but after they've built the cross compiler twice the runtime environment of the build system really doesn't matter as long it can schedule CPU time and access files. Most of us don't have that luxury. You create the situations you yourself must live with. NetBSD is only interesting in this respect because the whole project, and indeed multiple working branches of it, can be checked out entirely from one big CVS repository. (keeping in mind that the manual rules for developers dealing with that repository are not exactly trivial, especially in the special-case situations I mentioned) In fact in in all successful development environments for critical software, and most for embedded software, that I've ever encountered there's a similar level of ownership over all tools and components -- however it's extremely rare to find anyone using CVS as exclusively as NetBSD is able to do (unless they are also using NetBSD :-), partly because few groups are willing to live under the restrictions this causes (it's far easier to use a manual checklist to ensure the right versions of all the right tools and third-party components is installed on a build system). (So far it's been the unsuccessful, or struggling, development groups I've encountered who have been the ones who have failied to take ownership over all their software components.) -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: binary files bad idea? why?
I want to play with the diff patch tools a bit myself just to see if I could see something go wrong with CVS and binary files if those files were run through something that would binhex them (similar to uuencoding) via a CVS wrapper. Everything seemed to work as I expected. If I understand what CVS does, when to check in a file, it does a diff with the previous version and stores that diff. To do the comparison, it must also use the patch tool. So, I took two very different binary files (well a mix of binary and text files in a special folder under MacOSX called a NIB) and binhexed them. I then did: diff -u filea.hqx fileb.hqx difference.txt I then did: patch filea.hqx difference.txt and the resulting file was equivalent to fileb.hqx. So, I'm sorry...what can go wrong here? If diff, patch and a binhex tool are the only tools which CVS requires when dealing with binary files, I don't see the problem as long as I never compare the differences between filea.hqx and fileb.hqx and select which ones to keep and which ones to throw away. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
inflate: unknown compression method after server upgrade to 1.11.16
When I use a client which inserts the global '-l' option together with my newly upgraded server, I get the expected global `-l' option ignored warning. However, if I also specify a compression level, I get the following: [EMAIL PROTECTED] tools] cvs -nq -z1 up cvs update: inflate: unknown compression method cvs [update aborted]: reading from server: Input/output error Server: cvs 1.11.16 RedHat 7.2 Client: cvs 1.11.1p1 RedHat 7.2 Note that I have many clients deployed, so I'd like to understand the problem (not just deploy newer clients). Thanks, David Please respond to this newsgroup, not my e-mail address. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
