(no subject)
Hi, I want to use java api's over cvs code. want ot connect to cvs thru my java application in a windows environment. Some sample code if possible. Can somebody help me with the same ? pradeep ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Preventing users from Tagging files
Thanks. Everyone has been very helpful.
You hit the nail on the head.
Adding tags is quite safe, it is the removal of a tag that messes up our repository
structure. We do back things up nightly, but its a huge waste of time recovering from
the backups when a tagging mistake occurs.
I've tried out a modified version of the script on my test cvs server and it works
great. I'll move it on over to production next week.
Thanks for the help.
--Mike
--- On Tue 11/25, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Tue, 25 Nov 2003 17:41:47 -0800 (PST)
Subject: Re: Preventing users from Tagging files
On Tue, 25 Nov 2003, Kaz Kylheku wrote:brbr On Tue, 25 Nov 2003, Mike wrote:br
br I am aware that I can use the unix file system permissions to preventbr
developers from checking in files into CVS. But is there a way to preventbr br
In addition, you can use the commitinfo scripting mechanism to stop commitsbr for
just about any criteria: bad code formatting, missing bug numberbr in the log
message, etc.br br people from TAGGING files [or retagging] while still
letting them checkinbr those same files? Or am I just asking a stupid
question?br br You can implement your custom restrictions in a script specified
in br the taginfo administrative file. The taginfo script could check thebr
user identity and reject the operation if that identity is blacklisted.br br
(But really, if you can't trust some developers to tag properly, howbr can you
trust them to commit anything? Learning a tagging system andbr sticking to it is
far less complex than all the things you have to dobr to become a competent
software developer. :)brbrbrTagging is not really the issue, it is deleting tags
that is. And once youbrhave deleted a tag, it is gone. I have always thought this
was a weaknessbrof CVS. History of all commits are retained, even deleting a file
from thebrrepository really does not delete the ,v file, the file is just moved
intobrthe attic. But when you delete a tag, there is no history you can
revertbrfrom, besides your last repository backup. Even competent developersbrcan
accidentally delete something they did not mean to. Everyonebrcan be confused from
time to time. This is a strong argument for havingbrgood and frequent backups of
the CVS repository, in lieu of somebrother home grown tag backup
mechanism.brbrAt work, we prevent everyone from deleting tags, except one user,
brcvsadmin. This way, if there is a tag delete snafu, we know who didbrit. There
is our implementation; YMMV. You could easily make this bra more generic
implementation, and lookup the username from a file ofbrauthorized
users.brbrtaginfo entry:brALL $CVSROOT/CVSROOT/tag.sh
${USER}brbrbrtag.sh:br#!/bin/shbr# Everyone can addbr$brif [ $3 =
add ]; thenbrexit 0brfibrbr# cvsadmin can do
everythingbr#bruser=`whoami`brif [ $user = cvsadmin ]; thenbrexit
0brfibrbr# Nothing else is allowed.br#brecho $@ $4/tag.logbrexit
2brbrbrAdambrbrAdam Bernstein [EMAIL PROTECTED]
http://mpgedit.org/~number6brbrbrbrbr___brInfo-cvs
mailing listbr[EMAIL PROTECTED]brhttp://mail.gnu.org/mailman/listinfo/info-cvsbr
___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Loading files into CVS with a declared date
Please take a look at the sccs2rcs.csh script (You can browse to this source at http://ccvs.cvshome.org/source/browse/ccvs/contrib/sccs2rcs.in ) which converts SCCS files to RCS files. After the procedure you move the RCS files into the CVS repository directly. While your tools are not SCCS, this script will show you how to use the RCS ci tool to create entries with the correct timestamp as well as create binary RCS files. CVS uses the RCS file format, so there is no compatibility problem. -Allan -Original Message- From: Kevin Oberman [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 25, 2003 6:03 PM To: [EMAIL PROTECTED] Subject: Loading files into CVS with a declared date I hope this is not a FAQ. I have the job of transitioning a large archive from an in-house system to CVS. I have all of the tools to do the maintenance of the repository, but I need to load all of the historical data into my repository. I have the time-stamps when these files were entered into my archive and the change-log information. Is there any way to force a commit to put a timestamp on a commit? Any hacks to cvs to allow this? I guess what I want to do is: cvs commit -D 1997-10-23 20:45 file, but there is no such command. Any ideas? Thanks, -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ 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: cvs rlog -rTAG1::TAG2 doesn't handle newly added files
Matthew Herrmann writes: I'm having problems with cvs rlog and -rTAG1::TAG2 not outputting changes for newly created tags. Update your server to the most recent release (1.11.9). -Larry Jones Do you think God lets you plea bargain? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Please help..
Hi All, I am seriously new to CVS. I have a large project that has been developed by my self for the past 18 months but is about to be taken on by a few other people so I though CVS would be a good way of working. I seem to have turned all of my original source files within the directory to have a .v extention and a lot of stuff has been added to these files. Please tell me their is an easy way to get my files back! I seem to have figurered out now how to make a repository from my original source files but they all have a double .v (.v.v) file extention now!!! Doh. Thanks in advance!! Cheers John ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Exporting with 1 tag name
Can anyone help me think around this one? We are finally getting around to making releases from CVS. We have a product that is split up into a number of seperate modules. Ideally we would like to be able to release the whole project, or just a module. I intend to follow the simplest solution here - I'm going to tag all the files with a release tag and then do an export. If I'm releasing the whole product I'll put the name of the product as part of the tag; if I'm releasing a single module then I'll put the name of the module as part of the tag. And, of course, if a file is part of a product- and a module- level release, it gets two tags. No problem. However, I'm a little concerned that if a customer gets a product level release followed by a module level release then the ident string for the module code will not have any relation to the ident string for the rest of the product. The customer will see rel_tapestry_2_3 (product) and rel_ta_4_1 (module) and not know which came first. The best solution I can conjure up is that a module release is always predicated on a product release. So instead of rel_ta_4_1 (s)he would get rel_tapestry_2_3_ta_4_1. In effect that makes a module release a sort of patch release. Andy Jones QA Bod Tapestry Software ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
affect of large numbers of tags on performance
Hi, We use an automated build tool that performs many builds each day. Each time there is a successful build it applies an appropriate tag to our CVS repository. This has been running for a number of months now and on many files there are well over 100 tags - for files that don't change much, all 100 tags are on the same version number. Obviously this tag count is going to simply increase over time. Does anyone know if we should be concerned about this? How does such a large number of tags affect performance (checkout, commit, tag, log etc)? How does it affect the size of the repository in terms of disk space? Should we be looking to implement a scheme to purge old tags? Thanks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Please help..
Two things. First, did you work for 18 months on something without making backups? If you never made backups, then whether it was a mistake setting up CVS, some other kind of mistake, hardware failure, fire, or theft, you were destined to lose your work. I hope, however you resolve this issue, that you will always make nightly backups in the future. If you are ahead of me, and you have backups after all, then you can always use them to undo whatever you've done. I'm guessing, but at this point it may be easiest. Second, to get help you will need to be much more specific about exactly what you did when you figured out how to make a repository from your original source files. How did you set everything up (CVSROOT, etc)? What commands did you run? It sounds like you have some confusion about repositories versus working directories and the import process. Did you read the CVS manual before you started? I fear from your description you've gone pretty far down the wrong way. [EMAIL PROTECTED] wrote on 11/26/2003 11:32:10 AM: Hi All, I am seriously new to CVS. I have a large project that has been developed by my self for the past 18 months but is about to be taken on by a few other people so I though CVS would be a good way of working. I seem to have turned all of my original source files within the directory to have a .v extention and a lot of stuff has been added to these files. Please tell me their is an easy way to get my files back! I seem to have figurered out now how to make a repository from my original source files but they all have a double .v (.v.v) file extention now!!! Doh. Thanks in advance!! Cheers John ___ 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: Please help..
You need to spend some time with the manual, and/or the various tutorials on the subject. As you are discovering, if you're not understanding the manual, forging ahead anyway may not be the best decision. A repository is a database (that holds its data in RCS files - ending in .v). You create a repository in an _empty_ directory, somewhere separate (with cvs init), and then you import sources into it from wherever you have them (with cvs import). Then you do a cvs checkout to create a new CVS working directory from the repository - and that is where you then do your work. (Often people will move or zip the original directory they imported from, and then move their CVS working directory into its place.) You've created a repository right on top of where you are working, which is bad. I confess at this point I'm not sure what you've got in those files (perhaps someone wiser than myself can offer a shortcut?), but my best guess is that it will be easier to recover from backups than to reconstruct your sources from what's left of them now (.v.v files). At any rate, since you have backups, there is no reason to panic. In the future, just put your repository somewhere separate (/home/cvs/repository ?). And of course, have another go at the manual (or some of the other reading materials) to get a better handle on how the system works. John Wards [EMAIL PROTECTED] wrote on 11/26/2003 12:25:42 PM: On Wednesday 26 November 2003 4:57 pm, David Wood wrote: First, did you work for 18 months on something without making backups? Yes yes of course, but they are not with me currently and I am in a bit of a panic! Second, to get help you will need to be much more specific about exactly what you did when you figured out how to make a repository from your original source files. How did you set everything up (CVSROOT, etc)? What commands did you run? It sounds like you have some confusion about repositories versus working directories and the import process. Did you read the CVS manual before you started? I fear from your description you've gone pretty far down the wrong way. Yes I read the manual and I should have probably been a bit more detailed but I thought ah someone wil know an easy undo comand.seems not then :-( I got a bit confused with all the CVSROOT stuff etc. My source files are in /home/johnwards/www/sportnetwork I thought I should have done this: CVSROOT=/home/johnwards/www export CVSROOT cvs init Then: cvs import -m SportNetwork first import -d sportnetwork sportnetwork start This was wrong :-( I think. As its changed all my files... I am really confused by the manual...all I want to do is set up CVS using my source files...how on earth do you do it as I am really confused.. John ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: affect of large numbers of tags on performance
There's a small incremental cost per tag per file: Each tag is represented by a line in each RCS file. This is typically less than 100 bytes but it depends on the length of the tag and the depth of the branch to which the tag is applied. In terms of time, this amounts to probably a few milliseconds per file per 10,000 tags to process in most cases. The performance penalty is greater for cvs log due to the overhead to display them. I used a method similar to yours for 5 years on several projects, without much complaint about performance. I did find myself wishing to be able to clean old tags just to reduce clutter, but there was no technical requirement to do so. --- Forwarded mail from [EMAIL PROTECTED] We use an automated build tool that performs many builds each day. Each time there is a successful build it applies an appropriate tag to our CVS repository. This has been running for a number of months now and on many files there are well over 100 tags - for files that don't change much, all 100 tags are on the same version number. Obviously this tag count is going to simply increase over time. Does anyone know if we should be concerned about this? How does such a large number of tags affect performance (checkout, commit, tag, log etc)? How does it affect the size of the repository in terms of disk space? Should we be looking to implement a scheme to purge old tags? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I settled on a compromise for the nonce. I fixed the latest case insensitivity bug I knew of in 1.11.x and removed case insensitivity support from feature entirely. I've also added some tests of behavior involving heterogeneous combinations of case sensitive and case insensitive clients and servers to both branches though I've yet to get it set up for nightly testing (if anyone knows how to get Cygwin sshd to allow access to a mounted Samba share via its login shell, I could use some assistance). Since things look stable without case insensitivity support, I will probably remove support from stable too if any new bugs crop up. I'll probably roll a new release early next week. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/xP4ZLD1OTBfyMaQRAjN4AJ0dlk5zjIsae5xN6elNbLw9TKpl9ACg2KGD DIdO/rpFI8YlFAqUrOukha4= =q+r2 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Please help..
David, Perhaps John could try this? A suggestion to untangle: 1. Create a repository properly. 2. Copy the .v.v files into the repository manually. 3. Checkout the files into a working directory. (getting a .v file) 4. Copy the .v files manually into the repository. 5. Checkout the files into a working directory. (hopefully getting back the originals.) This assumes that the creating the repository over the original files didn't muck them up too much. John, Don't just try the above suggestion till we get more input. I'm just floating an idea and I think the experts here might have something more to say about it. Understanding how the repository is different from the working directory is crucial. A few clif notes: * You create a repository in an empty directory. This repository is separate and very different from the data you actually work on. In our case our repository is in /swdev/cvsroot. This is what the CVSROOT environment variable is set to. * You use ONLY cvs commands to get data into and out of the repository. Ideally you'd never directly touch the repository data. * You work in a separate working directory (off of your home directory probably, in my case /home/derosier/projects) and you check out your source code modules there. When you've made some changes you want to check in, you do a 'cvs commit' command. * Even if you run CVS locally, think of it as a server. It's a black box where you store things. You make requests to get data out, work on it, and then make a request to store data back in. From an OOP point of view: It is encapsulated data with a very well defined interface or API. Use the interface, don't touch the data. * If the above doesn't make sense to you, then read it again, read the CVS manual again until it makes sense. Do not try to setup and use CVS without understanding this. Hope this helps, - Steve David Wood wrote: You need to spend some time with the manual, and/or the various tutorials on the subject. As you are discovering, if you're not understanding the manual, forging ahead anyway may not be the best decision. A repository is a database (that holds its data in RCS files - ending in .v). You create a repository in an _empty_ directory, somewhere separate (with cvs init), and then you import sources into it from wherever you have them (with cvs import). Then you do a cvs checkout to create a new CVS working directory from the repository - and that is where you then do your work. (Often people will move or zip the original directory they imported from, and then move their CVS working directory into its place.) You've created a repository right on top of where you are working, which is bad. I confess at this point I'm not sure what you've got in those files (perhaps someone wiser than myself can offer a shortcut?), but my best guess is that it will be easier to recover from backups than to reconstruct your sources from what's left of them now (.v.v files). At any rate, since you have backups, there is no reason to panic. In the future, just put your repository somewhere separate (/home/cvs/repository ?). And of course, have another go at the manual (or some of the other reading materials) to get a better handle on how the system works. John Wards [EMAIL PROTECTED] wrote on 11/26/2003 12:25:42 PM: On Wednesday 26 November 2003 4:57 pm, David Wood wrote: First, did you work for 18 months on something without making backups? Yes yes of course, but they are not with me currently and I am in a bit of a panic! Second, to get help you will need to be much more specific about exactly what you did when you figured out how to make a repository from your original source files. How did you set everything up (CVSROOT, etc)? What commands did you run? It sounds like you have some confusion about repositories versus working directories and the import process. Did you read the CVS manual before you started? I fear from your description you've gone pretty far down the wrong way. Yes I read the manual and I should have probably been a bit more detailed but I thought ah someone wil know an easy undo comand.seems not then :-( I got a bit confused with all the CVSROOT stuff etc. My source files are in /home/johnwards/www/sportnetwork I thought I should have done this: CVSROOT=/home/johnwards/www export CVSROOT cvs init Then: cvs import -m SportNetwork first import -d sportnetwork sportnetwork start This was wrong :-( I think. As its changed all my files... I am really confused by the manual...all I want to do is set up CVS using my source files...how on earth do you do it as I am really confused.. John ___ 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
CVS check in privileges
Is there a way in CVS to allow check in privileges for a directory or a file in repository to a certain group of developers so that only they can make changes to files while others can work on the rest of the repository, without creating an entirely new repository? What we are trying to do is limiting check in access to only few developers for some specific files or directories. Thanks in advance. Hamid Ghassemi ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
Is the problem that you're not sure how to get the network drive into the sshd filesystem root? Or that when you try to that it fails? If it were the latter, it would be reminiscent of a similar problem I had trying to get apache to serve files from a network drive on Windows XP. We found that the Local System Account that the apache service ran under by default did not have permissions to access the drive. If you were having trouble with it, you might look into what user the sshd process is running as, and whether that user has permission to access the drive. [EMAIL PROTECTED] wrote on 11/26/2003 02:25:14 PM: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I settled on a compromise for the nonce. I fixed the latest case insensitivity bug I knew of in 1.11.x and removed case insensitivity support from feature entirely. I've also added some tests of behavior involving heterogeneous combinations of case sensitive and case insensitive clients and servers to both branches though I've yet to get it set up for nightly testing (if anyone knows how to get Cygwin sshd to allow access to a mounted Samba share via its login shell, I could use some assistance). Since things look stable without case insensitivity support, I will probably remove support from stable too if any new bugs crop up. I'll probably roll a new release early next week. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/xP4ZLD1OTBfyMaQRAjN4AJ0dlk5zjIsae5xN6elNbLw9TKpl9ACg2KGD DIdO/rpFI8YlFAqUrOukha4= =q+r2 -END PGP SIGNATURE- ___ 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: CVS check in privileges
Hamid Ghassemi [mailto:[EMAIL PROTECTED] wrote: What we are trying to do is limiting check in access to only few developers for some specific files or directories. http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_18.html#SEC167 -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Please help..
I had the same thought, Steve, and I think the same concern - given what he did, the repository _might_ have been a valid one the first time through - and it might be a valid repository of the repository now. But without knowing the nuts and bolts of the repository and import process, I can think of reasons why it wouldn't be. Of course, there's not much to lose in performing the experiment, as long as you take care and keep copies of everything. I'll be curious to hear if following these instructions would work. [EMAIL PROTECTED] wrote on 11/26/2003 02:46:10 PM: David, Perhaps John could try this? A suggestion to untangle: 1. Create a repository properly. 2. Copy the .v.v files into the repository manually. 3. Checkout the files into a working directory. (getting a .v file) 4. Copy the .v files manually into the repository. 5. Checkout the files into a working directory. (hopefully getting back the originals.) This assumes that the creating the repository over the original files didn't muck them up too much. John, Don't just try the above suggestion till we get more input. I'm just floating an idea and I think the experts here might have something more to say about it. Understanding how the repository is different from the working directory is crucial. A few clif notes: * You create a repository in an empty directory. This repository is separate and very different from the data you actually work on. In our case our repository is in /swdev/cvsroot. This is what the CVSROOT environment variable is set to. * You use ONLY cvs commands to get data into and out of the repository. Ideally you'd never directly touch the repository data. * You work in a separate working directory (off of your home directory probably, in my case /home/derosier/projects) and you check out your source code modules there. When you've made some changes you want to check in, you do a 'cvs commit' command. * Even if you run CVS locally, think of it as a server. It's a black box where you store things. You make requests to get data out, work on it, and then make a request to store data back in. From an OOP point of view: It is encapsulated data with a very well defined interface or API. Use the interface, don't touch the data. * If the above doesn't make sense to you, then read it again, read the CVS manual again until it makes sense. Do not try to setup and use CVS without understanding this. Hope this helps, - Steve David Wood wrote: You need to spend some time with the manual, and/or the various tutorials on the subject. As you are discovering, if you're not understanding the manual, forging ahead anyway may not be the best decision. A repository is a database (that holds its data in RCS files - ending in .v). You create a repository in an _empty_ directory, somewhere separate (with cvs init), and then you import sources into it from wherever you have them (with cvs import). Then you do a cvs checkout to create a new CVS working directory from the repository - and that is where you then do your work. (Often people will move or zip the original directory they imported from, and then move their CVS working directory into its place.) You've created a repository right on top of where you are working, which is bad. I confess at this point I'm not sure what you've got in those files (perhaps someone wiser than myself can offer a shortcut?), but my best guess is that it will be easier to recover from backups than to reconstruct your sources from what's left of them now (.v.v files). At any rate, since you have backups, there is no reason to panic. In the future, just put your repository somewhere separate (/home/cvs/repository ?). And of course, have another go at the manual (or some of the other reading materials) to get a better handle on how the system works. John Wards [EMAIL PROTECTED] wrote on 11/26/2003 12:25:42 PM: On Wednesday 26 November 2003 4:57 pm, David Wood wrote: First, did you work for 18 months on something without making backups? Yes yes of course, but they are not with me currently and I am in a bit of a panic! Second, to get help you will need to be much more specific about exactly what you did when you figured out how to make a repository from your original source files. How did you set everything up (CVSROOT, etc)? What commands did you run? It sounds like you have some confusion about repositories versus working directories and the import process. Did you read the CVS manual before you started? I fear from your description you've gone pretty far down the wrong way. Yes I read the manual and I should have probably been a bit more detailed but I thought ah someone wil know an easy undo comand.seems not then :-( I got a bit confused with all the CVSROOT
Re: CVS check in privileges
On Thu, 27 Nov 2003 07:14 am, Hamid Ghassemi wrote: Is there a way in CVS to allow check in privileges for a directory or a file in repository to a certain group of developers so that only they can make changes to files while others can work on the rest of the repository, without creating an entirely new repository? What we are trying to do is limiting check in access to only few developers for some specific files or directories. The best way to do this is to have a script which checks repoitories/files against certian usernames and either allows/or disallows the checkin to continue. It took me a while to figure out how to do it, so I have made a website explaining what I did (: http://rhoden.id.au/doc/cvs-commitcheck.html You need to customise the script for your own usernames and repository / file names. Regards, Jacob Jacob RhodenPhone: +61 3 8344 4478 ITS DivisionEmail: [EMAIL PROTECTED] Melbourne University Mobile: +61 403 788 386 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Loading files into CVS with a declared date
From: [EMAIL PROTECTED] (Paul Sander) Date: Tue, 25 Nov 2003 14:34:00 -0800 CVS has no such option, but RCS does. The ci program, which creates a new revision in a ,v file, can override the system time when storing a timestamp. To use it, you must muck directly with the repsitory. --- Forwarded mail from [EMAIL PROTECTED] I have the job of transitioning a large archive from an in-house system to CVS. I have all of the tools to do the maintenance of the repository, but I need to load all of the historical data into my repository. I have the time-stamps when these files were entered into my archive and the change-log information. Is there any way to force a commit to put a timestamp on a commit? Any hacks to cvs to allow this? I guess what I want to do is: cvs commit -D 1997-10-23 20:45 file, but there is no such command. --- End of forwarded message from [EMAIL PROTECTED] Thanks to all who replied, Paul Sander, Mark D. Baushke, and Allan Schrum. I think using ci to insert my files into an RCS repository looks like the ticket. Can I then import the RCS repository into a cvs repository? That looks like the a job for cvs import. Since the CVS repo is being newly created and will be empty at the start, it looks like I can just dump all of my files into the RCS repo and do an import into CVS. Am I reading the man pages correctly? Thanks again and have a Happy Thanksgiving (even if you live in another country and have never eaten cranberry sauce)! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Loading files into CVS with a declared date
--- Forwarded mail from [EMAIL PROTECTED] From: [EMAIL PROTECTED] (Paul Sander) Date: Tue, 25 Nov 2003 14:34:00 -0800 CVS has no such option, but RCS does. The ci program, which creates a new revision in a ,v file, can override the system time when storing a timestamp. To use it, you must muck directly with the repsitory. --- Forwarded mail from [EMAIL PROTECTED] I have the job of transitioning a large archive from an in-house system to CVS. I have all of the tools to do the maintenance of the repository, but I need to load all of the historical data into my repository. I have the time-stamps when these files were entered into my archive and the change-log information. Is there any way to force a commit to put a timestamp on a commit? Any hacks to cvs to allow this? I guess what I want to do is: cvs commit -D 1997-10-23 20:45 file, but there is no such command. --- End of forwarded message from [EMAIL PROTECTED] I think using ci to insert my files into an RCS repository looks like the ticket. Can I then import the RCS repository into a cvs repository? That looks like the a job for cvs import. Since the CVS repo is being newly created and will be empty at the start, it looks like I can just dump all of my files into the RCS repo and do an import into CVS. Am I reading the man pages correctly? Do not run cvs import on RCS files; you'll end up versioning the RCS files themselves, which is probably not what you want. Instead, just copy the RCS files into your CVS repository, in whatever shape your source tree demands. Then write your modules database to suit. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Please help..
David, Have you tried to check out files from the repository you created? I understand there is some question as to the integrity of the repository you created, but I can think of no better way to determine if all is well than to try a checkout. The safest way to do this is the following: export CVSROOT=/home/johnwards/www mkdir /tmp/test_checkout cd /tmp/test_checkout cvs co sportnetwork It sounds to me from reading your description of how you created this repository, all you did was create a whole bunch of ,v files in the same directory where the source files you imported were located. Not how you want to normally create a repository, but that should not have resulted in any data loss of the files you imported. I just tried what you did and I got some ,v and ,v,v files for some of the original source files. This happened for some, but not all of the source files. I believe this is what happened. During the import CVS creates a source control file (the file,v file) for each file being imported. However, since you were creating the repository in the same directory as where you were importing from, the CVS picked up some of the newly created file,v files as source files that needed to be imported into the repository. That resulted in the creation of the file,v,v files. Why this did not keep recursively picking up all of the ,v files and then the ,v,v files to create ,v,v,v files and so on is beyond me. The good news is no data has been lost, at least in the test I performed. You should be able to safely do a checkout like I describe above, then delete all of the file,v files that you get as part of the checkout. But absolutely make sure you are doing this checkout test IN A NEW WORK DIRECTORY, separate from any directory in the /home/johnwards/www path. These file,v files you get as part of this checkout can be safely deleted, because they were created as part of the recursive import that happened as I describe above. All they are is an import of a CVS file1,v file, which is of no use to you. You will also see the corresponding file1 file, which is the source file you want. After you do this checkout test and prune out the files,v files, make sure you can still build your project, or whatever integrity check you can perform over these files to insure they are in a good state. Assuming that goes well, then start over, and create a new good repository. You almost had it right. From reading what you did, the only mistake I can see that you made was setting your CVSROOT=/home/johnwards/www. Do this instead, and you should be in good shape: mkdir /home/johnwards/cvsroot export CVSROOT=/home/johnwards/cvsroot cvs init cd /tmp/test_checkout cvs import -m SportNetwork first import sportnetwork vendor_tag release1 After you do this, you then need to checkout the source code you just checked into CVS into a new, empty work area. I'd do the following: cd /home/johnwards/www mv sportnetwork sportnetwork.saveme cvs co sportnetwork Make sure you archive off and save /home/johnwards/www/sportnetwork.saveme, just in case you need to go back to this mixed up work area to recover any files. I think you can recover from your original mistake, assuming you have not panicked and done something in the interim that has made your original mistake worse. I hope some of what I have described above is helpful to you. Good luck, Adam --- Adam Bernstein [EMAIL PROTECTED] http://mpgedit.org/~number6 On Wed, 26 Nov 2003, David Wood wrote: I had the same thought, Steve, and I think the same concern - given what he did, the repository _might_ have been a valid one the first time through - and it might be a valid repository of the repository now. But without knowing the nuts and bolts of the repository and import process, I can think of reasons why it wouldn't be. Of course, there's not much to lose in performing the experiment, as long as you take care and keep copies of everything. I'll be curious to hear if following these instructions would work. [EMAIL PROTECTED] wrote on 11/26/2003 02:46:10 PM: David, Perhaps John could try this? A suggestion to untangle: 1. Create a repository properly. 2. Copy the .v.v files into the repository manually. 3. Checkout the files into a working directory. (getting a .v file) 4. Copy the .v files manually into the repository. 5. Checkout the files into a working directory. (hopefully getting back the originals.) This assumes that the creating the repository over the original files didn't muck them up too much. John, Don't just try the above suggestion till we get more input. I'm just floating an idea and I think the experts here might have something more to say about it. Understanding how the repository is different from the working directory is crucial. A few clif notes: * You create a repository in an empty directory. This repository is separate and
Re: affect of large numbers of tags on performance
In addition to tagging, we also built a manifest of the source files, checked it in, and applied the same tag as was applied to the rest of the build. The manifest was stored separately from the source code so that developers wouldn't muck with its tags. Our rebuild procedure used that file to populate a workspace rather than relying on the tagged sources, in case the developers fudged the tags for any reason after the build completed. (We also had a changeset mechanism, and having the manifest in advance made the integration and reversion computations easier.) Our manifest included the path of the source file relative to the root of the workspace, plus the version number. This worked because we didn't use the modules database and instead used directory names from the repository directly. All of our source code lived in a single repository, also. To do this today, you'd want to include the contents of the Repository file, the path (relative to the top of the repository) to the RCS file, the version number, and the path to the source file (relative to the top of the workspace). --- Forwarded mail from [EMAIL PROTECTED] If you are worried about not being able to get a older build using a tag, when you delete the tag, stick the file revision, name, folder name, EXACT date/time of commit etc in a database along with the tag you are deleting in SQL database. You can get these info from the rlog/log files. In future if someone says give me build_xxx .. Simply do a lookup in the SQL database for this date, get the EXACT date/time of the commit and just use that as a 'tag'. CVS allows passing the date/time to get a revision. Like CVS co 2003-10-10 14:00 will give me all the commits I did that are near or exactly matching October 10th, 2003 2:00 PM ... --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Importing into Different Repositories
Hi All, I am having more than 2 repositaries. I am importing source files into the repositories. I want to know how to do this. Is there any option in the import command. It always goes into only one repository. Advice is highly Appreciated. Thanks in Adv Narendhran.K Do you Yahoo!? Free Pop-Up Blocker - Get it now___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
