Re: merge or branch?
From: Christine Freight ([EMAIL PROTECTED]) I am having a dispute with a co-worker over how to do something in CVS. I was wondering if anyone out there can help? Here's the situation: A branch (let's call it branchA) gets created off the main line. Then, at some point in time, a branch (branchB) gets created off of branchA. Development continues down branchA, and a new directory, with new files, gets added and committed on branchA. This new directory is obviously not on branchB, since it was created after branchA was created. Question: how does one get the new directory from branchA onto branchB? I would merge the branchA changes into branchB cvs co -r branchB everything cd everything cvs update -d -j branchB_origin -j branchA new_directory cvs commit -m 'merged new_directory from branchA' You did create a tag (branchB_origin, above) to mark the beginning of branchB, right? Also, partial merges like this, (mergiing in _just_ the new_directory) instead of the whole branch, can make it difficult to keep track of what's merged and what's not later on, so be careful and use tags liberally to keep things straight.. So you'd probably want to tag branchA to indicate which portion was merged into branchB. Something like: cvs rtag -r branchB_origin branchA_merged_to_branchB everything cvs rtag -F -r branchA branchA_merged_to_branchB new_directory so that future merges from A to B could use this tag as a starting point and not have re-merge the same changes again. -- steve __ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
new version of .trunk + .origin patch
Hi,
For anybody using my .trunk + .origin patch,
( http://www.geocities.com/dotslashstar/branch_patch.html ):
I have a new version. I found a tiny problem if
you specify .origin by itself, (which is not allowed
anyway) it would add an invalid line into the val-tags
file.
If you do, for example:
cvs update -r .origin module
It will say you can't use .origni alone, but,
it will also put a bad line into the val-tags
file.
This patch to tag.c, below, (on top of the previous
complete patch) fixes that.
I also put up a new complete patch at the above
URL that includes this latest fix, and is made
relative to the current development version of
CVS.
I noticed this problem after updating to the
recent changes to myndbm.c, which made my problem
readily apparent, (at least I think that's why it
suddenly became apparent).
-- steve
--- tag.c.orig Wed Sep 19 15:41:48 2001
+++ tag.c Wed Sep 19 14:55:59 2001
@@ -1216,6 +1216,12 @@
/* than '.' */
*dot = '\0'; /* lop off the .origin */
+ if (strcmp(name, ) == 0) {
+ /* We don't want to add an empty tag into val-tags */
+ /* if .origin is specified alone. */
+ free(name);
+ return;
+ }
}
/* Special tags are always valid. */
__
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
testing different versions of client/server against each other
Tinkering around with my .trunk + .origin patch, I realized if it were ever to make it into mainstream CVS, there will inevitably be interaction between unpatched clients and patched servers and also between patched clients and unpatched servers. One would hope that they would behave reasonably well together, but right now the patch takes no special actions to determine if the other side of the connection is patched or unpatched. I think there might be some things that neither work nicely nor fail to work nicely if you attempt to use the new features and only one of the client/server pair is patched to handle it. (e.g. if you have an unpatched client, you can still get away with cvs co -r .trunk modulename, and various other things appear to work anyway) I don't know that _everything_ works right though. I was looking at sanity.sh to see if there was a way I could specify a different CVS for the server vs. the client. There's a CVS_SERVER variable, but in the TODO list at the end, it seems this is to be removed, and may have been partially removed already. So, two questions 1) Is there any easy way to get sanity.sh to test different versions of client and server against each other? (more to characterize the breakage than anything else) and 2) would it be a good idea for client and server to give each other some idea of what they can and cannot tolerate? For this latter, I suppose the simpler the better, maybe exchange version numbers and compare against a list of konwn-to-work-with (or maybe, known-not-to-work-with) and proceed or not based on that? How has this kind of thing been handled before? Or maybe it never came up? -- steve (the patch I refer to is here: http://www.geocities.com/dotslashstar/branch_patch.html ) __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS tags
Tim Wensink wrote: Hello all, I have a question regarding CVS tags. I want to have a list of files that are in a certain release. Is there a command within (win)cvs that allows me to specifiy a certain tag and then generates a list of all the files that have that tag? Saw lots of responses to this with various options to cvs co... In the past, people have mentioned that cvs rdiff -s works well. cvs rdiff -s -r 0 -r some_tag some_module Gives you not just the filenames, but the revisions numbers too (Assumes you have no file with a revision of 0, which you don't most likely.) example: [scameron@zuul usrc]$ cvs rdiff -s -r 0 -r efs_x42_dev_br autobuild cvs server: Diffing efs/unix/autobuild File efs/unix/autobuild/autobuild is new; current revision 1.11.2.1 File efs/unix/autobuild/autobuild.html is new; current revision 1.4 File efs/unix/autobuild/build_warning is new; current revision 1.3 File efs/unix/autobuild/devel_list.txt is new; current revision 1.10.2.2 File efs/unix/autobuild/dist_list.txt is new; current revision 1.12.2.2 [...etc...] __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Maintaining branches...
Ralph Mack ([EMAIL PROTECTED]) wrote: [...] What I'm reading about branching and merging makes me think that a branch-merge pair on CVS is a one-way trip, that once you have merged from a branch you can't merge to that branch from the updated mainline and then merge back again. Another interpretation is that you have to specify your merge control points (from, to, last common ancestor) manually. For the first merge, CVS can figure the common ancestor (given only one -j option.) For subsequent merges, you don't want it to figure the common ancestor because if you allow it to, it will re-merge in the changes you already merged, potetially causing lots of conflicts that you've already resolved the first time. The typical sequence is something like: 1st merge: cvs tag before_merge_1 cvs tag -r from_branch merge_point_1 cvs update -dP -j merge_point_1 (resolve conflicts) cvs commit -m 'merged up to merge_point_1 from_branch 2nd merge: cvs tag before_merge_2 cvs tag from_branch merge_point_2 cvs update -dP -j merge_point_1 -j merge_point_2 (resolve conflicts) cvs commit -m 'merged up to merge_point_2 from_branch Does CVS branching and merging allow the developer to do the kind of rev-up/promote merge pattern that we do routinely with ClearCase? If you have to specify all three control points, shouldn't CVS be able to figure out the last common ancestor from the merge history? Is this another situation complicated by directories not being versioned? There is no merge history. As far as CVS is concerned, changes commited which are the result of a merge are indistiguishable from a situation where you just typed in those same changes again and commited them. CVS is finished with the merge operation as soon as the cvs update command completes. The subsequent commit is not a merge as far as CVS knows. CVS's idea of merge is, I think, pretty similar to: cvs diff -uN -r abc -r xyz | patch -p0 but with conflicts handled a bit differently With that in mind, your process seems a bit extreme, with more than the usual amount of branching and merging going on, vs. a typical CVS shop...(not that I know what that really is.) Note also, there is a subtle implication that a merge using 2 -j options differs from using just 1 -j option in that with 2 -j options, for files which are removed between the two tags, that removal is merged in without possibility of conflict. This is because for such a merge, CVS can't know that there really is a common ancestor, or what span of revisions to check for conflicting changes. (all it knows is two points... it is very much like running patch) You could be running a reverse merge, for instance, to undo changes, in which case a common ancestor is nonsense. Looking at this more (than I have before) it looks like the code calls RCS_merge in much the same way whether one or two -j options is given, so, assuming cvs update -j rev1 -j ref2, it looks like it takes rev1 to be the common ancestor, when in reality, it may not be a common ancestor at all. I think the magic is in cvs update finding the common ancestor (with one -j) and filling it in for rev1. So, if RCS_merge is taking rev1 to be the common ancestor and the basis for conflict detection, It kind of seems like the same logic should apply for file removals too...if you truncated the file to zero length, that and that would make a conflict, shouldn't deleting it make a conflict too? I'm not 100% sure about that. (Everytime I look at this part of the code it seems a bit weird. Sorry to go off on a tangent.) -- steve __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log options ( was Re: cvs rtag -r BRANCH -D date)
--- Derek R. Price [EMAIL PROTECTED] wrote: Stephen Rasku wrote: cvs admin -o uses a colon syntax to specify a revision range and cvs log uses the same (or similar) syntax to specify revisions (except for the space problem mentioned above) but it uses a different syntax for dates. First of all, it uses -d instead of -D and it uses a greater than/less than syntax. I would prefer using a -D syntax that mirrors the -r syntax. So you would do some thing like this: cvs log -D date -D now cvs log -D start -D date cvs log -D date1 -D date2 etc. This sounds usable. I would also change the -r option so that it matches cvs update and cvs diff. It would work like this: cvs log -r rev1 -r rev2 cvs log -r rev.origin -r rev cvs log -r rev -r HEAD cvs log -r branch cvs log -r branch1 -r branch2 Hmm... interesting. This might be doable without loss of functionality in conjunction with Stephen Cameron's .origin/.trunk patch. I'd like more feedback on Cameron's patch before adoption, though. If you'd like to download and try it, Steve keeps it at http://www.geocities.com/dotslashstar/branch_patch.html . Some testing of the patch with vendor branches is probably mandatory before integration too. (Perhaps someday I'll just happen to need a vendor branch for something, and finally get around to that...) Just a couple comments (not really relating to how this might fit in with my patch): There is this comment in log.c: /* Unfortunately, rlog accepts -r without an argument to mean that latest revision on the default branch, so we must support that for compatibility. */ if (argstring == NULL) argstring = ; The implication is that no space is allowed between -r and its argument, if this compatibility the comment refers to is something we want to keep. (I do know that this no space requirement has tripped me up a number of times. Maybe this is the space problem alluded to...I didn't see the first message(S) in this thread (yet).) Specifying revision ranges for log makes sense in the typical cases, but perhaps not in the general case, as you could give two revisions on completely separate branches. You can diff those, but what to do for log messages? There aren't any. (And maybe that's the answer, ask a silly question, CVS gives a silly answer: the empty set of log messages.). But, by doing that, the results of log used against multiple files at once with two tags could be misleading since for some files no log messages may show due to two revisions specified being added separately to separate branches (for example) while for other files log messages show up, so that certain types of changes would be masked, and presumably this masking effect would be counter to the reasons you're running cvs log in the first place. Maybe a message like No loggable revision sequence between revisons 1.2.2.4 and 1.2.4.9 esists for foo.c, or prefereably something clearer, would suffice. Arguably, log is most commonly used on a single file at a time, (by me anyway) [...] -- steve __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: -jHEAD:yesterday
Tony Mantler wrote: basically I type... cvs update -jHEAD -jHEAD:yesterday and it doesn't do what he expects. Well, I don't know what to say about that, but at the very least, you did lead me to find a gaping hole in my .trunk patch. I tried cvs update -j.trunk -j.trunk:yesterday to see if that would work any better...well, it cores... yikes. I suspect that may happen with any branch + date construct where branch == .trunk The patch I'm refering to is here: http://www.geocities.com/dotslashstar/branch_patch.html -- steve __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Put .deps directories in .cvsignore files?
Hi, I've checked out CVS sometime ago from cvs.cvshome.org, and now I do: [scameron@zuul ccvs]$ cvs -z3 -nq update ? lib/.deps/argmatch.Po ? lib/.deps/dup2.Po ? lib/.deps/fncase.Po [ ... loads more ? files...] ? src/.deps/[loads of ? files...] Should there be .cvsignore entries for these .deps directories? Or is there a reason not to? thanks, -- steve __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
deleting branches
Donald Sharp wrote: I have a user who manged to delete a branch( it looks like with the cvs rtag -d command ). When I went poking at the ,v file it looks like the revisions for that branch are still around. Is it ok to just put the branch name and revision back into the ,v files? Yes, I think so, but you have to use the magic branch revision,(with a zero in it in the next to last part of the rev number.) This can be a little tricky to figure out, conceivably impossible in some cases). There was a thread some time ago on recovering a lost branch tag. In the general case, it is not possible, though in specific cases (possibly most cases?) it can be done. If you have a revision a.b.c.d, the branch revision could be a.b.0.c, but, if the file has not been changed on that branch, it would be something else, and that's where the trouble comes from. (I think I got that right...) See: http://groups.google.com/groups?hl=enlr=safe=offic=1th=9c603ed65ed2e6a4,11seekm=fa.olakjtv.dhsqp9%40ifi.uio.no#p (go to groups.google.com and search for Deleted Branch Tag if you don't want to type in that URL.) If you created a non-branch tag initially when the branch was created to mark the origin, you are in better shape than if you didn't. (This would be an argument _against_ my .origin patch http://www.geocities.com/dotslashstar/branch_patch.html) However, you cannot just do cvs rtag -b -r my_branch_origin_tag lost_branch_tag everything It might make sense to change CVS so that it balks at deleting a branch tag unless you give it some option to let it know that you know that you're deleting a branch tag, so that you don't inadvertently do so when you mean only to delete a regular tag. I say this because there is almost never a sane reason to delete a branch tag. Even if you create one by mistake, what harm is there in leaving it lying around? And if there are revisions on the branch, then deleting the branch tag is almost certainly the wrong thing to do, and can be catastrophic. For the case where you have a tag which is non-branch in some files, and a branch tag in others, skip deleting the branch tags...(with warnings about skipping and about the fact that the same tag shows up sometimes as branch sometimes as non-branch.) Or are there people out there happily deleting branch tags willy-nilly as part of normal every day operations? -- steve __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Suggestions for merging system?
One point I forgot to mention in my previous post: I wrote: When a new branch is to be created (when development on a new release is to begin) the current newest branch is merged to the trunk, then the new branch is created off the trunk. What I forgot to mention was that since no development is occurring on the trunk this merge is pretty much guaranteed to be without conflicts, barring accidental commits to the trunk, (which you can roll back prior to attempting the merge anyway.) -- steve __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Suggestions for merging system?
Richard Cobbe wrote that he wanted suggestions about merging... I can tell you what we do, and you can see if it might make sense for you. We do all development and bugfixes on branches. We don't really use the trunk for any development at all. We have "official" branches that everybody knows about, essentially one branch per release. Bugfixes for old releases go on the branch for the old release. Developers are free to create their own branches if they wish to isolate themselves for a while from the rest of the organization, but if their code is to see the light of day, they have to eventually merge it into one of the active "official" branches. In practice, the developers rarely create their own branches it seems. When a new branch is to be created (when development on a new release is to begin) the current newest branch is merged to the trunk, then the new branch is created off the trunk. Lots of tagging and record keeping is done just to keep things straight. (Yes it's a hassle, but necessary, there's no avoiding it, so just take your time and tag it.) Typically we have 2 active branches at any given time, sometimes 3, sometimes just 1. Probably the toughest problem we run into is that occasionally stuff fails to get merged up from older branches to newer branches. "cvs rdiff -s" can catch some of this, (find files on old branches which have been modified since a new branch was created, but which have not yet been modified at all on the new branch, and therefore, must not have been merged.) This problem is probably an artifact of our rather loose development model, in which it is each developer's responsibiltiy to merge his code changes forward. (we do that 'cause there's so much code, no one person could hope to be able to merge it all and sensibly resolve the conflicts.) One person *can* go thru the motions of the merge, at least to see what a full-repository merge *would* do, in order to catch things that developers forgot to merge...) Well, that's one way it can be done, we've done it that way for the last 3 years or so. Hope it helps. -- steve __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Latest .trunk + .origin patch
For any who are interested, I've updated my ".trunk" + ".origin" patch vs. the current (nov 1, 2000) development version of CVS. http://www.geocities.com/dotslashstar/branch_patch.html Only change since last time is change to sanity.sh to account for recent fix to "cvs add" to handle "-Q" option. -- steve __ Do You Yahoo!? From homework help to love advice, Yahoo! Experts has your answer. http://experts.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
[Info-cvs] .trunk + .origin patch
If anybody's interested, I regenerated my ".trunk" + ".origin" patch against CVS 1.11 and made minor cosmetic changes plus added one more test to sanity.sh for "cvs annotate". http://www.geocities.com/dotslashstar/branch_patch.html As always, let me know if you find any problems, or if I've done something in the code that you just don't like. -- steve __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 is now available
Greg Woods wrote: I'm having no end of trouble trying to "cvs update" in my working directory checked out from the anonymous repository... Just a datapoint: I was able to do several "cvs -z3 update" last night ok... and "cvs -z3 diff -c" too... It was kind of slow, but I _was_ on a 56k modem...There was some unexpected changes post 1.11 to doc/cvs-paper.ps in there that took a little while to transmit. But nothing like the delays you're experiencing. -- steve __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How can I list fixes in a BRANCH that have not been applied to MAINLINE?
Alexander N. Spitzer writes: If this is a common question, then I am sorry. I have spent a couple hours on google, and ftp-mailing-list-archives.gnu.org/mailing-lists/info-cvs, and still have no answer question: mainline \ \___branch-1_0_0_ branch-1_0_0 is just bug fixes. Is it possible to get a list of all bug fixes in branch-1_0_0 that were never merged (i.e. forgotten) into the mainline? Short answer: not really. The closest thing I can suggest would be: (supposing you have a top level module called "everything" that means all of your source code...) Just tell CVS to redo the whole merge, but don't commit, instead inspect what it thinks needs to be done. A lot of times, things that are already merged won't show up as diffs if they went in smoothly the first time. cvs co everything cvs update -d -P -j branch-1_0_0_ cvs diff -u diffs.txt cvs -nq update files.txt diffs.txt will contain the changes that the merge thought were necessary. This may involve remerging changes and may cause spurious conflicts. OFten, the remerging just magically works, producing the same results as what's already on the mainline for already merged code, so the diffs for those will not show up. In theory, all the "missed" merging will show up in diffs.txt, but there will also be other junk in there that was already merged files.txt will contain a list of the files that the merge thought were in need of changes. This method is a long way from perfect, but it's a starting point.Hope it helps. -- steve __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
[Info-cvs] (no subject)
__ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
[Info-cvs] Re: Briefer version of cvs status - comments?
(sorry about prior empty message) James Youngman wrote: Before checking code in I like to check what changes I've made in order to ensure that I have in my mind all the comments that need to be made at "cvs commit". I also like to do this periodically to ensure that I haven't forgotten to commit change So, were you aware of "cvs -nq update" for this purpose? I think it does close enough to what you want already for most people, though your script's output looks a bit more compact. __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS versus MKS (or should I avoid moving to MKS?)
The biggest thing CVS has going for it over MKS SI is the (mostly) automatic merging of branches on a project- or module-wide basis using 3-way diffs. MKS merging is file-by-file, and is 2-way diff based manual process, (or was, last time I checked, which was a year ago or so). A couple other points in CVS favor: CVS is pretty portable, which can be important if you're doing development on some obscure or very new platform or OS. For example, I was able to run CVS on pre-beta versions of SCO Unixware 7 before SCO had even picked unixware 7 as the name. And now I am able to run it on IBM's AIX5L on Itanium. Also, MKS SI uses a locking scheme, like RCS, which, if you've gotten used to CVS, this can be an annoyance to have to constantly be locking things. __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/
Re: CVS help! on branches
On Thu, 07 Sep 2000, Benjamin Balagot wrote: Hello, I'm new to CVS and would like to find some answers. We have a BRANCH e.g. branch1 that was branched off the main line and another branch e.g. branch2 that I recently branched off the main line. How can I merge the 2 branches so that all additional files in branch1 will show up in branch2? Thanks! When you created your branches, did you create a regular non branch tag on the trunk first? Assuming yes, and that the tag marking the origin of branch1 is branch1origin, then: cvs rtag -r branch1 merged_to_branch2_01 everything cd someplace cvs co -r branch2 everything cvs tag prior_to_branch1_merge cvs update -d -P -j branch1origin -j merged_to_branch2_01 (resolve any conflicts) cvs commit The first "rtag" is so that if you have to merge branch1 into branch2 _again_, you won't have to remerge tha same changes in again, (doing that can be painful). The second tag is so that if the merge doesn't go well but you don't notice it until after the commit, you have a way to undo the merge. If you didn't tag the trunk prior to making your branches, you might be interested in a CVS patch I have made at http://www.geocities.com/dotslashstar/branch_patch.html -- steve __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/
Re: merging main trunk to branch?
Mike Castle wrote: So, for your situation, yuou have something like this: Branch point v 0+ Main | +--- Test Now, hopefully you labled the branch point with something when you created the branch. Otherwise, this is a pain. (Allow me to advertise my patch again) My patch will alleviate some of this pain, (though my patch may imply some changes that need to be made to wincvs or other cvs clients besides the command line cvs client, specifically in the area of allowing "cvs add" to work with the ".trunk" tag.) http://www.geocities.com/dotslashstar/branch_patch.html Then you could merge from trunk to branch "foo" like this, using the ".trunk" and "branchname.origin" pseudo tags that the patch implements. cvs rtag -r .trunk trunk_merge_point modulename cvs co -r foo modulename cd modulename cvs update -j foo.origin -j trunk_merge_point cvs commit cvs tag foo_post_trunk_merge -- steve __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/
Re: Bug: cvs up -r|-D -A (Was: getting old revision without a sticky tag)
Noel Yap wrote: Is there really a reason why "-A" doesn't work when the update command is also given "-D" or "-r"? Yes. (without my ".trunk" patch) this is how you update your working directory to the trunk, with "-A". "-A" means get rid of the sticky tags (and sticky options too). "-D" and "-r" both try to put in sticky tags. So which is it? Do you want to get rid of the sticky tags, or have sticky tags? A problem with "-A" is that it removes sticky options as well as sticky tags. With my ".trunk" patch it becomes possible to update your working directory to the trunk without losing sticky options, which, I don't think is possible with "-A". There probably needs to be a way to remove sticky tags without removing sticky options and vice versa. (Well, I think "cvs admin" covers the "vice versa" case) __ Do You Yahoo!? Get Yahoo! Mail Free email you can access from anywhere! http://mail.yahoo.com/
Re: cvs tag -F and branch tags, (was Re: Branches vs. keyword expansion)
--- Stephen Rasku [EMAIL PROTECTED] wrote: Date: Wed, 19 Jul 2000 22:46:42 -0700 (PDT) From: Stephen Cameron [EMAIL PROTECTED] [...] It seems to me that moving a branch tag is almost NEVER the right thing to do, while moving a non-branch tag is a (comparatively) normal operation... I quite often move branch tags. Usually, I only do this when there is no development on that branch for that file. This allows me to keep up with the current development without creating multiple branches. I just move the branch tag up to the tip revision, do "cvs update" and I am back to the latest and greatest. [...] And how is it that you move a branch tag? If you were to naively attempt it with something like this: cvs update -A somefile cvs tag -F branchtag somefile Well, guess what... You just converted "branchtag" from being a branch tag into being a regular tag. Not only that, but now you have NO idea what revision "branchtag" used to point to, and no way to find out, so you can't even undo it. So, to refine my suggestion, perhaps "cvs tag -F branchtag" should balk at converting a branchtag to a non-branch tag without some explicit instructions to do so. I suppose, if it's normal practice to move branchtags around, (seems odd to me) then "cvs tag -F -b branchtag file" should be tolerable. Perhaps the problem stems from "-F" meaning "Force", thus allowing all sorts of questionable things to be justified as part of "cvs tag -F" and overloading of "-F" to move a normal tag, which is a fairly common operation that seems like it should not require a mnemonically drastic-sounding option such as "-F". Just a few thoughts. --steve __ Do You Yahoo!? Get Yahoo! Mail Free email you can access from anywhere! http://mail.yahoo.com/
cvs tag -F and branch tags, (was Re: Branches vs. keyword expansion)
David Thornley wrote: (The biggest single problem I get is when people type cvs tag -F RELEASE_x_y rather than cvs tag -F RELEASE_x_y_MERGED where the first is the branch tag It seems to me that moving a branch tag is almost NEVER the right thing to do, while moving a non-branch tag is a (comparatively) normal operation... Would it make some kind of sense to make "cvs tag -F" refuse to move a branch tag and require something special to be typed in to indicate to CVS that you KNOW that you're moving a branch tag? (or should the capability be removed altogether, or require the use of "cvs admin" or require direct editing of RCS files?) The consequences of accidentally moving a branch tag can easily be really bad, especially if it isn't noticed for awhile. BTW, be careful when doing merges using -kk, as, if I recall correctly, this can suppress -kb and cause unintentional corruption of binaries. (Well, I saw this happen to a user here once, but, maybe he did something wrong I wasn't aware of. Generally I avoid keyword conflicts by avoiding keywords altogether, so I'm not all that familiar with all the hazards in this area, other than having stumbled into them once or twice.) -- steve __ Do You Yahoo!? Get Yahoo! Mail Free email you can access from anywhere! http://mail.yahoo.com/
.trunk + .origin patch refinement July 9, 2000
Update of my ".trunk" + ".origin" patch: I fixed a bug with "cvs commit -r .trunk" plus ChangeLog entry, and some changes to sanity.sh test cases and docs and misc. other changes. July 9 2000 version of this patch can be found here: http://www.geocities.com/dotslashstar/branch_patch.html (GPL'ed of course) applies to the development version of CVS, 7/9/2000. make check and make remotecheck pass on Linux for me. -- steve __ Do You Yahoo!? Get Yahoo! Mail Free email you can access from anywhere! http://mail.yahoo.com/
cvs.cyclic.com:/home2/cvs modules file corrupt?
Is the cvs.cyclic.com:/home2/cvs modules file corrupted? I try: [scameron@zuul cvs.ctd]$ echo $CVSROOT :pserver:[EMAIL PROTECTED]:/home2/cvsroot [scameron@zuul cvs.ctd]$ export CVSROOT [scameron@zuul cvs.ctd]$ cvs -z3 co -c ccvs @ÐàÈ [scameron@zuu[scameron@zuul cvs.ctd]$ And I try: [scameron@zuul cvs.ctd]$ cvs -z3 co -l ccvs cvs [server aborted]: there is no repository /home2/cvsroot/@ðv30555 Huh? I tried this with a 1.10.8 client on Linux and also the current development version (well last night's anyway, 7/6/2000, obviously I can't get today's version) to rule out my hacked up version of CVS. BTW, is there a way to see what version of CVS is running on the remote end? If not, should there be? -- steve __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/
Re: .trunk patch 06-28-2000
I wrote: I just tried my 6-28-2000 ".trunk" patch against 1.10.8 on SCO unixware 7. It failed log-14. Ah. Now that I'm home, I sse the problem. The diffs between the 1.10.8 and the development version are too great for my patch to work with 1.10.8. __ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/
sanity.sh.howto
Somebody on this list asked awhile ago about how to write sanity.sh test cases, (now I can't seem to find the message though.) It occurred to me that I know a thing or two about that, and it also occurred to me that it was hard-won knowledge. So I took a few minutes to write some of it down. If this (or something like it) would be a useful addition to the CVS distribution, feel free to include it under the GPL. For what it's worth -- steve __ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ sanity.sh.howto
.trunk patch update 6-27-2000
Here's the latest update to my ".trunk" patch.
(Several people seem to prefer ".main" or various
other strings to ".trunk", which is ok by me...,
that's only a #define)
Anyway, this one makes "cvs admin -l.trunk foo" and
"cvs admin -u.trunk foo" work.
It also includes sanity.sh tests for other "cvs admin" options
and ".trunk". Though I'm no expert with "cvs admin", I rarely use it, as I
expect is the case with most people.
I also think I found one of the "corner cases" Greg Woods has vaguely
referred to around the area of "cvs commit -r" updating trunk
revisions: "cvs log -r.trunk" (or "cvs log -b"
for that matter) doesn't seem to work quite right if the trunk
contains foo version 1.1 and foo version 2.1. Only version 2.1
will show up by "cvs log -b" or "cvs log -r.trunk" For the latter,
it is certainly a bug, for "cvs log -b" I'm not sure, maybe it
was made that way on purpose. This also gave me insight into
finding other such corner cases, places where strrchr() is used,
looking for a dot (".") are prime stomping grounds for such
corner cases. Not that I've started looking too hard for them
yet.
Attached is the latest ".trunk" patch against the current (6/27/2000)
development version of CVS. It passes "make check" and "make
remotecheck" for me on linux.
(ftp.geociites.com was acting weird this morning, so I couldn't
put it on the web)
I grant permission to distribute this patch under
the terms of the GNU Public License
-- steve
__
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
Index: NEWS
===
RCS file: /home2/cvsroot/ccvs/NEWS,v
retrieving revision 1.79
diff -c -r1.79 NEWS
*** NEWS2000/05/05 14:48:37 1.79
--- NEWS2000/06/27 05:26:00
***
*** 1,5
--- 1,8
Changes since 1.10:
+ * New ".trunk" pseudo-branch-tag added which acts just like a branch
+ tag, but means the trunk.
+
* The "cvs history" command output format has changed -- the date
now includes the year and is given is ISO 8601 format (-mm-dd).
Index: doc/ChangeLog
===
RCS file: /home2/cvsroot/ccvs/doc/ChangeLog,v
retrieving revision 1.622
diff -c -r1.622 ChangeLog
*** ChangeLog 2000/06/14 17:41:56 1.622
--- ChangeLog 2000/06/27 05:26:23
***
*** 1,3
--- 1,7
+ 2000-06-18 Stephen Cameron [EMAIL PROTECTED]
+
+ * cvs.texinfo: Document new ".trunk" pseudo branch tag.
+
2000-04-03 Pavel Roskin [EMAIL PROTECTED]
* cvs.texinfo (Telling CVS to notify you): Remove backslashes
Index: doc/cvs.texinfo
===
RCS file: /home2/cvsroot/ccvs/doc/cvs.texinfo,v
retrieving revision 1.489
diff -c -r1.489 cvs.texinfo
*** cvs.texinfo 2000/06/14 17:41:56 1.489
--- cvs.texinfo 2000/06/27 05:27:55
***
*** 3258,3264
as internal numbers that @sc{cvs} maintains, and tags
provide a better way to distinguish between things like
release 1 versus release 2 of your product
! (@pxref{Tags}). However, if you want to set the
numeric revisions, the @samp{-r} option to @code{cvs
commit} can do that. The @samp{-r} option implies the
@samp{-f} option, in the sense that it causes the
--- 3258,3273
as internal numbers that @sc{cvs} maintains, and tags
provide a better way to distinguish between things like
release 1 versus release 2 of your product
! (@pxref{Tags}).
!
! In fact, let's just go ahead and say right now that you are
! STRONGLY advised against using @samp{cvs commit -r}
! to manually set revision numbers. It is STRONGLY recommended that
! you just allow CVS to assign revision numbers however it likes.
! You should use tags instead of trying to assign some meaning to
! revision numbers.
!
! However, if, with that caution in mind, you still want to set the
numeric revisions, the @samp{-r} option to @code{cvs
commit} can do that. The @samp{-r} option implies the
@samp{-f} option, in the sense that it causes the
***
*** 3313,3331
@cindex Name, symbolic (tag)
@cindex HEAD, as reserved tag name
@cindex BASE, as reserved tag name
You can use the @code{tag} command to give a symbolic name to a
certain revision of a file. You can use the @samp{-v} flag to the
@code{status} command to see all tags that a file has, and
which revision numbers they represent. Tag names must
start with an uppercase or lowercase letter and can
contain uppercase and lowercase letters, digits,
! @samp{-}, and @samp{_}. The two tag names @code{BASE}
! and @code{HEAD} are reserved fo
RE: .trunk patch refinement
John P. Cavanaugh wrote, regarding his preference for "main" or "trunk"
over ".trunk":
Partly for personal preference of liking main or trunk better than .trunk.
But it also allows for main.latest (which I will admit is only to facilitate
similarity with other branches)
So, it's partly for the sake of consistency. Well, ".trunk" is perfectly
consistent too. It's a branch tag name for the trunk. If you want the
latest stuff from a branch, you use the branch tag name. If you want the
latest stuff from the trunk, you use the branch tag name: ".trunk"
(my words, and here I confuse BASE, and ".base" which are completely
different).
branchname.base - For the version where the branch sprouted
I haven't thought about BASE, or what it means, at all, not one whit, so I
haven't yet formed an opinion.
Its nice to be able to easily figure out where your branch sprouted from
using an abstract mechanism.
Yes it is, actually it's more than nice, it's essential, which is
why everybody manually tags this point before creating a branch,
except for newbies, who learn the hard way.
So I've thought about it a bit more and written some rough code
(below). (I didn't put the code in patch form because it's not
quite cooked yet and it would be a bit irresponsible to put it
out there in such easily edible form.)
These changes were made to rcs.c, and TAG_ORIGIN was #defined to
".origin", (to avoid confusion with BASE, I didn't use ".base"
but of course we can #define TAG_ORIGIN to be whatever everybody
likes)
Anyway it seemed to work with "update", "checkout", "diff" and
"rdiff", but then I tried sanity.sh, and it failed "make remotecheck"
(I forget which test, something to do with removing a branch tag.)
I'm not sure why, I would have though my code would only fire if you
used a tag of the form xxx.origin, but that's where things stand now.
Anyway, one thing I haven't figured out is what to do for the case
of the trunk, e.g. ".trunk.origin", (and/or maybe just ".origin" by
itself) The super easy but surely wrong implementation is just
return "1.1" in that case maybe? I'm not sure how to implement it
correctly though. Also, what should be done about the
"force_tag_match" case? I'm not sure that even makes sense
with ".origin", so just ignore it?
Anyway, here's a snippet of the code that I'm working on:
-- steve
/*
* Find the revision for a specific tag.
* If force_tag_match is set, return NULL if an exact match is not
* possible otherwise return RCS_head (). We are careful to look for
* and handle "magic" revisions specially.
*
* If the matched tag is a branch tag, find the head of the branch.
*
* Returns pointer to newly malloc'd string, or NULL.
*/
char *
RCS_gettag (rcs, symtag, force_tag_match, simple_tag)
RCSNode *rcs;
char *symtag;
int force_tag_match;
int *simple_tag;
{
char *tag = symtag;
int tag_allocated = 0;
if (simple_tag != NULL)
*simple_tag = 0;
/* make sure we have something to look at... */
assert (rcs != NULL);
/* XXX this is probably not necessary, --jtc */
if (rcs-flags PARTIAL)
RCS_reparsercsfile (rcs, (FILE **) NULL, (struct rcsbuffer *) NULL);
/* If tag is "HEAD", special case to get head RCS revision */
if (tag (STREQ (tag, TAG_HEAD) || *tag == '\0'))
#if 0 /* This #if 0 is only in the Cygnus code. Why? Death support? */
if (force_tag_match (rcs-flags VALID) (rcs-flags INATTIC))
return ((char *) NULL); /* head request for removed file */
else
#endif
return (RCS_head (rcs));
/* If tag is "TRUNK", special case to get trunk RCS revision */
if (tag (STREQ (tag, TAG_TRUNK) ))
return (RCS_trunk (rcs));
if (!isdigit ((unsigned char) tag[0]))
{
char *version;
/* add this for ".origin" */
/* if asking for the ".origin" of a branch tag, then find it */
if ( strlen(tag) strlen(TAG_ORIGIN)
strcmp(tag+strlen(tag)-strlen(TAG_ORIGIN), TAG_ORIGIN) == 0)
{
char *branchtag;
branchtag = xstrdup(tag);
strncpy(branchtag, tag, strlen(tag) - strlen(TAG_ORIGIN));
/* cut off the ".origin" */
branchtag = xstrdup(tag);
branchtag[ strlen(branchtag) - strlen(TAG_TRUNK)-1] = '\0';
version = RCS_getbranchoriginrev(rcs, branchtag);
free(branchtag);
return(version);
}
[..]
/*
* Get the origin of the specified branch.
* If the branch does not exist,
* return NULL
*
* Note, force_tag_match is IGNORED. I'm not sure what it should do,
* return "1.1", or the lowest numbered version? Seems questionable.
*
* What about ".trunk"?
*
* A lot of this code was copied mercilessly from RCS_getdatebranch
*
*/
char *
RCS_getbranchoriginrev (rcs, branch)
RCSNode *rcs;
char *branch;
{
char * version;
char *cur_rev =
6-20-2000 .trunk patch refinement
I have a new version of my ".trunk" patch (I sent it to bug-cvs already but I didn't want to pollute everyone's mailbox with a big patchfile twice, so I'm only sending this URL to info-cvs... Includes a new test case in sanity.sh for a revision "2.1" Changes to docs, comments...minor stuff. The patch applies to the development version of CVS. (and to 1.10.8, with a minor, easily resolved reject in log.c) (I did have some trouble with Larry's 6-19-2000 check-in to server.c, main.c, root.c though, so I ran the tests with those changes backed out.) http://www.geocities.com/dotslashstar/branch_patch.html -- steve __ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/
.trunk patch, usage of -r1 random data point
Just out of curiosity, I used my hacked version of cvs to do this on my biggest repository: cvs rdiff -s -r1 -r.trunk topmodule diffs.txt There were 459 (out of 6658) files that had a revision number that didn't start with "1", and quite a few that I was surprised to see. (that is, quit a few relatively new files, in addition to the old ones. grumble grumble... silly users. :-) Just a random data point. -- steve __ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/
Re: .trunk patch refinement
Well, I see one problem with my patch already: --- Stephen Cameron [EMAIL PROTECTED] wrote: This part, from cvs.texinfo: + + CAUTION: the special tag `HEAD' is interpreted by + the `cvs diff' command in a different way than it + is interpreted by any other cvs command. `cvs diff' + takes `-r HEAD' to mean the following, as nearly as + I can tell: + + For `cvs diff', `HEAD' means the most recent revision + on the `current branch' (taking into account whatever + sticky tags are active in your working directory) unless + the particular file being diffed is not present on the + branch, in which case the head revision of the trunk is + taken. It is evident that there are at least some cases + for which this definition fails, that is, the wrong + revision may be found by `cvs diff' when used in combination + with `-r HEAD'. You may wish to use `.trunk' rather than + `HEAD'. The `.trunk' tag acts as a branch tag name for the + trunk. + is not correct nor consistent with this part: /* ! * Special tags. ! * -rHEAD refers to the tip revision on the trunk, _except_ for ! * "cvs diff". "cvs diff" interprets -rHEAD to mean the tip ! * revision of the current branch, however, that behavior is ! * broken, because if the file has not been branched, that is, ! * the revision on the branch is the same one that's on the trunk ! * then the tip revision of the trunk is reported. Also, it's ! * not clear (to me) what happens in the instance of a sticky ! * non-branch tag what -rHEAD is supposed to mean. So, -rHEAD ! * is probably a lost cause, unless you redefine what it means. ! * from cvs.h, which I think is more correct... So I need to fix that. -- steve __ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/
.trunk patch refinement
Ok, here's a refinement of my ".trunk' patch that gives the trunk a branch-tag name, just like other branches (from the user's perspective, the implementation is rather different.) You can also find this here: http://www.geocities.com/dotslashstar/branch_patch.html From HACKING: * Writing patches (strategy) [...] For features, the desirable attributes are that the need is clear and that they fit nicely into the architecture of CVS. Is it worth the cost (in terms of complexity or any other tradeoffs involved)? Are there better solutions? I'm not sure I know the answers to the above..., but you can have a look at my code and ponder it. If the design is not yet clear (which is true of most features), then the design is likely to benefit from more work and community input. Yes please, input could be nice. Make a list of issues, or write documentation including rationales for how one would use the feature. Discuss it with coworkers, a newsgroup, or a mailing list, and see what other people think. This has been discussed several times in the past...with no real outcome. Distribute some experimental patches and see what people think. The intention is arrive at some kind of rough community consensus before changing the "official" CVS. Features like zlib, encryption, and the RCS library have benefitted from this process in the past. So far: ...silence... (the sound of crickets chirping maybe) If longstanding CVS behavior, that people may be relying on, is clearly deficient, it can be changed, but only slowly and carefully. For example, the global -q option was introduced in CVS 1.3 but the command -q options, which the global -q replaced, were not removed until CVS 1.6. I have carefully refrained from disturbing the longstanding (but disturbing) behavior of the "HEAD" pseudo tag. * Writing patches (tactics) When you first distribute a patch it may be suitable to just put forth a rough patch, or even just an idea. But before the end of the process the following should exist: Check! - ChangeLog entry (see the GNU coding standards for details). Check! - Changes to the NEWS file and cvs.texinfo, if the change is a user-visible change worth mentioning. Check! - Somewhere, a description of what the patch fixes (often in comments in the code, or maybe the ChangeLog or documentation). Check! - Most of the time, a test case (see TESTS). It can be quite frustrating to fix a bug only to see it reappear later, and adding the case to the testsuite, where feasible, solves this and other problems. Check! Include words like "I grant permission to distribute this patch under the terms of the GNU Public License" with your patch. By sending a patch to [EMAIL PROTECTED], you implicitly grant this permission. Check! "I hereby grant permission to distribute this patch under the terms of the GNU Public License" -- Steve Cameron So, of course my expectations are not that this will be checked in, but maybe someone will point me to what I need to fix to move things in that direction, or tell me not to bother. Thanks, -- steve The patch is attached. Or you can get it here too: http://www.geocities.com/dotslashstar/branch_patch.html __ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/ Index: NEWS === RCS file: /home2/cvsroot/ccvs/NEWS,v retrieving revision 1.79 diff -c -r1.79 NEWS *** NEWS2000/05/05 14:48:37 1.79 --- NEWS2000/06/18 04:19:30 *** *** 1,5 --- 1,8 Changes since 1.10: + * New ".trunk" pseudo-branch-tag added which acts just like a branch + tag, but means the trunk. + * The "cvs history" command output format has changed -- the date now includes the year and is given is ISO 8601 format (-mm-dd). Index: doc/ChangeLog === RCS file: /home2/cvsroot/ccvs/doc/ChangeLog,v retrieving revision 1.622 diff -c -r1.622 ChangeLog *** ChangeLog 2000/06/14 17:41:56 1.622 --- ChangeLog 2000/06/18 04:19:47 *** *** 1,3 --- 1,7 + 2000-06-18 Stephen Cameron [EMAIL PROTECTED] + + * cvs.texinfo: Document new ".trunk" pseudo branch tag. + 2000-04-03 Pavel Roskin [EMAIL PROTECTED] * cvs.texinfo (Telling CVS to notify you): Remove backslashes Index: doc/cvs.texinfo === RCS file: /home2/cvsroot/ccvs/doc/cvs.texinfo,v retrieving rev
A branch-tag name for the trunk! maybe. (was RE: diff bug when using HEAD)
[EMAIL PROTECTED] (that's me) wrote: [smc] "TRUNK" sounds useful, "HEAD" as described here, less so, since the branch tag may currently be used for that purpose, (though it might be useful for scripts or something that don't want to have to know what the branch tag is, or in the case of some kind of hybrid sandbox with modules from multiple branches (or even multiple repositorires?)) But, does anyone here know how to implement either HEAD or TRUNK as described here? ,, I don't know how. Well, perhaps someone does... Heck, perhaps *I* do, after all. I've implemented *something* anyway, a ".trunk" tag that acts very very much like a branch tag for the trunk. You can "cvs diff", "cvs add", "cvs remove", "cvs update", "cvs checkout", "cvs commit" using this tag. Also it doesn't break the current behavior of "no tag means the trunk". "cvs update -A" will get rid of the sticky ".trunk pseudo branch tag" too, and "cvs update -r .trunk" will bring it back... Anyway, you can check out my attempt at a patch here, if you have the inclination. http://www.geocities.com/dotslashstar/branch_patch.html The patch is against the current (6/8/2000) development version of CVS. The patch leaves the current (broken) behavior of HEAD as is, ".trunk" does what HEAD should have done, I think. (There aren't any sanity.sh tests yet... and I haven't tried it in client server mode yet, and don't try this on a real repository yet, etc. etc. I think it works, but I wouldn't want to ruin anybody's day with what could easily be shoddy code, you know? Consider yourself warned. There's some stuff there in commit.c that I wasn't really too sure about..., but it seemed to work on the things that I tried... -- steve __ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com
duplicate key...message
I'm getting some weird results from 'cvs rdiff' scameron@zuul 1097 $ cvs rdiff -s -r 0.0 -r efs_x36_dev_br abd cvs server: duplicate key found for `y' cvs server: Diffing efs/unix/autobuild/abd File efs/unix/autobuild/abd/Changelog.x30 is new; current revision 1.2 What's the "dupilicate key found for 'y'" message? I'm guessing it's from ndbm, while looking in the modules file. But, I can edit the modules file, and commit a change to the modules file, and I get the message about rebuilding the modules database, but nothing about any duplicate key, and I don't have a module called "y" so I'm not sure what the 'y' key is, or why there's more than one. So what does that mean? Is it a bug. (looks like one to me) Is my modules ndbm file(s) corrupt? Can I rebuild the ndbm files...hmmm, where are the ndbm files? I'm expecting some files named modules.pag and modules.dir, or something like that...(all my ndbm experience comes from Sun's yellow pages, er, NIS I mean). This is with cvs 1.10.7 on both client and server. Thanks for any help. -- steve __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/
