Re: Error while seeing logs using loops
Kudiyarasan writes: The result is not coming fully . i.e. the cvs server gets down at the middle and quits . I can not analyze where the problem is . Can anyone help me ?! . http://www.cvshome.org/docs/manual/cvs_21.html#SEC182 Pay particular attention to the very last paragraph. (And you might also want to look at the man page for xargs.) -Larry Jones It's clear I'll never have a career in sports until I learn to suppress my survival instinct. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Sticky Tags
Scott Holmes writes: I'm getting an error message on trying to commit: cvs server: sticky tag `WCGCPG-1-0' for file `init.blk' is not a branch ``cvs update -A'' will remove the sticky tag and return your working directory to the tip of the trunk so that you can do checkins. -Larry Jones Mr. Subtlety drives home another point. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: info without working copy
Laine Stump writes [quoting me]: There should be an rlog command to do that, but it's never been implemented. And whoever decides to do that, can also implement an "rannotate" command. Pretty please? ;-) Your wish is my command. I've just checked in support for rannotate and rlog. -Larry Jones Aw Mom, you act like I'm not even wearing a bungee cord! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: commit to head restricted
One more question! does anyone have a cron job script already created that will rtag the head as a specific time? -Original Message- From: Annette Waters Sent: Friday, March 30, 2001 3:15 PM To: Annette Waters; Info-Cvs (E-mail) Subject: RE: commit to head restricted I have testing the reserved checkout to the head. Does anyone know where the message that informs someone the file is already locked comes from and can I modify it? -Original Message- From: Annette Waters [mailto:[EMAIL PROTECTED]] Sent: Friday, March 30, 2001 1:03 PM To: Info-Cvs (E-mail) Subject: commit to head restricted I've been reading the CVS home page and my collection of CVS info group e-mails as I need to restrict committing to the HEAD of our source tree to just be allowed to one user. I do not want to restrict anyone from committing to their own branches. I would appreciate any insight on the best way to do this. I have an old clearcase (prior company tool) trigger that accomplishes this. If I modify this to contain cvs commands and reference this in the cvswrapper file -- "should" this work? (if so some proper steps would be appreciated!) What about reserved checkouts.. if I do a reserved checkout as my cvsadmin user and therefore the only one who could commit.. would this have any effect on developers committing into their own branches? Thanks in advance for any and all help! Annette ___ 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: cvswrappers - any better suggestions ?
[ On Friday, March 30, 2001 at 07:07:14 (-0800), Gianni Mariani wrote: ] Subject: RE: cvswrappers - any better suggestions ? Your point is well taken. However, time are a changing - source code is not only text. Image, sound, movie, geometry, encryption key, etc etc files are all parts of modern day applications. All these files need to be version managed just like regular files. If we could apply an rcsmerge on these kinds of files, then it would be ideal. Yes, what you say is all very well and fine. What it means though is that CVS is not the correct tool for use in such a diverse environment. Obviously my point did not sink in properly though so I will say it more clearly: PLEASE go use something else Here is some interesting work in this area: http://www.cs.berkeley.edu/~jmacd/xdelta.html Yes, and I was aware of it well before most of the rest of the community was, but CVS does not xdelta, and in fact cannot without breaking it's current design goal of keeping the repository fully RCS compatible. (note that even though RCS can store binary files, CVS cannot deal properly with RCS'ed binary files in its repository. CVS runs on top of RCS, not the other way around!) We both agree, cvswrappers is a band aid at best. No, if that's what you think then we do not agree. Cvswrappers are a mistake that misleads users into thinking CVS is something that it just cannot be. They can only cause problems. They should never ever have been added to the "official" release. They should in fact be removed before the next major release is made, if indeed anyone ever gets brave enough tot make a "major" release. If some poor user can't find a way to do without them or to use some other more appropriate tool then that user is free to maintain his or her own local version of CVS with them still integrated, and since CVS is free software that user is free to make either the patches or the integrated release freely available too. As to MYSELF developing a new versions management system, there are plenty of people doing that, I would just confuse the situation. If you were to build a tool that filled your needs explicitly, and then freely offered it to the world, just as the authors of CVS and CVS-II originally did, then perhaps you'd clarify things. If not then perhaps you should become an early adopter of whichever of these other new systems you think will in fact actually meet your explicit requirements. The reason I choose CVS is because it is prolific, people I hire are likely going to know about the system. I'd rather fix CVS itself - that is if I get time to do it - along with my 100 other unfinished projects. Then you chose CVS for exactly the wrong reasons and as a result you made the wrong choice because you ignored the fact that it does not meet your real requirements. CVS is not something that tries to gain market share at all costs -- quite the opposite as it is free software that very nicely and properly fills *one* niche in the software configuration management tool set. Because it is free software you are free to mis-use it, but you'd be better off realising that you're also free not to use it at all. Choosing CVS because you percieve that it has market share despite the fact that it obviously does not meet your real requirements demonstrates that you do not understand how to make effective use of free software! Demanding that CVS properly handle binary files either demonstrates that you do not understand your own requirements or you do not understand the goals of free software and the reasons why a tool like CVS would be made freely available. My suggestion to you, as you offered so many to me, is to think about a broader use of CVS as not only a concurrent versions/merging tool but also as a database off all components that are used to build products Excuse me, but CVS is not anything but a *source* code control tool that was *explicitly* designed to support, nay to force, the ability for its users to concurrently edit source files! Anyone who tries to use it for something else, will inevitably run into problems such as you have. - some of which are not text; that I need to version successfully and satisfies the ACID semantics (Atomicity, Consistency, Isolation, and Durability). Then you absolutely need something that is not CVS. Period. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Merge conflict?
Tristan Juricek writes: I'm getting a merge conflict when merging files that only have lines deleted from the branch to the main repository. Essentially what's happening is that we have a build system here that automatically creates user branches for doing work. One of the users made some large deletions to one of his files, then attempted to release those changes. The files that contain the merge conflicts only show that those exact sections had been deleted. I'm wondering if anyone else has seen this behavior. It sounds like it might be the same bug for which one of the cvs maintainers checked in a fix last week. I can't post the actual file that had problems, do to it's proprietary (and very important) status. Try using the command below on the file. It changes it enough that it probably no longer has any significant private info in it, but yet it is usually still possible to reproduce merge bugs with it: sed 's/[a-zA-Z]/x/g' file file_changed I've been unable to simulate the changes as well (much to my frustration). The author of the bug fix, Karl Tomlinson, thought that there are still some cases which his patch does not handle, so it might be good to try to test your case on Karl's patch. I will be glad to help you do that testing if you send me your files after changing with the "sed" command. Karl's patch is here: http://www.mail-archive.com/bug-cvs@gnu.org/msg00554.html ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
restoring an old repository
I've a re-installed Soaris system which has a old CVS repositroy some data included. After OS installation job, I tryed to re-load the previous data. But I can't. I don't know what's matter. What shall I do in this case ? Thanx -0-0- Youngwha, Ko ** E-place Bldg, 719-24, Yeoksam, Kangnam, Seoul, Korea, 135-080. T E L : +822-3467-(5541) F A X : +822-3467-5599 P C S : 016-411-2978 E-ML : [EMAIL PROTECTED] ** ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: Friday, March 30, 2001 4:19 PM To: Gianni Mariani . . . Obviously my point did not sink in properly though so I will say it more clearly: PLEASE go use something else We clearly violently disagree, obviously there is no point in further discussion. Cheers G ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Windows GUI fro CVS
Charles wrote: Part 1.1Type: Plain Text (text/plain) Encoding: quoted-printable Well, TkCVS is cross platform (Unix/Linux/XxxBSD, Win, Mac, whatever else has Tcl/Tk ported to it). We use it and like it. It's also easy to extend for those who need that. Home page -- http://www.twobarleycorns.net/tkcvs.html Docs -- http://www.rubicon.net/~gbr/cvs-info/ -- Lan Barnes [EMAIL PROTECTED] Icon Consulting, Inc 858-273-6677 Key fingerprint = 57D6 C219 140A A81E 26C6 8138 0E62 7F4A 2659 7389 They have computers, and they may have other weapons of mass destruction. - Janet Reno ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
checkout -d . ?
I want to check out directory web/perl to the current directory as just perl. So I use cvs co -d . web/perl This works like a dream on the machine with a local repository. But when I am using a remote repository it complains to me as follows: % cvs co -d . web/perl cvs server: existing repository /cvs does not match /cvs/web/perl cvs server: ignoring module web/perl What gives? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs