Re: check_cvs.pl script
Attached. Documentation inside the script. donald On Thu, Nov 21, 2002 at 08:29:18AM +0200, Reinstein, Shlomo wrote: > Hi, > I found the check_cvs.pl script in some of the messages in the mailing-list. > Is this script published formally somewhere, or is that a private script > that was provided only for the cases in those messages? > Shlomo > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs check_cvs.pl Description: Perl program
RE: check_cvs.pl script
Thanks, Donald, but I didn't mean to get an updated private version. I really meant to ask if this script is going to be published (e.g., in the contrib/ directory) and regularly updated. One thing I'd add to the script is read the checkoutlist file and avoid reporting the files specified there as "files that do not belong in the repository". Shlomo -Original Message- From: Donald Sharp [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 2:57 PM To: Reinstein, Shlomo Cc: [EMAIL PROTECTED] Subject: Re: check_cvs.pl script Attached. Documentation inside the script. donald On Thu, Nov 21, 2002 at 08:29:18AM +0200, Reinstein, Shlomo wrote: > Hi, > I found the check_cvs.pl script in some of the messages in the mailing-list. > Is this script published formally somewhere, or is that a private script > that was provided only for the cases in those messages? > Shlomo > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: check_cvs.pl script
Go ahead and make the changes( if you want to ). I'll put them into the copy I have. Publishing it into cvs is fine if someone with write permission to the repository wants to do such a thing. donald On Thu, Nov 21, 2002 at 03:10:49PM +0200, Reinstein, Shlomo wrote: > Thanks, Donald, but I didn't mean to get an updated private version. I > really meant to ask if this script is going to be published (e.g., in the > contrib/ directory) and regularly updated. > One thing I'd add to the script is read the checkoutlist file and avoid > reporting the files specified there as "files that do not belong in the > repository". > > Shlomo > > -Original Message- > From: Donald Sharp [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 21, 2002 2:57 PM > To: Reinstein, Shlomo > Cc: [EMAIL PROTECTED] > Subject: Re: check_cvs.pl script > > > Attached. Documentation inside the script. > > donald > On Thu, Nov 21, 2002 at 08:29:18AM +0200, Reinstein, Shlomo wrote: > > Hi, > > I found the check_cvs.pl script in some of the messages in the > mailing-list. > > Is this script published formally somewhere, or is that a private script > > that was provided only for the cases in those messages? > > Shlomo > > > > > > ___ > > Info-cvs mailing list > > [EMAIL PROTECTED] > > http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: check_cvs.pl script
Donald Sharp writes: > > Publishing it into cvs is fine if someone > with write permission to the repository wants to do such a thing. We can't do that given the current copyright notice; we need permission to distribute it (preferably under the GPL). -Larry Jones All girls should be shipped to Pluto--that's what I say. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Problem with partially lost branch information
Hi all, I have a problem with my CVS repository that I don't understand: I have a branch called "forv_ver1_020311-branch" in a module named "itp" which has been in use for quite a while (as you can tell from the name). I have created a local sandbox of this branch with the following: cvs co -r forv_ver1_020311-branch itp Now, the odd thing is that the content of itp/CVS/Tag is "Nforv_ver1_020311-branch", where I would have assumed a leading "T" instead of the "N". Furthermore are there five directories in this module: build, docs, external, install and main. The contents of these: $ for i in build docs external install main > do cat $i/CVS/Tag; done Nforv_ver1_020311-branch Nforv_ver1_020311-branch Tforv_ver1_020311-branch Tforv_ver1_020311-branch Tforv_ver1_020311-branch As you can see is the branch treated as a tag in two of these, whereas it is a branch in the rest. This has the upshot that it is impossible to add files to the first two directories in this branch, but quite allright in the other three. Anyone seen this before? What is going on? How can I fix this? Sincerely yours Karl-Koenig Koenigsson -- PITLOCHRY (n.) The background gurgling noise heard in Wimby Bars caused by people trying to get the last bubbles out of their milkshakes by slurping loudly through their straws. (The Meaning of Liff, Douglas Adams) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problem with partially lost branch information
I would suggest that the forv_ver1_02X branch tag doesn't exist in the first two directories. Since it looks like you know the date when the tag was applied you can pull a workspace with the cvs co -D command for those two directories and then apply the branch tag. Then you should be able to update the original workspace... donald On Thu, Nov 21, 2002 at 06:16:08PM +0100, Karl-Knig Knigsson wrote: > Hi all, > > I have a problem with my CVS repository that I don't understand: I have > a branch called "forv_ver1_020311-branch" in a module named "itp" which > has been in use for quite a while (as you can tell from the name). > > I have created a local sandbox of this branch with the following: > > cvs co -r forv_ver1_020311-branch itp > > Now, the odd thing is that the content of itp/CVS/Tag is > "Nforv_ver1_020311-branch", where I would have assumed a leading "T" > instead of the "N". > > Furthermore are there five directories in this module: build, docs, > external, install and main. The contents of these: > > $ for i in build docs external install main > > do cat $i/CVS/Tag; done > Nforv_ver1_020311-branch > Nforv_ver1_020311-branch > Tforv_ver1_020311-branch > Tforv_ver1_020311-branch > Tforv_ver1_020311-branch > > As you can see is the branch treated as a tag in two of these, whereas > it is a branch in the rest. This has the upshot that it is impossible to > add files to the first two directories in this branch, but quite > allright in the other three. > > Anyone seen this before? What is going on? How can I fix this? > > Sincerely yours > > Karl-Koenig Koenigsson > > -- > PITLOCHRY (n.) > The background gurgling noise heard in Wimby Bars caused by people > trying to get the last bubbles out of their milkshakes by slurping > loudly through their straws. > (The Meaning of Liff, Douglas Adams) > > > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problem with partially lost branch information
Donald Sharp wrote: I would suggest that the forv_ver1_02X branch tag doesn't exist in the first two directories. Since it looks like you know the date when the tag was applied you can pull a workspace with the cvs co -D command for those two directories and then apply the branch tag. Both directories exists in the branch and there have been changes made in both. "Build" contains a directory "tools" which has the same error, i.e. its CVS/Tag file contains a "N" and not a "T". "tools" in its turn contains four directories: "cmd", "lib", "src" and "wise"; two are OK and two are weird. All files in these directories have the correct sticky tag; there seems not to be a problem with the files, just the structure. If I manually correct the erronous "N" entries and replace them with a "T" things work just fine. Adding, committing, you name it. The problem with this solution is that it only fixes the symptoms; once I check out a new sandbox I'm back again with the missing branch tags on some directories. Furthermore: this has worked in the past. I don't know what has changed but for those developers who has an old sandbox of this branch everything is hunk-dory. This error only appears if you check out the branch today (or rather if you did in the last week). I suppose I will have to go through the backups, but I'd rather not. What I really like to know is 1) why this has happend, 2) how I can fix it, and 3) how I can prevent it from happening in the future. Karl-König Königsson -- VOBSTER (n.) A strain of perfectly healthy rodent which develops cancer the moment it enter a laboratory. (The Meaning of Liff, Douglas Adams) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problem with partially lost branch information
=?ISO-8859-1?Q?Karl-K=F6nig_K=F6nigsson?= writes: > > As you can see is the branch treated as a tag in two of these, whereas > it is a branch in the rest. This has the upshot that it is impossible to > add files to the first two directories in this branch, but quite > allright in the other three. > > Anyone seen this before? What is going on? How can I fix this? Most likely, there is at least one file in each of those directories where that tag is a revision tag rather than a branch tag. -Larry Jones Any game without push-ups, hits, burns or noogies is a sissy game. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
checksum failure after patch won't refetch?!
Hi, I have this messages on my screen after doing "cvs update -dA": cvs update: checksum failure after patch to ./myfile.txt; will refetch But the refetch does not happen. However, if I change dir to where that file is (lower in the directory hierarchy), I get this message instead: cvs server: Updating . P myfile.txt cvs update: checksum failure after patch to ./myfile.txt; will refetch cvs client: refetching unpatchable files U myfile.txt I am running the pserver on a Solaris machine, and the client is on a Linux machine. The CVS versiom is 1.11.2. Do you know why it does not refetch the first time? --- Thanks, Martin d'Anjou ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Rtag ?
I have been asked to tag (and branch) a module. The Problem is that there are no current tags for that build they want to branch on. Can I, using Rtag -D , specifiy a date/time of the build and tag all the files that were current on that date/time then create a branch? HELP! Matt Rich __ 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
checkout.c uses strdup()
Greetings, I notice that checkout.c, below the comment "/* strip the last_component */" still uses strdup() instead of xstrdup(). Is this an accedent? FWIW, OS/400 documents strdup() as an XPG4 extension. Speaking of compiler warnings ... Does anybody still build cvs with a compiler which does not accept function prototypes? Thank you for your attention. Terry [Aside to moderator: I tried to send this earlier from [EMAIL PROTECTED] Please discard that message.] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
How to merge two repositories with out loss of log & tags ?
Hello, We have two repositories which need to be merged in to a single database. But i would like to retain the logs, tags and other info contained by both database. Is this possible ? Any help is welcome. I have tried to explain the problem in brief here. We have database CVS/project1 which contain may sub dir's which has been used by many people for about two years and is having version no's running into 1.100 + and has been tagged with about 50 + tags for various bug fixes & releases. We have CVS/project2 which is relatively new , has many sub dir's, has been used for about a year, is having about 10 tags, and revisions of various files running in to 1.20 +. now our problem is to merge these two projects 1 & 2 in to project. CVS/project which is a super set of project1 & project2. is it possible to create CVS/project with out loss of the two years of log & old tags. Thanks in advance, Srinivas. PS: I had sent the same mail from my new mail id ( non member id by mistake), in case that message gets posted please ignore it. sorry for the inconvenience caused. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to merge two repositories with out loss of log & tags ?
Srinivas P Shenoy wrote: >We have two repositories which need to be merged in to a single >database. >But i would like to retain the logs, tags and other info contained by >both database. >Is this possible ? >Any help is welcome. >I have tried to explain the problem in brief here. >is it possible to create CVS/project with out loss of the two years of >log & old tags. Hi, what you can do is create new repository. Then tar the modules(in old repos) to separate tar files and the untar them in the new repository. This is actually physically moving modules from one repo to another. As version info will be maintained by the RCS files themselves, this should work. Thus your new repo will have all modules which were there in the other older repos. Cheers. Mahantesh. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rtag ?
On Fri, 2002-11-22 at 09:25, Matthew Rich wrote: > I have been asked to tag (and branch) a module. The > Problem is that there are no current tags for that > build they want to branch on. > Can I, using Rtag -D , specifiy a date/time of the > build and tag all the files that were current on that > date/time then create a branch? Yes. Try this: cvs rtag -D (date) base_(branchname) (module) cvs rtag -r base_(branchname) -b (branchname) (module) The first one creates a base tag for the branch (and when the time comes to merge, you'll bless its existance!). The second one creates the branch. Remember all the caveats about dates, like specifying timezone and the fact that without a time it's based on midnight-that-starts-the-day. Jenn V. -- "Do you ever wonder if there's a whole section of geek culture you miss out on by being a geek?" - Dancer. [EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
