RE: Hard Links
--- Forwarded mail from [EMAIL PROTECTED] I will explain: 1) I have 2 directories inside CVSROOT with different names A and B. 2) I have a1,a2 files in A directory 3) I have b1,b2 files in B directory 4) I want that if i modify file a1, b1 should be modified automatically and vice versa 5) If i will modify a2, b2 would be modified automatically and vice versa I don't want to modify the module defination to checkout coomon file from one common location for both these projects As file names a1,b1 are different and same is the case for a2,be but files are exactly copies of each other I can attain this functionality by doing soft links in Linux and can modify the files in wincvs to get my results but not through hard links Have you actually succeeded, using this method, to keep the RCS files identical? I think that the first time you commit a change via the symlink you'll find yourself with two RCS files and your changes will begin to diverge. The reason for this is the way the RCS file locking protocol works: Create a lock file, copy the RCS file to the lock file, merge the change into the lock files, then rename the lock file back to the RCS file. The last time I read the RCS source code, it didn't chase symlinks to their definitive sources and apply changes there; it treated symlinks like files. So when you commit via the symlink, the lock file is created where the symlink is, then the modified RCS file replaces the symlink. By the way, this applies to all operations that modify the RCS file, including tagging and changing keyword expansion. The other problem is that CVS adds a directory level locking protocol to keep the RCS files static while a group of them are updated. Using symlinks to spoof RCS files defeats this because a change to the true source can spring a surprise if the symlink side has also been locked and the update is delayed. The RCS file locking protocol offers no protection from this because the true source could have a new version introduced while the symlink side thinks it's up to date. If you plan to continue using CVS, you'll be way better off refactoring your project so that there's just one true source for these files. If that simply is not possible, then you'll have to adopt a discipline in which you never commit or tag via the symlink; in other words, choose the one true source and modify that, and perform only checkouts and updates on the other side. One More Question: As mentioned by you linking files, you have defeated CVS's locking system and you're asking for a corrupted repository. Soft linking directories isn't dangerous Could you please suggest me more on this The CVS locking mechanisms work on a directory basis, and symlinks to directories within the repository don't affect them. So if you want to have a directory appear in several places (without doing module file calisthenics) then this is a way to do it. But the contents of each instance are obviously identical. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Vendor Branches
Title: Message I wonder if anybody can help me with the following problem regarding multiple vendor branches. I regularly receive code drops from vendors in the form of tarballs. I want to untar them and then `cvs import' to the appropriate vendor branch. Once they are on the vendor branch, I want to tag them and run some unit tests. If the unit tests pass, I want to tag them again, marking them as ready for integration, sort of: tar xvf vendor.tar cd vendor cvs import -b 1.1.3 -m "Latest vendor drop" repository/vendor VENDOR VENDOR_LATEST_ddmm if (unit tests ok) cvs rtag -r VENDOR_LATEST_ddmm INTEGRATION_READY repository/vendor then fi No problems there so far. The problem is that I want to be able to copy the latest version on the vendor branch to the latest version on the INTEGRATION branch, since all integration testing and tagging is to be done from this branch, i.e.: Before: +---+ | 1.1 | +---+ \ \ \ \ /\ | VENDOR | \+---/ | | | +++ | 1.1.3.1 | +++ | +++ | 1.1.3.2 | VENDOR_LATEST_ddmm +++ INTEGRATION_READY After: +---+ | 1.1 | +---+---+ | \ | \ | \ | \ | /\ | | VENDOR | |\+---/ | | | | | | | +++ || 1.1.3.1 | | +++| | | +++ || 1.1.3.2 | VENDOR_LATEST_ddmm | +++ INTEGRATION_READY | | +---+---+ | 1.2 | MERGED-VENDOR_LATEST_ddmm +---+---+ INTEGRATION I have tried various permutations: cvs import as above cd /tmp cvs checkout -rVENDOR_LATEST_ddmm repository cvs update -A cvs commit and cvs import as above cd /tmp cvs checkout -jINTEGRATION -rVENDOR_LATEST_ddmm repository cvs commit But the `commit' part either does nothing, or reports 'up-to-date check' failures. Is what I am hoping to do impossible? Anybody dealt with a similar scenario? Many thanks IA. John. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
installation of CVS on RedHat Linux
Hi Iam very new CVS and i installed CVS 1.11 on RedHat Linux(on which bugzilla is already installed) by following the instructions mentioned in http://cvsbook.red-bean.com/cvsbook.html#Getting_And_Installing_CVS these r the steps -- floss$ ./configure creating cache ./config.cache checking for gcc... gcc checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking how to run the C preprocessor... gcc -E (etc) When the configure command finishes, the source tree will know everything it needs to know about compiling on your machine. The next step is to type: i could execute all these steps floss$ make You'll see lots of output fly by, then type: floss$ make install after this step , what exactly i have to do ? how to access my CVS ? Does it have any GUI ? how can i know whether my installation is successful or not ? is it possible to access it on browser through webserver ? Any help is appriciated Regards Rajan. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Query about removed files
Johnny John writes: When I do a cvs status, I obtain the following. Query: why is the status different for the two? === File: no file file1.sStatus: Needs Checkout Working revision:No entry for file1.s Repository revision: 1.30/repository_path/Attic/file1.s,v === File: no file file2.mStatus: Up-to-date Working revision:No entry for file2.m Repository revision: 1.3 /repository_path/Attic/file2.m,v What does cvs log -r HEAD say about the files? My guess is that the first has a state other than dead, probably caused by an incomplete resurrection attempt, whereas the second is truly dead. -Larry Jones Your bangs do a good job of covering up the lobotomy stitches. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs hangs while reporting 'version'
Harig, Mark A. writes: The above is NOT a typo. After 'read(5,', the output hangs with the cursor following the '5,'. I have left this run for nearly thirty minutes to see if there was a timeout condition, before using 'Ctrl-C' to halt the command. Try upgrading to the recently-released CVS 1.11.4. -Larry Jones What a stupid world. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: installation of CVS on RedHat Linux
Rajan writes: floss$ make install after this step , what exactly i have to do ? how to access my CVS ? Does it have any GUI ? how can i know whether my installation is successful or not ? is it possible to access it on browser through webserver ? Read the rest of the book, or the CVS manual and/or the other documentation you'll find at www.cvshome.org. -Larry Jones What a waste to be going to school on a morning like this. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Vendor Branches
[ On Saturday, January 4, 2003 at 20:05:46 (-), John Birtley wrote: ] Subject: Vendor Branches The problem is that I want to be able to copy the latest version on the vendor branch to the latest version on the INTEGRATION branch, since all integration testing and tagging is to be done from this branch, i.e.: You cannot safely mix normal branches in modules with vendor branches and still expect full and normal functionality from CVS. To do what you want you'll have to manually import (i.e. copy and add) new vendor releases to a normal branch and then manually merge to the other branches you wish to maintain.. BTW: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN Please DO NOT EVER send HTML, rich text, or otherwise stylized e-mail, especially not to me or to any public mailing list. Not all mail readers will recognize such formats, and their added volume is generally a total waste of bandwidth, storage, and processing power for everyone. HTML in particular is a potential security threat and many firewalls and some mailing lists filter it entirely -- especially since CERT and Microsoft have jointly anounced a very major flaw in the HTML rendering engine used in all Microsoft products (in versions still widely in use, and which isn't even properly fixed in the most recent releases). For more information see, for instance, the following article: http://www.georgedillon.com/web/html_email_is_evil.shtml Please send all your messages as plain text only. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Query about removed files
Exactly as you say. How can I get the state of the first to be dead again? Do another remove? At 05:22 PM 1/4/03 -0500, Larry Jones wrote: Johnny John writes: When I do a cvs status, I obtain the following. Query: why is the status different for the two? === File: no file file1.sStatus: Needs Checkout Working revision:No entry for file1.s Repository revision: 1.30/repository_path/Attic/file1.s,v === File: no file file2.mStatus: Up-to-date Working revision:No entry for file2.m Repository revision: 1.3 /repository_path/Attic/file2.m,v What does cvs log -r HEAD say about the files? My guess is that the first has a state other than dead, probably caused by an incomplete resurrection attempt, whereas the second is truly dead. -Larry Jones ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Vendor Branches
I have a simple what about this I'd like to comment on, regarding the expressed rich text e-mail is always bad-attitude. In this specific case, I think it _is_ ok to use stylized e-mail, since the diagrams would be rendered with MUA:s showing mail with non-fixed width characters. (It _is_ easier to read spoken language texts on screen with a typeface which does not use fix width characters.) However, in all other cases, I agree that it's a waste of bandwidth/cpu-time to send HTML mail. / Fredrik -- In response to Greg, who wrote: Please DO NOT EVER send HTML, rich text, or otherwise stylized e-mail[...] Please send all your messages as plain text only. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Vendor Branches
Thanks for the reply. I'll try and write some scripts to do it the copy and add way. My sincere apologies for the HTML - I recently set up this machine and I hadnt checked the mail format. HTML was the default - thanks for pointing it out. -Original Message- From: Greg A. Woods [mailto:[EMAIL PROTECTED]] Sent: 04 January 2003 23:25 To: John Birtley Cc: [EMAIL PROTECTED] Subject: Re: Vendor Branches [ On Saturday, January 4, 2003 at 20:05:46 (-), John Birtley wrote: ] Subject: Vendor Branches The problem is that I want to be able to copy the latest version on the vendor branch to the latest version on the INTEGRATION branch, since all integration testing and tagging is to be done from this branch, i.e.: You cannot safely mix normal branches in modules with vendor branches and still expect full and normal functionality from CVS. To do what you want you'll have to manually import (i.e. copy and add) new vendor releases to a normal branch and then manually merge to the other branches you wish to maintain.. BTW: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN Please DO NOT EVER send HTML, rich text, or otherwise stylized e-mail, especially not to me or to any public mailing list. Not all mail readers will recognize such formats, and their added volume is generally a total waste of bandwidth, storage, and processing power for everyone. HTML in particular is a potential security threat and many firewalls and some mailing lists filter it entirely -- especially since CERT and Microsoft have jointly anounced a very major flaw in the HTML rendering engine used in all Microsoft products (in versions still widely in use, and which isn't even properly fixed in the most recent releases). For more information see, for instance, the following article: http://www.georgedillon.com/web/html_email_is_evil.shtml Please send all your messages as plain text only. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Vendor Branches
On Sat, 4 Jan 2003, John Birtley wrote: Date: Sat, 4 Jan 2003 20:05:46 - From: John Birtley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Vendor Branches I wonder if anybody can help me with the following problem regarding multiple vendor branches. Meta-CVS has a feature like vendor branching, but sane. The ``grab'' command is conceptually similar to import, but it uses an ordinary branch (that you create beforehand). Thus it can keep track of external patches relative to any baseline you choose. Moreover, grab figures file moves and renames, as well as symbolic link reconfigurations. Because Meta-CVS keeps track of repeated merges from the same source, merging the results of successive grabs is painfully simple: mcvs grab -r vendor-branch module # verify renames, look at diffs, etc. mcvs ci mcvs sw integration-branch # switch to integration branch mcvs merge vendor-branch # merge from vendor-branch # resolve conflicts, verify mcvs ci Grab doesn't do anything to the repository; it converts your working directory into a sandbox of the specified module, containing the would-be import as local changes. cvs import as above cd /tmp cvs checkout -jINTEGRATION -rVENDOR_LATEST_ddmm repository cvs commit Merging requires two -j options, except when it's the first time it's done from a branch to the trunk. You must use tags to keep track of the last merged point. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Query about removed files
Johnny John writes: Exactly as you say. How can I get the state of the first to be dead again? Do another remove? Yep. -Larry Jones He just doesn't want to face up to the fact that I'll be the life of every party. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Vendor Branches
[ On Sunday, January 5, 2003 at 02:43:44 (+0100), Fredrik Wendt wrote: ] Subject: Re: Vendor Branches I have a simple what about this I'd like to comment on, regarding the expressed rich text e-mail is always bad-attitude. In this specific case, I think it _is_ ok to use stylized e-mail, since the diagrams would be rendered with MUA:s showing mail with non-fixed width characters. Sorry that's just bogus. First off if a modern computer that can read e-mail doesn't have a fixed-width font then it's certainly not going to be able to interpret HTML or any other rich-text format. Secondly, if an accurate and detailed diagram is that important then the poster can include a URL to a proper graphic file (or if it's reasonably small, such as about 20KB or less, attach it directly to the email using MIME). HTML e-mail is ALWAYS bad, especially on a public mailing list. (It _is_ easier to read spoken language texts on screen with a typeface which does not use fix width characters.) That's irrelevant. You can read your e-mail using any typeface you please, but if you'd like to clearly see a diagram represented with text characters then I'm sure you will know when to switch to an appropriate fixed-width typeface. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
