Aliasing the trunk with a branch tag
One problem I regularly face is: how to build two different versions of a project which differ in only a very small subset of files. One of these versions is obviously the trunk version. It would be extremely convenient if this could be achieved by simply cvs co (or update) -A myproject cvs co (or update) -r Version_B myproject to switch between them. The main (trunk) version is under continual development and "Version_B" should mean "the head of the branch Version_B for the few files which differ and the head of the trunk otherwise". Obviously only branch tags will do. But attaching a branch tag to the files which differ will fix the version beloning to "Version_B" for all time (or until I move the unused branch tag by hand). I recenty came across a suggestion of how to do this, and it does work when I tried it out. The idea is simple - just add the branch at the numeric version "1": cvs admin -nVersion_B:1 for the files common to both versions of the project. This makes branch Version_B an alias for the trunk. Then make a regular branch for the files which differ. (This assumes the RCS revisions on the trunk are all 1.nnn ..., but the extension to other cases is obvious). Now cvs co -r Version_B myproject does indeed fetch all of the files needed to build or develop Version_B of the project, which benefits from any changes to the trunk version. I'm asking for any opinions on whether this is a safe thing to do, and any potential difficulties, mild or severe, which might arise. Keith Refson ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about process scheduleing
Lynch, Harold writes: > > On most of the machine in the shop it takes between 10 and 15 minutes, > on one machine it can take an hour. Look for network problems with that machine -- that sounds like dropped packets and retransmissions. -Larry Jones Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about process scheduleing
> "Lynch, Harold" wrote: > > I'm trying to look into a problem with the amount of time it takes us to do > a checkout of a large (800 meg) module. > > On most of the machine in the shop it takes between 10 and 15 minutes, on > one machine it can take an hour. > > When I look at top on the cvs server, the process associated with the pulls > to that machine get very little cpu. > Is there any kind of scheduling going on inside the cvs server process > (aside from blocking for io)? > > Harold Lynch Have you looked at top on the slow machine? You did not indicate if it has a bitty processor, compared to others, or if it has a lot of work happening on it all the time, or even if it has an old slow hard drive that the 800 meg is getting written to. Oh you are using :ext: or :pserver: access method right? Have you made sure the network connection to the slow machine is as fast as the others and in good repair? (Assuming Unix) check the output of ifconfig if the following are not 0 you might have a bad cable/hub/card errors:0 dropped:0 overruns:0 carrier:0 (not necessarily a good indicator, mine has a few here) check with ping `ping -c100 -s1492 slowmachine` if there is any loss in a LAN, something is going on you need to look into. `time ping -f -c1000 -s1492 slowmachine` for a slow processor machine on a 10Mb/s LAN the loss here should still be sub 20%. and running `time ping -f -c1000 -s1492` against a fast machine too might give you some insight. also the following might you measure the path. http://freshmeat.net/projects/netio/ -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about process scheduleing
Lynch, Harold wrote: I'm trying to look into a problem with the amount of time it takes us to do a checkout of a large (800 meg) module. On most of the machine in the shop it takes between 10 and 15 minutes, on one machine it can take an hour. When I look at top on the cvs server, the process associated with the pulls to that machine get very little cpu. Is there any kind of scheduling going on inside the cvs server process (aside from blocking for io)? I had a problem like this that ultimately turned out to be a network card misbehaving, particularly with ssh. Andrew Thomas ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
CVS 1.12.9 breaks emacs pcl-cvs mode - known bug?
Hello all, The latest version of CVS, version 1.12.n (n>5), changed the format of its output on commit messages. This unfortunately breaks pcl-cvs mode in emacs, which uses the commit messages to determine which files have been committed. It is of course possible to alter pcl-cvs to parse the new messages, but the new messages produced by CVS no longer contain sufficient information for a front-end to be able to determine what has happened. CVS needs to be altered slightly to produce sufficient information so that front-end programs can function. I'll clarify below, but my question is: Is this a known bug, and is there any plan to fix it? Cheers, Andrew Thomas --- The problem in more detail --- First, the way it used to work: === andrew:~$ cvs -v Concurrent Versions System (CVS) 1.12.5 (client/server) Copyright (c) 1989-2003 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS This is the structure of a the CVS repository: == andrew:~$ ls -R temp temp: CVSROOT projects temp/CVSROOT: Emptydircommitinfo,v cvswrappers,v modulesrcsinfoval-tags checkoutlistconfighistorymodules,v rcsinfo,v verifymsg checkoutlist,v config,v loginfonotify taginfo verifymsg,v commitinfo cvswrappers loginfo,v notify,v taginfo,v temp/CVSROOT/Emptydir: temp/projects: project1 project2 temp/projects/project1: module1 temp/projects/project1/module1: main.c,v temp/projects/project2: module2 temp/projects/project2/module2: main.c,v I change main.c in two separate projects, and then perform a commit: andrew:~/temp3$ cvs commit -m"test" cvs commit: Examining projects cvs commit: Examining projects/project1 cvs commit: Examining projects/project1/module1 cvs commit: Examining projects/project2 cvs commit: Examining projects/project2/module2 Checking in projects/project1/module1/main.c; /home/andrew/temp/projects/project1/module1/main.c,v <-- main.c new revision: 1.2; previous revision: 1.1 done Checking in projects/project2/module2/main.c; /home/andrew/temp/projects/project2/module2/main.c,v <-- main.c new revision: 1.2; previous revision: 1.1 done andrew:~/temp3$ ** Notice that CVS produces four lines of output for each file, indicating the relative local path of the file on the first line, and then the repository file name and the basename of the local file on the second line. pcl-cvs needs the relative local path on the first line (the "Checking in..." line) in order to determine which file was actually committed. Now, the newer broken way: == andrew:~/temp3$ cvs -v Concurrent Versions System (CVS) 1.12.9 (client/server) Copyright (c) 1989-2004 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS Again, change both main.c files and commit: === andrew:~/temp3$ cvs commit -m"test" cvs commit: Examining projects cvs commit: Examining projects/project1 cvs commit: Examining projects/project1/module1 cvs commit: Examining projects/project2 cvs commit: Examining projects/project2/module2 /home/andrew/temp/projects/project1/module1/main.c,v <-- main.c new revision: 1.3; previous revision: 1.2 /home/andrew/temp/projects/project2/module2/main.c,v <-- main.c new revision: 1.3; previous revision: 1.2 andrew:~/temp3$ ** Notice that CVS no longer produces the first and fourth lines of output. The first line was the only one carrying the relative local path to the file being committed. It is no longer possible for pcl-cvs to determine which file was committed. It is not possible in general to "guess" the local file path from the repository file name since each directory has its own CVSROOT so that the repository organization is not necessarily anything like the local directory organization. It is also not possible to use the "Examining " lines in the output since they all precede the first file commit message, so we still do not know which files belong to which directories. Other programs acting as a front-end to CVS will also likely break with this new reduced (insufficient) information. WinCVS comes to mind, though I have not tested it. This whole problem could be trivially resolved in CVS by simply altering the line: /home/andrew/temp/projects/project1/module1/main.c,v <-- main.c to read /home/andrew/temp/projects
Re: Reverting a concrete revision
[EMAIL PROTECTED] writes [in very long lines]: > > Using i.e "cvs update -j -j > file.c", we discard changes from 1.6 to 1.3. Then, commiting, we get > revision 1.7 that is exactly the same as 1.3. Now, suppose I want to > generate a new revision of "file.c" but containing code from 1.1 to 1.3 > + 1.5 and 1.6 revision, because I realise that I don not want the > changes made on revision 1.4 but still want all the changes made in 1.5 > and 1.6. Doing the previous update, I lost 1.4 changes but also 1.5 and > 1.6. So the idea is revert ONLY the changes that were made on 1.4. If > the changes of 1.5 and 1.6 are small (or changes of 1.) it can be do it > manually but this is not my case. > > Is there any way to do this in CVS? Of course, just merge those changes back in: cvs up -j1.4 -j1.6 file.c -Larry Jones These findings suggest a logical course of action. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about RCS files
K. Posern wrote: But I need an exact copy of the version a CLIENT has in its > /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). How can I achieve this? Do I have to to do an cvs-checkout > on the server and cvs-update everytime a client did commit > something? Or can I say to the server somehow to keep automatically > the rcs stuff seperate in one dir and an "client-like-copy" > of the cvs-repository in another dir? You have to do a cvs-checkout into a separate directory on the server, and then perform a cvs-update every time a client does a commit. In UN*X you can do the checkout on a cron job periodically. In Windows I think you can use cygwin to set up a cron job as well. You could also abuse the "loginfo" script so that after every commit the server runs a "cvs update" in you checked-out directory. See https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC167 Cheers, Andrew Thomas ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Question about process scheduleing
Title: Question about process scheduleing I'm trying to look into a problem with the amount of time it takes us to do a checkout of a large (800 meg) module. On most of the machine in the shop it takes between 10 and 15 minutes, on one machine it can take an hour. When I look at top on the cvs server, the process associated with the pulls to that machine get very little cpu. Is there any kind of scheduling going on inside the cvs server process (aside from blocking for io)? Harold Lynch ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about RCS files
Hello, * On Thu, Aug 26, 2004 at 12:20:14PM +0200 K. Posern wrote: > But I need an exact copy of the version a CLIENT has in its > /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). Have a look at C.3.5.2 of your manual: https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175 HTH, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ http://www.viceteam.org/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about RCS files
> > Hi. > > I am a CVS newbie and I would like to do/have the following: > > On the clients I work with: > CVSROOT=":ext:[EMAIL PROTECTED]:/var/lib/cvs"; > LOCAL="/SOMEWHERE/sv"; > > > CVS update is done by: > cd "/SOMEWHERE/sv"; > cvs -d "$CVSROOT" update -dP; > > CVS commit is done by: > cd "/SOMEWHERE/sv"; > cvs -d "$CVSROOT" commit; cvs -d "$CVSROOT" makes little sense... cvs uses $CVSROOT by default > I describe all this because I dunno if you might need this information to answer me the following question: > > I thought that the CVS-Tree LOCAL and on the SERVER are IDENTICAL (after I did an update). > > But on the server the files end with ",v" and have all the comments and version stuff inside. > > I now know that these files are the rcs files (the backbone of the cvs?). more or less. Never touch the files in $CVSROOT > But I need an exact copy of the version a CLIENT has in its /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). > > How can I achieve this? Do I have to to do an cvs-checkout on the server and cvs-update everytime a client did commit something? > > Or can I say to the server somehow to keep automatically the rcs stuff seperate in one dir and an "client-like-copy" of the cvs-repository in another dir? See "keeping a checked-out copy" https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175 Arno ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about RCS files
"K. Posern" <[EMAIL PROTECTED]> writes: > But I need an exact copy of the version a CLIENT has in its > /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). > > How can I achieve this? Do I have to to do an cvs-checkout on the > server and cvs-update everytime a client did commit something? > > Or can I say to the server somehow to keep automatically the rcs > stuff seperate in one dir and an "client-like-copy" of the > cvs-repository in another dir? CVS doesn't have support for that. You'd have arrange to update any separate checked-out versions on the server yourself using a script. Take a look at the hooks like 'commitinfo' and loginfo' for ways to do that. -- Brian Gough Network Theory Ltd, Publishing the CVS Reference Manual --- http://www.network-theory.co.uk/cvs/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Question about RCS files
Hi. I am a CVS newbie and I would like to do/have the following: There is a Server with an CVS Repository "sv" in the path /var/lib/cvs/sv. On the clients I work with: CVSROOT=":ext:[EMAIL PROTECTED]:/var/lib/cvs"; LOCAL="/SOMEWHERE/sv"; CVS checkout is done by: cd "/SOMEWHERE"; cvs -d "$CVSROOT" checkout sv; CVS update is done by: cd "/SOMEWHERE/sv"; cvs -d "$CVSROOT" update -dP; CVS commit is done by: cd "/SOMEWHERE/sv"; cvs -d "$CVSROOT" commit; I describe all this because I dunno if you might need this information to answer me the following question: I thought that the CVS-Tree LOCAL and on the SERVER are IDENTICAL (after I did an update). But on the server the files end with ",v" and have all the comments and version stuff inside. I now know that these files are the rcs files (the backbone of the cvs?). But I need an exact copy of the version a CLIENT has in its /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). How can I achieve this? Do I have to to do an cvs-checkout on the server and cvs-update everytime a client did commit something? Or can I say to the server somehow to keep automatically the rcs stuff seperate in one dir and an "client-like-copy" of the cvs-repository in another dir? Thanks a lot for any help in advance! Greetings, K. Posern. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Reverting a concrete revision
Hi All, Using i.e "cvs update -j -j file.c", we discard changes from 1.6 to 1.3. Then, commiting, we get revision 1.7 that is exactly the same as 1.3. Now, suppose I want to generate a new revision of "file.c" but containing code from 1.1 to 1.3 + 1.5 and 1.6 revision, because I realise that I don not want the changes made on revision 1.4 but still want all the changes made in 1.5 and 1.6. Doing the previous update, I lost 1.4 changes but also 1.5 and 1.6. So the idea is revert ONLY the changes that were made on 1.4. If the changes of 1.5 and 1.6 are small (or changes of 1.) it can be do it manually but this is not my case. Is there any way to do this in CVS? Thanks in advance Rolo ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
