Re: Merging on Vendor releases
On Mon, Dec 02, 2002 at 07:03:36PM +0100, Fabio Fracassi wrote: > What I like to do is porting one local change at a time e.g. I > have the following tags > > VendorRelease > basicChanges > extension1 > extension2 > product > > I'd like to take the new Vendor version and first apply the basicChanges, > then test and debug the whole mess, and then go on with extension1 and so on. > This is indeed a complicated operation. I have not attempted this myself, and I believe you should consider doing the merge in a signle step, but then again it depends on the complexity of the local changes. If you still want to do a piecemeal merge you should go like this, but *do* take my words with a grain of salt! First create a branch rooted at "basicChanges", like this: cvs rtag -b -r basicChanges b_basicChanges Then checkout from this branch: cvs co -r b_basicChanges Then merge the vendor changes in it: cvs update -j VendorRelease -j VendorRelease_new Fix the conflicts, test and make sure everything works fine. Then commit in the branch: cvs commit Then merge in the branch the "extension1" changes: cvs update -j basicChanges -j extension1 Again resolve the conflicts, and commit. cvs commit Finaly merge the "extension2" changes: cvs update -j extension1 -j enxtension2 Resolve the conflics and commit for the final time. /npat -- default, n.: The vain attempt to avoid errors by inactivity. -- Stan Kelly-Bootle ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merging in CVS
On Fri, Nov 22, 2002 at 11:35:17AM -0500, MacMunn, Robert wrote: > > When I merged 2 files I got extra lines teling me where the merged lines > where. > Is there any way around this ? The extra lines with and > appear only when there are conflicts in the merged files. They are a feature, not a bug, since they indicate that CVS cannot decide, by itself, what to do. You have to manually edit these places. /npat -- A commune is where people join together to share their lack of wealth. -- Richard M. Stallman ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: vendor branch imports, deleted files
On Thu, Oct 31, 2002 at 04:30:11PM -0500, Larry Jones wrote: > > (note that you *MUST* use the actual release tags for this to work as > opposed to using "branch:yesterday" or any similar schemes) Why -- Developing skills that depend on a proprietary product makes you a sharecropper on your own brain. -- Donald B. Marti Jr. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: vendor branch imports, deleted files
On Thu, Oct 31, 2002 at 12:43:18PM -0800, Kaz Kylheku wrote: > On Thu, 31 Oct 2002, Nick Patavalis wrote: > > Did you complete the merge merge from the vendor branch by > doing the update/checkout -j old -j new ? > Oooops! You're right! /npat -- He who joyfully marches to music in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would fully suffice. -- Albert Einstein ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
vendor branch imports, deleted files
I see that when I import a new vendor version (to the vendor branch), files that have been removed by the vendor (but not modified by me) are not removed. Is this a bug or a feature? Any sugestion for an easy way to find and remove these files? Thanks /npat -- In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. -- Douglas Adams, The Hitchhiker's Guide to the Galaxy ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
When are keywords substituted?
Reading from the CVS (info) manual [keyword substitution / using keywords]: To include a keyword string you simply include the relevant text string, such as `$Id$', inside the file, and commit the file. CVS will automatically expand the string *as part of the commit operation*. Is this true? I thought that expansion occured as a part of the *export* (cvs checkout, cvs diff, cvs export, etc) operations. /npat -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Web frontend
On Fri, Oct 25, 2002 at 01:03:40PM -0500, Steve Buehler wrote: > Does anybody know > of a few that I can checkout? Try "http://freshmeat.net"; and search for CVS. I am sure you will find some. I hava not used any, but I am certain I've seen a few when I was looking arround. /npat > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > ow3 > > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs > -- Mathematics belongs to God. -- Donald E. Knuth ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Stow
On Fri, Oct 25, 2002 at 02:07:22PM -0400, Eric Siegerman wrote: > > Stow (http://www.gnu.org/software/stow/stow.html) is excellent > for this! It's basically a package manager, but an extremely > lightweight one. > I agree. Stow rules! It is a fine example of treating problems with a purelly "unix" philosply (don't develop milions of lines of buggy C code for something that can be solved using a few scripts). > - Don't be anal about it. Some packages expect to be in their > own subdirectories, rather than dispersed throughout > /usr/local. Humour them. Be willing to let Apache go > directly into /usr/local/apache as it prefers, rather than > being stow-managed. Or if you want multiple versions, put > them in /usr/local/apache- and make the (single) > symlink by hand. Likewise Java JREs and SDKs. I totaly agree, though I would suggest putting these "anal" packages in a different hierarchy altogether. Everything inside "/usr/local" should be stow-managed. A good place for those would be under "/opt" /npat -- Morality is always the product of terror; its chains and strait-waistcoats are fashioned by those who dare not trust others, because they dare not trust themselves, to walk in liberty. -- Aldous Huxley ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Per-modules readers/writers ?
On Thu, Oct 24, 2002 at 04:49:08PM -0400, David R. Chase wrote: > Hello there, > > I'm mainly trying to obtain > finer granularity access control via pserver (or other remote access) > authentication rather than via the filesystem's uid/gid and related > permissions. What's wrong with uid/gid based permissions? /npat -- A commune is where people join together to share their lack of wealth. -- Richard M. Stallman ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Info about tags
On Thu, Oct 24, 2002 at 09:10:30AM -0500, Todd Denniston wrote: > Nick Patavalis wrote: > > > > Take for instance this very real example (my source-tree is a > > linux-kernel): > > > > cvs status -v Makefile > > > > === > > File: Makefile Status: Up-to-date > > > >Working revision:1.1.1.2 Wed Oct 23 16:20:33 2002 > >Repository revision: 1.1.1.2 /home/npat/new_kernel/cvsroot/arm-linux/Makefile,v > >Sticky Tag: (none) > >Sticky Date: (none) > >Sticky Options: (none) > > > >Existing Tags: > > T10 (revision: 1.1.1.2) > > T9 (revision: 1.1.1.2) > > T8 (revision: 1.1.1.2) > > T7 (revision: 1.1.1.2) > > T6 (revision: 1.1.1.2) > > T5 (revision: 1.1.1.2) > > T4 (revision: 1.1.1.2) > > T3 (revision: 1.1.1.2) > > T2* (revision: 1.1.1.2) > > T2 (revision: 1.1.1.1) > > T1 (branch: 1.1.1) > > > > and try to answer: > > > > which tag represents the most recent vendor-branch import? > > > > easy follow the magic vendor branch 1.1.1.x, T10 is probably the tag that > represents the most recent vendor-branch import. No, as a matter of fact it's T2* ! > now the 'T2 (revision: 1.1.1.2)' and 'T2 (revision: 1.1.1.1)' looks > funny, Ok, this is a typo (I obviously edited the TAG names!). I 've flagged the "second" T2 as "T2*" > OK, wait a second...I see why you chose this file...I can not be > SURE that the tag was applied during an import, I only assumed it > was because it followed the form of the ones used for import, and I > believe than any sane (or one who wanted to stay that way) person > would use a different form of tag for their own work than they did > for imports. I would need at least one more set of history to figure > it out for sure. You got me. Yep! That's the point. > Yep that's right I am about to mention cvs2cl.pl again. Looks helpfull, I 'll try it, but what I would like is a tool that produces an output like this: *Trunk* TAG1 TAG2 Branch0 TAG4 TAG5 Branch1 TAG6 TAG7 Branch1_0 TAG8 TAG9 Branch3 TAG10 or something similar. /npat -- In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. -- Douglas Adams, The Hitchhiker's Guide to the Galaxy ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Info about tags
On Thu, Oct 24, 2002 at 09:24:41AM -0700, Johnson, Susan wrote: > Nick, I would need a tool like that too. People have > pointed me to winCVS (windows tools) but I really > want a command-line-based output. Looking arround I found a very interesting little perl program. I's called "cvs-exp", its written by Sitaram Iyer <[EMAIL PROTECTED]>, and can be found at: http://www.cs.rice.edu/~ssiyer/code/cvs-exp/ It's not very sophisticated (you cannot actually "query" about the global repository status), but it does produce a tree like the one I was looking for. See for example the output of a test-run at one of my repositories: $ cvs-exp.pl arm-linux 2> /dev/null HEAD |- [VANILLA_ARM] <9241 files> | |- R2_4_5_RMK2_NP1 <9198 files> | `- R2_4_5_RMK7_NP1 <9231 files> |- clean_arm <9241 files> |- DECON_20010719 <9243 files> |- PRE_MODEMCTL_PATCH <9243 files> |- POST_MODEMCTL_PATCH <9243 files> |- POST_MODEMCTL_PATCH1 <9243 files> |- POST_MODEMCTL_PATCH2_RMKFIX <9243 files> `- LATEST_KERNELS_EXP <9258 files> Nice huh? /npat -- Hey, maybe I could apply for a saint-hood from the Pope. Does somebody know what his email-address is? I'm so nice it makes you puke. -- Linus Torvalds ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Info about tags
On Thu, Oct 24, 2002 at 08:15:30AM -0400, James Hughes wrote: > > > Nick Patavalis wrote: > > What tags exist, listed in chronological order? > > > > What are the names of the tags corresponding to vendor-branch > > imports, in chronological order? > > > > What tags exist in a specific branch? > > cvs status -v will provide much (all?) of the above. No it won't! I have to know to *which* file to run "cvs status" in order to get the info I want. And depending on the tag I'm interested in, it might not be sufficient to do "cvs status" on one file alone! Take for instance this very real example (my source-tree is a linux-kernel): cvs status -v Makefile === File: Makefile Status: Up-to-date Working revision:1.1.1.2 Wed Oct 23 16:20:33 2002 Repository revision: 1.1.1.2 /home/npat/new_kernel/cvsroot/arm-linux/Makefile,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: T10 (revision: 1.1.1.2) T9 (revision: 1.1.1.2) T8 (revision: 1.1.1.2) T7 (revision: 1.1.1.2) T6 (revision: 1.1.1.2) T5 (revision: 1.1.1.2) T4 (revision: 1.1.1.2) T3 (revision: 1.1.1.2) T2 (revision: 1.1.1.2) T2 (revision: 1.1.1.1) T1 (branch: 1.1.1) and try to answer: which tag represents the most recent vendor-branch import? /npat -- I xeroxed a mirror. Now I have an extra xerox machine. -- Stephen Wright ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: tag vs rtag question
On Wed, Oct 23, 2002 at 02:24:47PM -0700, Shankar Unni wrote: > > The problem was, if one of the files was *deleted* on the branch, cvs > tag wouldn't move the tag for that file - you'd have to use cvs rtag for > it. The developer in question had done separate "cvs rm"s on the > mainline and the branch, but since the deleted version on the branch > wasn't tagged, when I did the next merge from the branch to the > mainline, the deleted file "reappeared". > Oh, I see. You mean that you were using the *same* tag-name and you were just "pushing" it forward to more recent revisions, and that this didn't behave well when the "push" was "crossing" a delete operation! Tricky, indeed! /npat -- Don't ever think you know what's right for the other person. He might start thinking he knows what's right for you. -- Paul Williams, `Das Energi' ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: tag vs rtag question
On Wed, Oct 23, 2002 at 01:58:27PM -0700, Shankar Unni wrote: > > I would think that with the situation above, doing a cvs tag > > VENDOR_R2_MERGED in the working directory where conflict resolution > > was finished would be the safest method, to be sure you tagged the > > resolved files and not something else. > > On the other hand, if you have *deleted* a file, cvs tag won't tag the > repository file. This can lead to interesting "file reappearing in my > workarea" problems when others update to the tag.. Can you elaborate a bit on this? You mean deleted by the developers while working in the branch, or while doing conflict resolution in the trunk? /npat -- Dijkstra probably hates me -- Linus Torvalds, in kernel/sched.c ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: tag vs rtag question
On Wed, Oct 23, 2002 at 11:02:10PM +0300, Nick Patavalis wrote: > > ...Though I also have some confused ideas about what exactly HEAD > means. Could please a CVS guru give us a precise *definition* of what > the HEAD tag is? > Looking arround I find this which comes close to being a precise definition (posted in the cvs-bug list, by Philip Guenther, reference below): I think the question needs to be asked: what do people expect (when they specify the -rHEAD option [npat])? There are two logical possibilities: 1) always return the last revision on the default branch. Under normal circumstance (no use of cvs admin), this'll either be: a) the tip of the vendor branch for imported and still unmodified files; or b) the tip of the rcs main branch (a.k.a. the trunk) for all other files. Note that this is what a plain checkout will give you. cvs currently does this for all **but** cvs diff 2) The tip of the current (logical) branch, i.e., follow sticky tags. When no sticky tag is in effect, this reverts to the above. cvs diff does this. Reference: http://mail.gnu.org/pipermail/bug-cvs/1996-June/002054.html /npat -- In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. -- Douglas Adams, The Hitchhiker's Guide to the Galaxy ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: tag vs rtag question
On Wed, Oct 23, 2002 at 01:49:36PM -0500, Todd Denniston wrote: > Nick Patavalis wrote: > > > > You merge the local changes > > > > cvs co -j VENDOR_R1 -j VENDOR_R2 > > > > You resolve the confilicts, test the new sources, and generaly make > > sure that everything is stable. Then commit your changes. Several > > commits may be necesairy since the conflict resolution may take some > > time. No problem though since the rest of the developers are safely > > isolated in the VENDOR_R2_MERGE branch). When you have finished with > > the conflict resolution and tests you tag the trunk accordingly > > > > cvs rtag VENDOR_R2_MERGED > > > > If at the point the rtag is ran above the last commit of a file happened > on the > branch would rtag place the tag on the HEAD version of the file (what we want > here, I think) or on the branch version of the file? The tag will be placed on the most recent revision of the trunk (i.e the HEAD). ...Though I also have some confused ideas about what exactly HEAD means. Could please a CVS guru give us a precise *definition* of what the HEAD tag is? > I would think that with the situation above, doing a cvs tag > VENDOR_R2_MERGED in the working directory where conflict resolution > was finished would be the safest method, to be sure you tagged the > resolved files and not something else. True! /npat -- flowchart, v.: To obfuscate (a problem) with esoteric cartoons. -- Stan Kelly-Bootle ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Info about tags
Is there any way to get, via a script of something, information about the tags in a CVS-controlled tree? I want for example to answer the questions like the following: What tags exist, listed in chronological order? What are the names of the tags corresponding to vendor-branch imports, in chronological order? What tags exist in a specific branch? etc /npat ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merging from vendor-branch to branch
On Tue, Oct 22, 2002 at 08:28:43PM -0400, Greg A. Woods wrote: > > In effect, that after the import a user checking out from the branch > > might get files from the newer vendor version? > > No, that's one thing that shouldn't happen. Indeed that's part of the > problem though -- after an import and merge then the local branch will > still be stuck with base revisions of locally un-modified files at the > pre-import level and those files will explicitly have to have their new > vendor revisions merged to the branch. > I tought that the procedure could be carried out like this. Before importing the new vendor version (say R2, while the previously imported one was R1), ask the developers to commit everything. Then you create a normal branch: cvs rtag VENDOR_R2_PREMERGE cvs rtag -b -r VENDOR_R2_PREMERGE VENDOR_R2_MERGE You ask the developers to work with the VENDOR_R2_MERGE branch, by checking out their sources like this: cvs co -r VENDOR_R2_MERGE You procceed with the import cvs import -m "Imported VENDOR verion R2" VENDOR VENDOR_R2 You merge the local changes cvs co -j VENDOR_R1 -j VENDOR_R2 You resolve the confilicts, test the new sources, and generaly make sure that everything is stable. Then commit your changes. Several commits may be necesairy since the conflict resolution may take some time. No problem though since the rest of the developers are safely isolated in the VENDOR_R2_MERGE branch). When you have finished with the conflict resolution and tests you tag the trunk accordingly cvs rtag VENDOR_R2_MERGED Then you ask your developers to commit everything (in the VENDOR_R2_MERGE branch) and then to merge the branch back to the trunk (each developer his own submodule). cvs co -j VENDOR_R2_MERGE They will also (the developers) have to resolve the conflicts but there shouldn't be many since a few changes would have been made since the branch. As you can understand the idea is to make a branch that isolates the developers durring the "turbulent" meging period. Do you see any drawbacks with this approach? /npat -- flowchart, n.: The innumerate misleading the illiterate. "A thousand pictures is worth ten lines of code. -- Stan Kelly-Bootle ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merging from vendor-branch to branch
On Tue, Oct 22, 2002 at 06:16:31PM -0400, Greg A. Woods wrote: > It's not really safe to use "normal" branches in a vendor-branched > module, at least not one in which you plan to do more "cvs import"s to > the vendor branch. > What do you mean!?! That if I create a branch (a normal branch), and latter do a "cvs import", then files on the *branch* can be affected? In effect, that after the import a user checking out from the branch might get files from the newer vendor version? If this is so, then... well, this makes vendor-sources tracking (importing) almost useless!! I thought that I could always create a branch, ask the developer to work in it (instead of the trunk), and when when the trunk has stabilized ask them to switch back to the trunk. If this is not possible, then the whole idea of tracking 3rd party sources is unrealistic! > I've not tried to very carefully create a branch only on the trunk and > to merge "up" the head of the vendor branch to this branch, and then to > do an import and to do a merge on a branch. huh? > If that's the case then you would be better off to forget "cvs > import" and simply always do full merges on a "normal" branch > created for the vendor (where you manually check in and manually tag > new vendor releases instead of importing them). How could you do this? When you get new sources from the vendor you "hand-import" (i.e. manually commit) them to the "normal-vendor" branch (assuming it only contains sources form the previous vendor version, and no local changes). This means that you have to sort out which files were added and which files were deleted manually, or write a script for this. This far I understand. Then what you do about "local" changes. I don't quite get your scheme. /npat -- A commune is where people join together to share their lack of wealth. -- Richard M. Stallman ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Merging from vendor-branch to branch
We have a cvs tree, on which we work for quite some time now since the sources were first imported. As a result a considerable amount of changes have been collected. Now the "vendor" has shiped a new version and we would like to merge the changes back to our tree. Due to the complexity of the task the mege will take several days. If we follow the normal merging procedure the main-trunk (used by all the developers not normally involved in the merge operation) will remain unstable for all that period. So I'm wondering if it would be possible to perform the whole merging proccess on a branch and only when we 're finished (and reasonably sure that the resulting source-tree is stable) merge from this branch to the main trunk? How can this be done, if at all possible? What are the sugested practices for similar cases (not wanting to destabilizing you trunk durring a painfull merging period)? Thanks in advance /npat -- Mathematics belongs to God. -- Donald E. Knuth ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
