Re: CVS Server Change
What would be an appropriate way to merge the two CVS servers? I am just trying to simply copy the files (,v files) in one CVS server to the other CVS server. Would that cause any harm for the existing CVS files in the target CVS server? SH- On 6/24/05, Spiro Trikaliotis [EMAIL PROTECTED] wrote: Hello, * On Fri, Jun 24, 2005 at 01:13:28AM + Pierre Asselin wrote: Soo-Hyun Choi [EMAIL PROTECTED] wrote: I am a beginner in using CVS, and have a question on to change the CVS server. [ ... ] Would this work if I simply copy the CVS's ,v files with the directory to the machine S's cvsroot directory? Yes. This also makes your existing sandboxes nonfunctional, so be sure to delete them after committing any pending changes. Check out new sandboxes from the new server after the move. To the OP: If your server already has a CVS server (and, thus, a CVSROOT directory) and you want to merge both repositories into one, make sure you do NOT move that directory over to the server, but make sure you MERGE them in an appropriate way. If you just overwrite the old CVSROOT, you might get trouble with the data which is already stored on the server! Apart from this, it works exactly like you thought (and Pierre confirmed). Obviously, its best if you do not try to merge two cvs servers into one. Regards, Spiro. -- Spiro R. Trikaliotis http://cbm4win.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
a newbie facing tagging problem
Title: a newbie facing tagging problem Hi, I am newbie in using cvs. I am using a cvs configured by somebody else. I am facing a problem with the cvs setup as follows: I have remote repository When we tag main directory of a project it is shown that For xyz/abcsys/src/base/vlan/Makefile HEAD and other tags are shown correctly. Branch:MAIN inside vlan directory there is another vlan sub directory. But for files in this: For xyz/abcsys/src/base/vlan/vlan/Makefile Only HEAD tag is shown. Branch:MAIN Due this I am facing tremendeous problem in building old versions. What could be the cause/solution for the problem. Am I alone who has faced this problem? Thanks in advance, akumar ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Server Change
Hello again, * On Fri, Jun 24, 2005 at 02:51:08PM +0900 Soo-Hyun Choi wrote: What would be an appropriate way to merge the two CVS servers? I am just trying to simply copy the files (,v files) in one CVS server to the other CVS server. Would that cause any harm for the existing CVS files in the target CVS server? Ok, in some more details: You have a cvsroot directory, in your example, the local one is ~/cvsroot. In that directory, you have a CVSROOT directory. In your example, this is the ~/cvsroot/CVSROOT/ directory. This CVSROOT directory contains some information about your repository (for example, your modules file). If you happen to overwrite the modules file in the server CVS, then the modules there would be lost (or, to say it better, you would have to restore the file to be able to access them like before). Of course, I do not know if you ever changed anything in your ~/cvsroot/CVSROOT/ directory. If you did not, just move every ,v file to the server, leaving out all files in ~/cvsroot/CVSROOT/. Make sure you do not overwrite other files if they happen to already exist on the server! (directories with the same name, for example). If you made any changes to your ~/cvsroot/CVSROOT/ directory, I would suggest you should try to find out what you changed exactly, and put these changes in the server's CVSROOT by hand after thinking about what you need and what you do not need (or, what might break things on the server). HTH, Spiro. -- Spiro R. Trikaliotis http://cbm4win.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: a newbie facing tagging problem
[EMAIL PROTECTED] writes: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! When we tag main directory of a project it is shown that For xyz/abcsys/src/base/vlan/Makefile HEAD and other tags are shown correctly. Branch:MAIN inside vlan directory there is another vlan sub directory. But for files in this: For xyz/abcsys/src/base/vlan/vlan/Makefile Only HEAD tag is shown. Branch:MAIN Due this I am facing tremendeous problem in building old versions. What could be the cause/solution for the problem. The problem is that the files in that directory have never been tagged. From you description, it's not clear whether you're trying to apply a new tag or you're trying to use a tag that was applied some time in the past. If the problem is with a new tag that you applied using cvs tag, it would appear that your working directory has become corrupted in some way such that CVS commands don't know that that directory exists. If there aren't any changes in your working directory that you need, the simplest fix is to delete it and do a new checkout. Otherwise, check the CVS/Entries file in the parent vlan directory -- it should contain an entry for the vlan subdirectory, which you can add by hand if necessary. If the problem is with an old tag, the problem is that the directory was never tagged in the first place and there's nothing you can do now to fix it other than trying to recreate the correct state of the directory (perhaps by updating to a particular date/time) and applying the tag now. -Larry Jones It's going to be a long year. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: a newbie facing tagging problem
On Fri, 24 Jun 2005, Larry Jones wrote: [EMAIL PROTECTED] writes: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! Why doesn't this list run something like the demime package to scrub HTML/MIME postings to this list, so people don't have to be bothered with worring about how their mail client is configured? http://scifi.squawk.com/demime.html I use it on the mailing list I manage, and it does a fair job of converting HTML to plain text and it does strip MIME attachments out of mail. Adam ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: $Name$ causes files to be locally modified
Thanks for the suggestion, I have implemented commitinfo script to prevent someone from using $Name$, but I'm curious as to why $Name$ works differently from the other keyword expansions. Why does this keyword cause the file to be locally modified on expansion, when all the other keywords I've used ($Header$, $Id$, etc) all correctly update the field, and leave the file update-to-date? Personally, I consider this a bug in cvs itself. Is there a good reason the file needs to be locally modified after expanding $Name$? Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Denniston Sent: Thursday, June 23, 2005 8:38 AM To: Jorgensen, Steven Cc: info-cvs@gnu.org Subject: Re: $Name$ causes files to be locally modified Jorgensen, Steven wrote: I am having a problem with the $Name$ keyword expansion. We use a cvs tag to indicate when a file has moved beyond local testing stage, and is ready for general use by all developers (a release tag if you will) so that we can automate a update and build process to keep a working development version of our software compiled for all developers. So this tag is not permanently attached to a single revision, rather it moves as files get modified and tested by individual developers and released for use by other developers. The problem I'm having is when people use the $Name$ keyword in their file. In this tree of released software, it causes any file that contains a $Name$ keyword to be in a Locally Modified state when it is checked out. Where the only difference in the file is the fact that $Name$ is now filled out. The next time around we run an update on one of these files that changes, produces a conflict on the $Name$ line. For example: Myheader.h --- const char *tag = $Name$; Becomes on the next revision. Myheader.h Const char *tag = $Name: releasetag $; == Const char *tag = $Name: $; 1.2 Is there any way to prevent this from happening? On all the other keyword expansions $Id$, $Header$, etc, the keyword is expanded, but the file's status is Up-to-date. Thanks for any help. Steve Steven Jorgensen [EMAIL PROTECTED] Method #1, I think if the update is done with the '-kk' option it will stop the expansion. Method #2, tell your developers to stop using keywords and remove them where ever they find them. Method #3, do Method #2, and prevent the developers from checking files in to the baseline with the keywords inside, using a commitinfo script. ***begin simplistic commitinfo script (in bash)* #echo 0($0) 1($1) 2($2) 3($3) @($@) #get rid of path at the begining shift 1 #echo 0($0) 1($1) 2($2) 3($3) @($@) ARGS=$@ for i in $ARGS do # cat $i # exit 1 if grep -e \\$Name:\\$ -e \\$Id:\\$ $i then echo we no longer allow rcs keywords in the files, find your info in the echo cvs log from now on. exit 1 fi done ***end simplistic commitinfo script* BTW never written a commitinfo before, no warranties on the above script. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
demime the list? (was Re: a newbie facing tagging problem)
[EMAIL PROTECTED] wrote: On Fri, 24 Jun 2005, Larry Jones wrote: [EMAIL PROTECTED] writes: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! Why doesn't this list run something like the demime package to scrub HTML/MIME postings to this list, so people don't have to be bothered with worring about how their mail client is configured? http://scifi.squawk.com/demime.html I use it on the mailing list I manage, and it does a fair job of converting HTML to plain text and it does strip MIME attachments out of mail. Adam Speeking mostly for my self, translating the message text would not be a bad thing, but MIME ATTACMENTS are NEEDED so we can exchange code patches and scripts where the formatting of the data matter. i.e., if someone needs to send an attachment that is MIMEed, no problem, but the message body should be ASCII text. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Regarding check-in of unicode characters.
Arthur Barrett wrote: Maninder, CVS does not support Unicode files, instead they must be committed as binary, in which case you cannot do diff/merge etc. CVSNT on Mac/Linux/Unix/Windows (free, open source, GPL, just like CVS) does support unicode files (-ku). Please supply more information (file type in repository, cvs version etc). To determine the status of the file use: cvs status myfile To determine your version of CVS use: cvs version If you are using CVSNT then the CVSNT newsgroup is the place that the developers of CVSNT answer questions: news://news.cvsnt.org/support.cvsnt news://news.cvsnt.org/support.cvsnt or http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt Regards, Arthur Barrett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maninder Singh(SDG) Sent: Thursday, 16 June 2005 1:51 AM To: info-cvs@gnu.org Subject: Regarding check-in of unicode characters. Hi All, We are trying to check-in the following characters into CVS. But while doing so, the highlighted characters get corrupt and upon checking out, these are replaced by some other characters. Sí (means yes in Spanish) Sì (means yes in Italian) Can anybody provide a solution? Thanks and Regards, Maninder Singh ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Regarding check-in of unicode characters.
Hi Maninder - You can use UTF-8 encoded files. UTF-8 is a method of representing Unicode text with a stream of 8-bit bytes. The resulting stream is both ASCII-compatible and reverse-ASCII-compatible. A single character can occupy from 1 to 4 bytes. Most IDE and editors like emacs these days, will let you switch the default charset encoding from ASCII to UTF-8. More information on Unicode and UTF-8 is here - http://www.unicode.org/faq/utf_bom.html#14 A UTF-8 encoded source file with text in UTF-8 can be handled by CVS (on Linux etc) without any problems. Most IDEs and Editors supporting CVS can be configured for UTF-8 encoding by default to get Unicode support in CVS to work seamlessly. With regards to CVSNT, the big difference is CVSNT supports a -ku keyword flag to let you have the file in UTF-16 be automatically be converted to UTF-8. Internally CVSNT also stores the files in UTF-8. Since most IDE, editors and tools will do UTF-8 encoding, this may be good enough. For command-line cvs usage, tools like iconv (on UNIX, Cygwin) can be used to go from any format to any other. So just use UTF-8 and you should be home. You could have a script do iconv before and after any ci/co to make it seamless. Rahul Bhargava, CTO, WANdisco Mountain View, CA http://www.wandisco.com/cvs Arthur Barrett wrote: Maninder, CVS does not support Unicode files, instead they must be committed as binary, in which case you cannot do diff/merge etc. CVSNT on Mac/Linux/Unix/Windows (free, open source, GPL, just like CVS) does support unicode files (-ku). Please supply more information (file type in repository, cvs version etc). To determine the status of the file use: cvs status myfile To determine your version of CVS use: cvs version If you are using CVSNT then the CVSNT newsgroup is the place that the developers of CVSNT answer questions: news://news.cvsnt.org/support.cvsnt news://news.cvsnt.org/support.cvsnt or http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt Regards, Arthur Barrett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maninder Singh(SDG) Sent: Thursday, 16 June 2005 1:51 AM To: info-cvs@gnu.org Subject: Regarding check-in of unicode characters. Hi All, We are trying to check-in the following characters into CVS. But while doing so, the highlighted characters get corrupt and upon checking out, these are replaced by some other characters. Sí (means yes in Spanish) Sì (means yes in Italian) Can anybody provide a solution? Thanks and Regards, Maninder Singh ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
cannot open /nonexistant/.cvsignore: Permission denied
Hello Colleagues, I am using CVS version 1.11.17. My server is in Oregon. My client is in California. It runs on a PC under Windows XP using CYGWIN_NT-5.1 1.5.13(0.122/4/2) 2005-03-01 11:01. CVS works fine for me. However, every time I do a check in I get an additional error message: cvs server: cannot open /nonexistant/.cvsignore: Permission denied Every time I do a cvs update it works but every directory has an additional error message: cvs update: cannot open /nonexistant/.cvsignore: Permission denied I looked into my directories. File .cvsignore is present everywhere. Its permissions are writable to me. As an experiment I focused on one directory and made .cvsignore file writable to everybody. It did not help. I searched and have not found any directory with nonexistant name. I searched Internet and your archives. This message was not found. I would really appreciate if anybody knows where these messages come from and why. Thank you in advance. Boris ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
undesirable cvs behavior?
Hello. I'm writing regarding the behavior of cvs on the
backuprecover-15 test case. The comments call it a 'failure case',
which seems to mean 'the behavior is broken, but since we know what
the behavior is, we'll make sure we don't change it accidently'.
# Note that backuprecover-15 is probably a failure case
# If nobody else had a more recent update, the data would be lost
# permanently
# Granted, the developer should have been notified not to do this
# by now, but still...
We have a situation where we may have to quickly failover to a mirror
which may be missing 5-10 minutes of data. In that case, it would be
impractical to ensure that every engineer knows that they may lose data
if they update. Consequently, I've written the attached patch to
treat a workspace with a newer unmodified version of a file as an
error.
The test suite needs a few changes to pass; With the patch, cvs
behavior in response to an admin command changes. Currently, if
version 1.5 is removed via 'cvs admin -o', any tree with an unmodified
version of 1.5 silently reverts to 1.4 at the time of next
update. After the patch, cvs will complain at the time of next
update. Consequently, a few tests which check the previous behavior
need changes.
I have a few questions:
1. Does anyone see any problems that this patch would cause?
2. Would cvs developers be interested in integrating this behavior?
If so, I'll be happy to generate a real patch (ChangeLog entry,
testsuite changes, GNU coding style, copyright assignment (if
needed)), but I wanted to check for interest before I go through and
do all the details.
3. Does anyone know of a better way to accomplish this?
Thanks for your time,
greg
--
[EMAIL PROTECTED] | maintaining individual accountability
http://docs.yahoo.com/info/values/
--- classify.c.old 2005-06-16 19:19:30.0 -0700
+++ classify.c 2005-06-16 22:52:13.0 -0700
@@ -341,7 +341,7 @@
}
else
{
- /* The RCS file is a newer version than the user file */
+ /* The RCS file version does not match the user file */
if (vers-ts_user == NULL)
{
@@ -354,19 +354,43 @@
error (0, 0, warning: %s was lost, finfo-fullname);
ret = T_CHECKOUT;
}
+ /* if vers-tag is set, then we could be updating a file
+ on a branch, which if the file hasn't been modified on the
+ branch, could wind up being a lower version than our file
+ basically:
+ add 1.1
+ tag -b foo
+ remove (dead 1.2)
+ add (1.3)
+ update -r foo (vn_rcs == 1.1, vn_user == 1.3)
+ (see resurrection tests)
+ */
else if (strcmp (vers-ts_user, vers-ts_rcs) == 0)
{
-
- /*
-* The user file is still unmodified, so just get it as well
-*/
- if (strcmp (vers-entdata-options ?
- vers-entdata-options : , vers-options) != 0
- || (vers-srcfile != NULL
-(vers-srcfile-flags INATTIC) != 0))
- ret = T_CHECKOUT;
- else
- ret = T_PATCH;
+ if (((!vers-tag) || (0 == strcmp(vers-tag, HEAD)))
+ (!vers-date)
+ /* comparing versions is only reliable if numdots is the
same */
+(numdots(vers-vn_user) == numdots(vers-vn_rcs))
+(compare_revnums(vers-vn_user, vers-vn_rcs) 0))
+ {
+ ret = T_MODIFIED;
+ error (1, 0, file '%s` has revision %s, but the repository
only has %s\n,
+ finfo-fullname, vers-vn_user, vers-vn_rcs);
+
+ } else {
+
+
+ /*
+ * The user file is still unmodified, so just get it as well
+ */
+ if (strcmp (vers-entdata-options ?
+ vers-entdata-options : , vers-options) != 0
+ || (vers-srcfile != NULL
+(vers-srcfile-flags INATTIC) != 0))
+ ret = T_CHECKOUT;
+ else
+ ret = T_PATCH;
+ }
}
else if (No_Difference (finfo, vers))
/* really modified, needs to merge */
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
