Re: how to extract two versions of file for comparison
try something like: cvs update -r [version] -p [filename] temp/[filename] On 14 Jul 2005 06:16:04 -0700, NoPlatitudes [EMAIL PROTECTED] wrote: I am trying to get the difference between the latest working version of a file and a previous version. I need to use a third party tool to examine this difference (cvs's diff functionality won't do what I want here). I want the newest version to remain in my 'standard' working directory, and I'd like the old version to be extracted (for reference only; no edits needed) to another directory, like /temp off of my working directory. How can I do this? Thanks... ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- Give me ambiguity, or give me something else. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs client unable to see files added by TortoiseCVS
Apologies if I am telling you something you already know, but updating the repository does not automatically update all the sandboxes. In order to get an updated sandbox/working area, the normal thing to do is 'cvs update'. You can do 'checkout', as you are doing, it's normally much the same thing. On 02/06/05, Edward Moon [EMAIL PROTECTED] wrote: cvs server: cvs 1.11.17 on a Redhat Linux AS server cvs client1: TortoiseCVS v1.6.14 (which uses CVSNT 2.0.41a) on WindowsXP cvs client2: cvs-1.11.1p1 on Redhat Linux AS If client1 adds files to the cvs repository using TortoiseCVS, the added files are not seen by client2 (i.e. cvs update doesn't fetch the files). The only way I have found to force client2 to fetch the files is to issue a cvs -d :pserver:[EMAIL PROTECTED]:/vault co MODULE/DIR/TO/ADDED/FILES I've tried updating the client cvs version to 1.11.20 and have not seen any change in behavior. Is this an issue with TortoiseCVS/CVSNT or something with the configuration of the cvs server? Thanks, ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- Give me ambiguity, or give me something else. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: how to get cvs pserver working with xinetd?
xinetd is a server which starts other server processes, such as pserver, when it receives a request for them. So you might not see pserver all the time. I assume that you cannot connect using pserver from a remote machine? I think that if you post your xinetd script, and also tell us how you tried to connect to CVS remotely (using what client? What error messages appeared? Can you show us the CVS command line the client is building?), someone here should be able to help you. Andy. -- Give me ambiguity, or give me something else. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: List of files changed between 2 tags
I am trying to get a list of files changed between two tags. I am aware of 'cvs diff' command but not interested to see in the output the lines that have changed, contextually or not, I just need to see _what_ files have changed, period. I have checked all options of 'cvs diff' including --brief, however without any luck. I was faced with the same problem, and eventually came to the conclusion that the best solution was to write a script that parsed the output of cvs rdiff -s -r tag1 -r tag2. The script wasn't too complex. I know you say you've considered this, but unfortunately, it seems to be the best solution. Andy. -- Give me ambiguity, or give me something else. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Permission Denied for 'other' users
In *NIX you can make all the users part of the same group, setall the files in the repository as owned by that group, then set the repository directories group-sticky (chmod g+s). That way new files are created with the cvs group. Not sure how far that helps you with Cygwin + XP, though. On 16 May 2005 23:25:30 -0700, farseer [EMAIL PROTECTED] wrote: I have setup CVS under CYGWIN + XP.When i commit files, they are added to the repository as read only always (-r--r--r-- or -r-xr-xr-x).this means when anyone else does anupdate and tries to work with these files, he/she is unable to commitchanges.does anyone know of the possible causes of this and how to correct? thanks much___Info-cvs mailing listInfo-cvs@gnu.orghttp://lists.gnu.org/mailman/listinfo/info-cvs -- Give me ambiguity, or give me something else.___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to get changelog between two tags
You might try playing with cvs rdiff -f On 5/17/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello,I know there are some discussions in the past about using tags with cvs log,but I found no answer to my current problem. I need to get the changes which are made on some files since a specific tag.My Problem is to get also changes from files, which don't have the specifiedtag, because they are added to cvs after the tag has been generated. What I have tried, is to use the following syntax:cvs log -rTag1::Tag2Is it possible to get the changes for files which don't have Tag1 but haveTag2 ?It is not possible to use the file revision ( e.g. 1.13), because I have manyfiles (~28000) and it would take to long to get the possible filerevisionsfor cvs log -rFileRev::Tag2 .Is there a other way, or a hidden parameter, to get also files which don't have the Tag Tag1?ThanksAndreas--Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl ___Info-cvs mailing listInfo-cvs@gnu.orghttp://lists.gnu.org/mailman/listinfo/info-cvs -- Give me ambiguity, or give me something else.___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Using CVS as an enterprise backup facility
If you can live with only one version, then it seems to me that rsync fits the bill perfectly. On 5/12/05, Todd Denniston [EMAIL PROTECTED] wrote: Merlin Beedell wrote: CVS sounds like a possible solution to the following scenario: We are currently looking at backing up our main [file] servers to a remote site's hard disk.The requirements are:All files to be copied to the remote site just once (i.e. so that 200Gb does not get transferred every night/week or month over broadband connection). From then on we only need to back up new or changed files.For Changed files, we need to keep up to 3 (or a configurable number of) prior versionsWe need to see a simple report showing backup completion and any issues on the way To restore, we need to be able to easily select a file from a directory structure on the backup machine, and choose the most recent or one of the previous versions. I don't know of any backup software that runs quite like this (does anyone?).Clearly CVS would just be a component of such a system - yet it seems so possible that it really aught to be attempted.The key part is in a simple interfaces for - selecting servers and directories that should be backed up - a scheduler - a reporter - a restore interface. Am I being mad, or are there loads of existing products that do this, or does this sound like a great idea? Sounds like you really want to keep your backups in a VMS filesystem[1],which some might claim indicate you to be heading for madness. I thoughtthere was a project to provide a VMS filesystem for linux, but I can't find it quickly. Curiosity question, how many VMS folks you got there?If ALL of your files are _ASCII text_ then you might be able to implementwhat you want with CVS, but otherwise I highly suggest abandoning that idea. There are several open source backup solutions available[2], AMANDA[3]backing up to a disk, with some extra tools[4], seems the most likely to meto come close to what you want.In February someone discussed doing what you are suggesting with (or on) Subversion[5].If you could live with one backup, but have that backup in live hot realtime, you might want to look at DRBD[6].[1] http://en.wikipedia.org/wiki/OpenVMS_filesystem http://www.panix.com/~kingdon/free-vms.html http://www.tldp.org/HOWTO/Filesystems-HOWTO-9.html#ss9.19 [2] http://freshmeat.net/search/?q=backupsection=projectsGo.x=0Go.y=0[3] http://amanda.sourceforge.net/[4] http://freshmeat.net/search/?q=amandasection=projectsGo.x=0Go.y=0 [5] http://svn.haxx.se/users/archive-2005-02/0892.shtml[6] http://www.drbd.org/--Todd DennistonCrane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter___Info-cvs mailing listInfo-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs-- Give me ambiguity, or give me something else.___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: RES: Checking out only files NEWER than given date/revision
I needed this too, for similar reasons. The best I was ever able to manage was the script thing. I based my script around the output to 'cvs rdiff -s' which will show which files have changed, plus the relevant version numbers. intY has scanned this email for all known viruses (www.inty.com) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and NFS
It rather sounds like you are saying that CVS confused NFS, rather than vice versa... No. I am attempting to say the exact opposite. I am also suggesting that you were mistaken about needing to restart pserver. [...] ::shrug:: All I can say for sure is, I shut down NFS and it still didn't work; then I restarted pserver and it worked. You're right, there *may* be no connection between the action and the result in that last statement. I suppose I'd better just chalk it up to Spontaneous Reality Failure and hope it doesn't happen again I hope that everyone reading this understands I'm not attempting to apportion blame here; just trying to work out if, indeed, I do have a cause/effect link. Thanks for the various responses. Andy. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs tag: some slightly counterintuitive behaviour
As promised, a diff to the manual.
This is a context (-c) diff on the 1.11.14 version of the file. Please let me know if
that's not okay.
*** cvs.texinfo Wed Feb 4 19:05:46 2004
--- /home/apj/cvs.texinfo Tue Mar 30 11:02:33 2004
***
*** 3570,3576
One potentially surprising aspect of the fact that
@code{cvs tag} operates on the repository is that you
are tagging the checked-in revisions, which may differ
! from locally modified files in your working directory.
If you want to avoid doing this by mistake, specify the
@samp{-c} option to @code{cvs tag}. If there are any
locally modified files, @sc{cvs} will abort with an
--- 3570,3579
One potentially surprising aspect of the fact that
@code{cvs tag} operates on the repository is that you
are tagging the checked-in revisions, which may differ
! from locally modified or locally deleted files in your
! working directory. The local changes will be ignored
! and the checked-in revisions of these files will be
! tagged instead.
If you want to avoid doing this by mistake, specify the
@samp{-c} option to @code{cvs tag}. If there are any
locally modified files, @sc{cvs} will abort with an
***
*** 3582,3587
--- 3585,3593
cvs [tag aborted]: correct the above errors first!
@end example
+ This will work for locally modified files, but not
+ for locally deleted ones.
+
@node Tagging by date/tag
@section Specifying what to tag by date or revision
@cindex rtag (subcommand)
***
*** 11624,11629
--- 11630,11636
@c
@item tag [EMAIL PROTECTED] @var{tag} [EMAIL PROTECTED]@dots{}]
Add a symbolic tag to checked out version of files.
+ Uncommitted modifications to the current working directory are ignored.
See @ref{Revisions} and @ref{Branching and merging}.
@table @code
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs tag: some slightly counterintuitive behaviour
Did you check it doesn't work for locally removed files (for which cvs remove has been executed)? If it does, the description needs further cleanup, I think. What about locally removed directories? In both cases cvs tag warns or errors, then bombs out, regardless of whether the -c tag has been used. I don't think we should be going into that much detail in this part of the manual, especially since the behaviour fails safe. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs tag: some slightly counterintuitive behaviour
On a different note: IIRC you mentioned earlier that these deleted files are not part of the release, but you don't want to remove them from the repository. What harm would there be if those files actually had the tag applied? Not much, admittedly. The point is that they don't compile, and I want to get to the point where files not compiling in a release is some sort of danger signal (!) We're in the middle of a system test right now, and I'm removing the dead code. But inevitably there are some programs which aren't obviously dead but won't compile either. We'll have to hand those back to the developers and hope they can tell us... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs tag: some slightly counterintuitive behaviour II
While doing some further testing I have discovered that cvs tag -c ignores removed files. That is, you can remove a file from the sandbox with rm and then do a cvs tag -c, and the removed file will be tagged with no warning or error. Now I think that that *is* a bug. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs tag: some slightly counterintuitive behaviour
Jason Carucci No, I believe cvs will tag the files in the repository, the files in your working directory are irrelevant for this operation. I'm not saying that CVS behaved wrongly, just in a way that was counterintuitive. To say that cvs tag requires a working directory, but not the files in it, is surely that. Derek Price `cvs tag' is defined to tag the BASE revisions of the files in the working directory and this is exactly the behavior you are describing. [...] Therefore, I would argue that this sort of behavior is simply too much to expect from CVS. Maybe it is. The point I am making is, it surprised me. Here is what the manual says: tag [options] tag [filesÂ…] Add a symbolic tag to checked out version of files Now I've *seen* this particular little gotcha, on re-reading the above I can see that CVS is behaving as advertised. But I think it is fair to say that anyone reading it who had not had this happen to them, might get the wrong idea, as I did. Derek Price The work-around, and a pretty straight-forward one I should think, is to commit your changes before tagging. No, no. I don't want to remove the files. I just want to not tag them. Now it looks like I will have to tag the whole sandbox and then untag a list of about 30 files - not fun. Is it really a pain to change (assuming it should be changed)? Modified files shouldn't be a problem - just ignore them, as now. Anyone who doesn't like this behaviour should be doing cvs tag -c anyway... Of course, the simplest fix is to add a couple of lines to the manual. Don't get me wrong, this isn't a major gripe. I just wanted to flag a small bit of odd behaviour. Andy. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs tag: some slightly counterintuitive behaviour
Patches thoughtfuly considered. :) Well, hell. I'd be honoured. It's not as if it would take more than a couple of lines. Do you literally mean a patch-compatible diff to some version of the current Cederqvist? If so, which version? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs tag: some slightly counterintuitive behaviour
Why can't you just choose the files you want to tag and run the TAG command only on those. This way only those files get tagged and not the complete module, which is not want you as it is want to happen. Because I have 12,766 files, and I want to tag all but about 30 of them. Working out which 30 is a long and laborious process of checking by hand. It would have been nice if I could have just worried about getting the sandbox to a given state and then tagging that state. What I'll end up doing is compiling a list of the 30 as I go along, tagging everything and then doing something like: cat badlist.txt | xargs cvs tag -d tag As I said, it's not really a big deal, just a small surprise. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: branching blues
- anyone out there have suggestions or experience on a better way to do this than I've chosen? (well, that's certainly how *I*d do it...) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Best method to replace a branch's code
Errr... is it safe to rename branch tags? My suggestion: get a list of the files that will change, and delete those files in branch A's sandbox before the merge. Disclaimer: I've not tested this! At 01:47 pm 24/3/04, Fouts Christopher (6452) wrote: Will renaming the branches work? First rename branchA to branchX cvs tag -r branchA branchX Then rename branchB to branchA cvs tag -r branchB branchA -chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Euan Guttridge Sent: Wednesday, March 24, 2004 6:32 AM To: '[EMAIL PROTECTED]' Subject: Best method to replace a branch's code What is the best method to *replace* code on branchA with that on branchB? Note not a merge, a straight replace. Thanks Euan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Best method to replace a branch's code
that solution would flag conflicts, I just want a no questions replace.. It wouldn't, you know. To CVS it would be exactly as if you had made the changes manually. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tagging files based on existing tag. Why are fi les tagged with the new tag when the tag doesn´t not exist on some files
So we tag the latest test release with another tag for the offical version with cvs rtag -F -r TEST_20040322 RELEASE_20040330. Probably a stupid question, but are you sure you entered -F and not -f ? Which would presumably give exactly the results you describe. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tagging across branches?
Thanks for the help, all. No, I wasn't planning on doing a checkout - I assumed that that would crash and burn somehow - just an export. Larry Jones wrote: Just a terminology clarification -- everything in $CVSROOT is a single repository. Its subdirectories are top-level directories (or modules although, strictly speaking, that term should be reserved for things defined in the modules administrative file). Agreed, hence my careful qualification; and, agreed. I just couldn't bring top-level directories to the tip of my tongue, somehow. Not CVS's most memorable piece of terminology, although I'm at a loss to suggest a replacement... Andy Jones ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Tagging across branches?
Hi all, I have a repository - that is, a subdirectory of $CVSROOT - which has a number of subdirectories. For one of these subdirectories I have created a branch, and in my sandbox have checked out that branch. So in my sandbox I have the main trunk except for one directory, which is sticky on a branch. What happens if I cvs tag the entire sandbox? Can I do an export on that tag, and get exactly what I currently see in the sandbox, including the branched directory? What happens if I do a checkout (!!) on that tag? Some background, of you like: I have some legacy code from before we started with CVS that only applies to one directory, so I've put it in a branch (with the intention of never, ever merging from that branch). Now I need to make a release to a site that is not ready to move on from that legacy code. So I want to make a release tag and do an export. If I have cvs'd myself into a corner, suggestions for what I *should* have done will be greatfully received... [cvs 1.11.12; Red Hat 7.1] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS : extracting releases without the 'CVS related stuffs'
That would be cvs export. You have to give it a tag or a date to export, but other than that it's almost the same as cvs checkout. At 04:53 pm 17/3/04, Thomas Lavergne wrote: Hi all and sorry if this seems a trivial issue : the faq is of no help. I would like to checkout a release tagged version of my software, but without all the 'CVS related stuff'. I just want a directory with all my sources and makefiles in order to distribute it. I do not want copies to contain the CVS history information. Is there a special command or option to check-out? Thanks, Thomas ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: attaching hooks with specific activities in CVS
Yeah, but he should take the hint back to his local postmaster and belt him over the head with it on our behalf. Of course appending junk like this doesn't help either, but there it is attached to _YOUR_ e-mail (and soon my e-mail too)! :-) In my (British) experience these disclaimers are decided upon at a high level, and no amount of belting by anyone below the board level will get it changed. Yes, we know it doesn't make sense, but it has to be there. I tend to take the Zen approach, and just ignore them ::grin:: ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: attaching hooks with specific activities in CVS
The information transmitted is intended only for the person or entity to whom it is addressed and may contain confidential and / or privileged [...] Such disclaimers on messages posted to public mailing lists are specious at best. Err, guys? I don't think he actually *typed* that bit. He almost certainly doesn't have a choice about it appearing on the bottom of his mail... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs -n checkout weird behavior
I thought I could use cvs -n export to show a list of files with a certain tag. But I got this instead: $ cvs -n export -r rel_ta-2-3-2_040204 tapestry/ta |tee ffile cvs export: in directory tapestry/ta: cvs [export aborted]: there is no version here; run 'cvs checkout' first A checkout without -n doesn't do this, which bends the principal of least astonishment a bit. You get the error whether there is or is not a tapestry/ta dir below the current level. 1) Anybody know what is going on here? 2) Any other, better ways I have stupidly missed to list the files with a given tag? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs export weird behaviour (stupidly was: cvs -n checkout weird behavior)
Please excuse me, and replace checkout with export below. I was talking about cvs export the whole time. At 10:00 am 20/2/04, Andy Jones wrote: I thought I could use cvs -n export to show a list of files with a certain tag. But I got this instead: $ cvs -n export -r rel_ta-2-3-2_040204 tapestry/ta |tee ffile cvs export: in directory tapestry/ta: cvs [export aborted]: there is no version here; run 'cvs checkout' first A checkout without -n doesn't do this, which bends the principal of least astonishment a bit. You get the error whether there is or is not a tapestry/ta dir below the current level. 1) Anybody know what is going on here? 2) Any other, better ways I have stupidly missed to list the files with a given tag? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Binary release announcements?
People who don't want, or can't, compile their own programs should be looking to their software integration vendor for such support. If I understand you correctly, you are saying that people who don't feel comfortable compiling programs should buy support? So these people have no place in the Open Source / Free Software movement, I take it, which is just a big club for C programmers? way off topic; I'll stop now. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Binary release announcements?
Some folks prefer poking themselves in the eye with a dirty old stick too, but that doesn't mean we should encourage their behaviour. Except in certain cases, of course -- there are some people that you don't *want* to see what's going on. ;-) With the greatest of respect, of *course* you don't see why people shouldn't compile their own source - you're C programmers! This is rather like listening to a discussion by marathon runners saying they can't understand why everyone doesn't run to work. For my own part, there are some programs I am comfortable compiling and some I most certainly am not. It so happens that CVS falls in the former category (now), but I can certainly sympathise with people who put it in the latter. At the end of the day, people choose to install binaries for one reason: because if the program fails to work, then you know it's nothing you have done. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Pros/Cons
Aside: Have you seen Subversion? It specifically addresses a good number of your concerns. But it is a newer product, and I certainly don't know enough about it to recommend (or damn) it. For my own part I *like* the fact that CVS stores revisions at the file level. It's part of our release strategy to be able to make patch releases of only the programs that have changed, and it would be *much* more difficult to keep track of this if each program did not have it's own version number. Andy Jones Tapestry Software. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
server flow control option / my sig 11 problem last month
1) Can anyone clarify what the default is regarding the server flow control ./configure option? The INSTALL readme seems to say I should either turn it on or turn it off, but not what happens if I do neither. 2) Does anyone have an opinion they would like to share regarding the effect of this option on the problem I had last month: http://mail.gnu.org/archive/html/info-cvs/2004-01/msg00130.html or thereabouts. 3) Can anyone say if this has been recognised as a bug, and whether it is still being looked at? I know Mark Baushke was looking at it at the time, but of course he is under no obligation to continue to do so. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: server flow control option / my sig 11 problem last month
Thanks for the explanations. I would have thought the first sentence made that clear: ::grin:: it did, but later sentences made it less clear... As far as I remember, the concensus was that you had run out of (virtual) memory on the server machine. CVS does its best to detect that condition and report it, but there are circumstances were it is simply impossible to do so. So it would appear that I had flow control turned on and it did not help? My (ignorant) reading of the flow control description in INSTALL suggested that it might stop a memory overrun. Does that mean that there are circumstances where flow control doesn't? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: what's to stop a developer from nuking the repository?
At 04:15 AM 1/20/2004, Andy Jones wrote: am I right in thinking that Greg's opinion does not reflect the majority view? No. And besides, Greg is one of the resident experts on CVS. Listen to him. I didn't say that his point of view was not valid. I didn't say that he was wrong. Please do not jump to conclusions. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Control tagging of labels Test, QA and Production?
Allow me to suggest a simpler alternative. Developers do not book code into CVS until it is ready to be promoted to QA. Presumably you would not want code included in the automatic build unless the developers had completed it, so your test tag works fine as it is. Tested QA code is then tagged with a release tag once it has passed QA; you can then easily release using 'export -r release tag'. Regrettably there are few safeguards to stop developers tagging in ways that they should not. But it should not be difficult to find out who created a given tag, so it's just a matter of keeping your eyes open. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Have I got a corrupt repository?
What do you see in the CVS/Entries file for the corresponding directory
that is showing those 'greek' filenames?
Yep, you're right. That's where the greek filename is coming from.
That would be a matter of looking in bug tracking for your vendor
(Redhat for version 7.1) to see if there were any bug reports against
the kernel you are using.
Okay, I can't see anything, but that's not complete proof that you are wrong.
The line in entries.c is this one:
if (fprintf (fp, /%s/%s/%s, p-user, p-version, p-timestamp) 0)
so it miht be interesting for you to issue the commands
up
up
p *p
(gdb) up
#1 0x40156677 in fprintf () from /lib/libc.so.6
(gdb) up
#2 0x0805d950 in fputentent (fp=0x82f7b40, p=0x80fbda0) at entries.c:424
424 if (fprintf (fp, /%s/%s/%s, p-user, p-version, p-timestamp) 0)
(gdb) p *p
$1 = {type = 136248160, user = 0x80feec8 \n\tim1, version = 0x632f6c61 Address
0x632f6c61 out of bounds,
timestamp = 0x725f7376 Address 0x725f7376 out of bounds,
options = 0x736f7065 Address 0x736f7065 out of bounds,
tag = 0x726f7469 Address 0x726f7469 out of bounds, date = 0x61742f79 Address
0x61742f79 out of bounds,
conflict = 0x74736570 Address 0x74736570 out of bounds}
Andy.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Have I got a corrupt repository?
If you are at version 2.4.20-28.7 of the kernel and glibc-2.2.4-33, then I doubt that there is an mmap bug around any longer. If you are not at that level, you may wish to look into getting some updates from ftp://updates.redhat.com/7.1/en/os/ while they are still available. We've not made any patches to 7.1 here. I would have to consult with the Powers That Be before I could make such a major change. The idea is that all machines on all sites that run Webspeed run it under the same conditions. We have to be careful that we don't switch to an OS that our software suppliers will not support (although admittedly we could probably be running RH8.0 by now). In any case I can't seem to duplicate the problem on the cvs server of a second, identical box. Which would *suggest* that kernel/glibc versions aren't the problem. Sorry. I wish I could say something more certain. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Have I got a corrupt repository?
As a suggestion to tackling this problem from a different direction, would you please run the check_cvs script over your repository. The script should be found in the scripts directory of the cvs distribution. I'm interested in the output. All suggestions greatfully accepted. I've already run this script; the results were that it found no problems. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Have I got a corrupt repository?
Certainly is. Note that the space overwritten in the struct is probably a string since the hex values spell out al/cvs_repository/tapest. Just to confirm that one - the module in question was in /usr/local/cvs_repository/tapestry ... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Have I got a corrupt repository?
[Red Hat 7.1, CVS 1.11.10] I've been trying to check in a *big* change over pserver and getting some nasty crashes from CVS (which unfortunately I did not take a note of - System exit 11?). Eventually I discovered that this particular client machine had an older version of CVS on it - 1.10.8 - and put it down to that. So I FTP'd the big change across to the server machine and tried again, but I'm seeing some Weird Stuff: * I have some files which cvs status shows as locally modified but cvs -n commit does not list. If I do cvs commit without the -n, though, that's okay. * CVS keeps telling me that it's waiting for a lock to be freed. No-one else is using CVS, though. As per the manual, I'm deleting the lock files. But I've never had this problem before. Do I have a corrupt repository? If so, can it be repaired? I can restore a backup of the repository if necessary, but if there's an easier way... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Have I got a corrupt repository?
When I commit I'm also seeing: Rlog: RCS/somefile: No such file or directory ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Have I got a corrupt repository?
And you are sure that there are no 'odd' files present in your repository? (ls -alR) I think Redhat Linux allows UTF-8 characters in filenames... I'm afraid so. I did try an ls -b at the time; and wiping the sandbox and recopying from my original tar made the problem go away. Define 'large commit' please. Many files? Many LARGE files? A few LARGE files? It almost sounds like mmap() is broken on your system. About 200 files were committed according to the log (although I guess that's not a guaranteed number if CVS crashed half way). Sounds about right, though. Your average file should be about 5k. I don't know what mmap() does or how to tell if it is broken. Your suggestion is filed to try later, and thank you, although at the moment I have a baseline release to get out What do you see in the CVS/Entries file for the corresponding directory that is showing those 'greek' filenames? I may be able to duplicate the problem tomorrow, and if so, I'll find out and post again. Use 'top' to see what memory and sap you have free on your system. ::slaps heel of hand against forehead:: of course. Swap file working fine and 500Mb as advertised. Crashing in a malloc() to obtain 39 bytes is a bad sign. You really need to see how much free memory and swap you have on your system. You might be interested to see another trace from a different core: === (gdb) bt #0 0x4014e1c6 in vfprintf () from /lib/libc.so.6 #1 0x40156677 in fprintf () from /lib/libc.so.6 #2 0x0805d950 in fputentent (fp=0x82f7b40, p=0x80fbda0) at entries.c:424 #3 0x0805d1ce in write_ent_proc (node=0x80fdd48, closure=0xb5f0) at entries.c:100 #4 0x0806213a in walklist (list=0x80fe870, proc=0x805d1a0 write_ent_proc, closure=0xb5f0) at hash.c:370 #5 0x0805d268 in write_entries (list=0x80fe870) at entries.c:140 #6 0x0805dcb5 in Entries_Close (list=0x80fe870) at entries.c:580 #7 0x0807d642 in do_recursion (frame=0xb6f0) at recurse.c:793 #8 0x0807dcdb in do_dir_proc (p=0x80d35d8, closure=0xb798) at recurse.c:1134 #9 0x0806213a in walklist (list=0x80d3fb8, proc=0x807d77c do_dir_proc, closure=0xb798) at hash.c:370 #10 0x0807d61c in do_recursion (frame=0xb830) at recurse.c:783 #11 0x0807d0b6 in start_recursion (fileproc=0x80587e0 commit_fileproc, filesdoneproc=0x8058c58 commit_filesdoneproc, direntproc=0x8058dd4 commit_direntproc, dirleaveproc=0x8058e90 commit_dirleaveproc, callerdat=0x0, argc=0, argv=0x82ac150, local=0, which=1, aflag=0, locktype=0, update_preload=0x0, dosrcs=1, repository_in=0x0) at recurse.c:366 #12 0x08057ed1 in commit (argc=3, argv=0x80d31b4) at commit.c:679 #13 0x0806d82d in main (argc=3, argv=0x80d31a8) at main.c:994 #14 0x40113237 in __libc_start_main () from /lib/libc.so.6 The common denominator seems to be walklist() although I guess if it's just a case of running out of resources, then that doesn't mean much. Thanks again and hopfully I'll post tomorrow Andy. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Adding an earlier version of a file?
This is a bit bizzarre, but then again, real life invariably is. It looks as if I'm going to have to make a release which includes versions of some files which are *earlier* than my initial import of the software into CVS. In hindsight, I'd like this earlier code in CVS, too. But I'm stuffed, aren't I? There isn't any way I can tell CVS that these are earlier, rather than later, versions? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Installing the new version
Thanks for all the advice people have sent me about installing both from RPMs and tarballs. Knowledge is power, and I'm getting less scared of installing stuff. But I still don't know if there was anything wrong with the RPM I tried to install... Andy. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How to manage oracle custom.pll libraries
Can you explain what you mean by enhancements A, B, and C? If all of these new features: A, B, and C are fairly independent but all modify the same files, then one approach would be to put each feature on its own branch. But if you can make sure that the development for A, B and C does not happen at the same time, and know what order you need to develop them in, you don't *need* branches, do you? Of course you might decide to have branches anyway, because that would allow you to fix bugs on A and develop on B at the same time. * Keep your branches short -- the longer the branch the further away you are from the main branch, which means merging becomes more difficult. * Create a tag each time you do a merge. This could be a life saver if you have to make a second merge from a branch. * Always merge changes back into the main branch, not the other way around. (This is real problem with the separate DEV, TEST, and PROD branches idea. You want to maintain as few of branches as possible). I agree wholeheartedly. I would add: * Before you create a branch, think very carefully. - Know exactly what the branch is for; - Know who's job it will be to merge it back; - Know when it will be merged back; - Allocate time for the merging process (including a system test of the merged code!). In short, don't branch unless you are absolutely certain that you have to branch, and that you are ready for the consequences. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to manage oracle custom.pll libraries
I think it's going to depend on who has the ability to modify these files. If the files are only modified in DEV, then as I see it you don't need branches. The way I would organise things would be to have DEV, TEST, INT TEST, PREPROD and PROD checkout areas each with the version of the code they were ready for (have a look for sticky tags in the CVS manual). So custom.pll (and all the other files) would be checked in by the developer, updated into DEV (cvs update), and then as your test cycle progresses it would be updated into each area in turn until it reached PROD. But meanwhile developers could modify custom.pll as they wished without effecting anything else. You might indeed want to tag files that were ready to move between areas - your call. You only need branches if you need to do development work on more than one version of the program at once. For example, it is normal to start a branch after a release so that the developers can make quick fixes against the released code, rather than the code they are adding new features to. Andy Jones Tapestry Software. At 04:02 pm 8/12/03, Tom Marsh wrote: Dear list: Since I got no response, I'll try a more detailed explanation. We're using CVS on a large oracle development project. We're using revision number as the 'tag' (I hope my terminology is correct) to indicate the versions to promote up the development chain, I.E. DEV = TEST = INT TEST = PREPROD = PROD. This is working fine for groups of files that have to be promoted together. The problem however, comes in with an Oracle application library called custom.pll. custom.pll is a binary file, but it can be built from source. It is a library that _everybody_ wants to modify with references to thier enhancements. The library contains pl/sql procedures and routines. Everybody's enhancements are on a different timeline, so that enhancement A, B, and C might be in DEV, A and C in TEST, and only C is is in INT TEST. In reading the documentation, I think the solution might be with branches, but I'm not sure. Can anyone help? Thanks in advance, Tom info-cvs: Does anyone have any experience or procedures for managing oracle application custom.pll libraries with cvs? If no one knows what I'm talking about, I'll resend with a description of what seems to be challenging problem. Thanks, Tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Main branch tips
Is there some way (or special tag) which will allow me to refer to the tips of main branch, so I can use: yes, there is a special tag, HEAD (and another one is BASE, which refers to the revision you last checked out in your current working directory) So, if I do a cvs checkout without a -r then I get the HEAD revision? And in that case there will be no difference between 'cvs update -j rev1' and 'cvs update -j rev1 -j HEAD' ? Is that correct? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Exporting with 1 tag name
Can anyone help me think around this one? We are finally getting around to making releases from CVS. We have a product that is split up into a number of seperate modules. Ideally we would like to be able to release the whole project, or just a module. I intend to follow the simplest solution here - I'm going to tag all the files with a release tag and then do an export. If I'm releasing the whole product I'll put the name of the product as part of the tag; if I'm releasing a single module then I'll put the name of the module as part of the tag. And, of course, if a file is part of a product- and a module- level release, it gets two tags. No problem. However, I'm a little concerned that if a customer gets a product level release followed by a module level release then the ident string for the module code will not have any relation to the ident string for the rest of the product. The customer will see rel_tapestry_2_3 (product) and rel_ta_4_1 (module) and not know which came first. The best solution I can conjure up is that a module release is always predicated on a product release. So instead of rel_ta_4_1 (s)he would get rel_tapestry_2_3_ta_4_1. In effect that makes a module release a sort of patch release. Andy Jones QA Bod Tapestry Software ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checkout without \r's
wincvs has an option to check files out with *NIX line terminators. Maybe this will do what you want. But really that is not the point. Inherent in the idea of a text file is that you should be able to edit it. The convention is that *NIX and DOS terminate the line endings differently on a text file. The file has not changed. It is merely conforming with the standards of the platform - or else (clever editors aside) how would you be able to edit it? Try opening a *NIX-style text file in Notepad and see what you get. if only they had realized sooner, this mentality that 'what you checkin is NOT what you checkout' would not have been so concrete, and this ... would not be an issue. I would suggest that for the majority of CVS users, this is already not an issue. If you are going to use a hashing algorythm to check if the file has changed, then you need to remove the line terminators before making the hash, because they are not part of your data, but an os-specific part of the way the data is being stored. And you might want to consider removing whitespace too, because presumably you are only interested in noticing if a *meaningful* change has happened to the file. Alternatively you could use CVS to tell you if the file has changed. Andy Jones Tapestry Software ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: DOS2UNIX conversion Tool
To convert text files from DOS to UNIX, try: cat dosfile |tr -d '\r' unixfile At 11:17 am 7/11/03, Lars Thuring wrote: [EMAIL PROTECTED] wrote: Looking for DOS2UNIX Tool execution while checkin the files, can any one help on this. For unix, there is flip. There is also dos2unix for Unix / Linux: NAME dos2unix - DOS/MAC to UNIX text file format converter SYNOPSYS dos2unix [options] [-c convmode] [-o file ...] [-n infile outfile ...] and the converse unix2dos. regards, Lars ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rephrasing: question about merging branches
Is it just me, or is this getting way too complex to be usable except by CVS experts? I thought I was comfortable with the issues surrounding branches and merges, even though we are not using branches yet here. But I don't understand half of what you folks are saying. Worse: in my understanding this isn't even a particularly complex case. Let me see if I have this right. You want to merge changes made on a branch back into the main development stream, then merge that with the changes on another branch. Surely **everyone** will need to do this, sooner or later? Andy Jones. At 03:37 am 5/11/03, David Wood wrote: I am not sure about something. |If branch A and branch B in your example don't branch form the same |point on the trunk, a merge from point 2 to point 4 into the trunk might |still not do what you want. If branch B branched first, then 2-4 may |back out changes made to the trunk between the base of B and the base of |A. If A branched first, then 2-4 will attempt to remerge changes made |to the trunk between the base of A and the base of B, causing the same |sort of spurious conflicts you were attempting to avoid. Assume B is branched first. A merges to the trunk. Then A merges to B. Then B merges to the trunk as well. I think the trick here is what happens when A merges to B. If you do that merge like this: (in B's working dir): cvs update -j branchA_CREATED -j 3 (3 == where A merges to B) then you are correct. This merge will be missing changes from between the start of B and A - ALREADY! In other words, with respect to B, part of A was left out, since it was created before branchA_CREATED - on the trunk. But I think this is really the wrong way to merge A into B. The right way is to do it would be to say: cvs update -j branchB_CREATED -j 3 Then branch B does indeed end up incorporating everything from branch A. In other words, the changes on the trunk after B was created until A starts, and then all then all the changes in A. So when doing that kind of merge, always use the newest common ancestor (in this case, the start of B). Now let's look at your other scenario. When A is created before B, everything else being equal, I did not receive spurious conflicts doing that last merge in a single step (2-4, Jamie's way) after all! You say there should be, because that I am remerging changes made to the trunk between the base of A and the base of B. But I can't see where the redundancy should come from. The changes between the start of A and the start of B are not in A, and they are inherent in B. So goes my theory. Perhaps we are making different assumptions? |The only clean way to do this in the general case is to tag branch B |before and after your merge from A at point 3 and merge B back into the |trunk as two merges: | |~cvs up -j 1 -j pre-3 |~cvs up -j post-3 -j 4 ... Oops, yes, you are correct. What I said was correct if point 2 3 were the same (at point 2 all of branch A was merge to both the trunk and branch B). A clean merge to the trunk without conflicts from a repeated merge with distinct points 2 3 would require the two commands I listed above and a third merge: ~cvs up -j 2 -j 3 So if I understand you all correctly, a generalized merge formula would be: cvs update -j start-of-branchB -j pre-3' cvs update -j 2 -j 3 cvs update -j post-3' -j 4 in that order? What if branchB had made changes that would conflict with branchA's changes, and the merge from A to B is to correct that conflict and bring B into sync _before_ it merges with the trunk? Following this pattern, I will still get that conflict between B and the trunk on the first command - even though those conflicts had already been resolved post-3'. Nothing subsequent would work without manually duplicating the conflict resolution already present in B... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: improper behavior or improper usage?
On Friday, October 10, 2003 6:00 AM, Larry Jones [SMTP:[EMAIL PROTECTED] wrote: Mark Jaffe writes [in exceedingly long lines]: CVS is not behaving as expected, and causing great difficulty. Your expectations are wrong. The CVS philosophy is that you tag entire modules, not bits and pieces. -Larry Jones I think Larry is right in that Lawrence's expectations are wrong. But I think the problem is something different. Lawrence, if I understand correctly, you are tagging files that are ready to become part of the main product, then trying to check out a working copy that is the sum of the 'main product' tag and the 'ready' tag? This is contrary to CVS's normal mode of working. Normally you check out a working copy, do the development, then *commit* files to make them part of the product. You can then export or checkout to a common code area if you need to. If this doesn't work for you, why not just have a 'current product' tag, and add or remove it from files as necessary? But by doing this you are circumventing a lot of the good stuff CVS has to offer. What we will be doing here is: every time we are ready to make a release, tag all the files for that release with a 'release' tag. Then we can export on just that tag. We can tag individual files if we like (for example if we are making a patch release and only need some of the 'library routines' module) and that works fine. Andy Jones Tapestry Software. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
filename created independently by second party
Hello all. CVS 1.11 It's probably my fault - I was trying to do a final import to prepare for our version control strategy going live. What I didn't remember is that, with my developer's hat on, I had created some new files and done a cvs add in my local working copy. And to test those files I had to put them in the general code area. So they got imported too. So when I went to commit the files back in my local working copy I got filename created independantly by second party. I couldn't merge away the conflict. In the end I just cvs remove'd the version from the import. My question is, was there a better, cleaner way out of that conflict? Shouldn't a cvs update have merged the differences between the two versions? Andy Jones Tapestry Software ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: filename created independently by second party
::slaps heel of hand to forehead:: That's what comes of being the CVS administrator *and* a programmer: I kept thinking it was a problem for administrator-me. Thank you. On Thursday, October 09, 2003 4:21 PM, Larry Jones [SMTP:[EMAIL PROTECTED] wrote: Andy Jones writes: So when I went to commit the files back in my local working copy I got filename created independantly by second party. I couldn't merge away the conflict. In the end I just cvs remove'd the version from the import. My question is, was there a better, cleaner way out of that conflict? Temporarily rename your local file; do a cvs rm on the original name to unadd it; update to get the file from the repository; check to be sure that you really want your local file instead; then rename your local file back, replacing the one you just got. Shouldn't a cvs update have merged the differences between the two versions? As far as CVS knows, the two file have nothing whatsoever to do with each other. Without a common ancestor, there's nothing to merge -- you'd just have one big conflict with the entire contents of both files, so there's no point in even trying. -Larry Jones Hello, local Navy recruitment office? Yes, this is an emergency... -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
