Re: What is a module?
ps <[EMAIL PROTECTED]> wrote: > Reading the cvs documentation I can't get past the first few lines. > Nowhere can I find the definition for "module". The docs freely start in > referring to modules everywhere, but the term is never exactly defined. Yeah, it's a little ill-defined. Loosely speaking, a module is any part of the tree under $CVSROOT that can be checked out as a unit. For example, immediately after you do your "cvs init" there is a $CVSROOT/CVSROOT subdirectory with cvs administrative files, and you can check it its contents like so: cd some/place/clean cvs checkout CVSROOT In that sense, CVSROOT is a module. After you import a few trees, every top-level directory under $CVSROOT is a module because you can check it out by name. In that same CVSROOT administrative sandbox, you will find a "modules" file. You can edit that file to make other subtrees of your repository accessible by name, like the top-level subtrees. An entry like this, scripts-A projectA/lib/tools/subtools/scripts makes a deep subdirectory available through cvs checkout scripts-A So there is a somewhat more precise definition: a module is anything that has an entry in $CVSROOT/CVSROOT/modules . ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Recover a working copy
Robert D. Young <[EMAIL PROTECTED]> wrote: > When I import, the existing CVS revision info is lost (or appears to be, > with everything at 1.1.1.1). The substitution is done on checkout, not import. If you specify "-ko" on the checkout command line, your working copies will come out with the original strings. Not that it will necessarily do you a lot of good ... You still have only one revision's worth in your repository. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: need to force username of cvs 'action' when using shared SSH account
TG <[EMAIL PROTECTED]> wrote: > Here is the issue: I noticed that the name of the committer for each > file that I committed was unix account id, or the one that is used to > SSH into the cvs machine. Now I have multiple developers(committers) > and ONLY ONE shared shell account on the machine where is CVS is > running. Is there a reason why you can't use the old-fashioned strategem of one account per developer ? > I need to be able to force a unique name for each developer > that CVS will log. > Here is what I've tried so far: > A. In front of each developers public key, I placed: > command="/home/mydomain/bin/setuserscript > theuser",no-port-forwarding,no-pty You can also use $HOME/.ssh/environment on the client side to tunnel environment variables of your choice. I've never tried it myself, I just saw that in the ssh man page. (Your developers would be able to cheat, though.) The trouble is, CVS doesn't look at the environment to decide who's calling. > There HAS to be a way to force cvs to record the correct committer > name. Why ? Why would cvs extract that information from a source other than its own euid ? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: need to force username of cvs 'action' when using shared
Tim Grotenhuis <[EMAIL PROTECTED]> wrote: > I am not allowed to run pserver. Not even on a nonstandard port, tunneled through ssh ? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Fw: need to force username of cvs 'action' when using shared
Larry Jones <[EMAIL PROTECTED]> wrote: > What you're doing (using a single account for everyone) is what is > compromising the tracking. What you're asking for would completely > compromise the tracking since it would allow absolutely anyone to commit > changes whilst claiming to be anyone else they like. Actually, Tim might be able to preseve accountability if he keeps full control of the public keys. Each private key allows one developer to run exactly one command, which sets that developers environment variable and execs "cvs server" (so I guess the developers also need to tweak their CVS_SERVER variable at the client end). But CVS doesn't have an environment variable to fake the userid. Seems that Tim would have to hack CVS and get a copy installed on the colocated server, in his private tree if necessary. After that, he'd better lock down the CVSROOT/ module, otherwise his developers could manipulate the authorized_keys file through loginfo and other hooks. What other holes are there? Is it worth the trouble to chase them down? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: RES: Checking out only files NEWER than given date/revision
Alek Lapuc <[EMAIL PROTECTED]> wrote: > The reason is simple. At the begining of the project we had some > sources and include files supplied "out-of-the-box" with a commercial > product. Than we done some customizations -- some files were added, > some were changed, some were untouched. > The main idea is to filter out the untouched files, so they are > separated from out-of-the-box ones. > The reason for this is that files out-of-the-box can be automatically > patched while patching the whole product with official patch. The > patch is prepared outside to our project. Our changes are not known to > the product vendor, and most propably would be corrupted during such a > patch. But having original and customized files separated, we can > apply the patch and merge it manually to our sources if needed. Tracking third party sources in the presence of local changes is what the 'cvs import' command does. The external sources are usually delivered as tarballs or zip archives, but applying patches will work too. So check out your last import tag, patch it, reimport the result and merge your trunk. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Module weirdness.
Carter Thompson <[EMAIL PROTECTED]> wrote: > I have some really strange problems with my repository. > I have the module "adm" with a subdirectory "ui". I also > have a module named "ui". Both are part of a module alias, > "adm-suite". That is, > == Modules == > adm-suite adm &ui > adm adm > uiui Your $CVSROOT/adm/ui/ collides with the ui/ that the &ui is trying to create. You can't do that. It will *not* give you the union of $CVSROOT/adm/ui/ and $CVSROOT/ui/ . It just breaks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Personal CVS repository?
J Krugman <[EMAIL PROTECTED]> wrote: > For reasons that I'm not too clear on, my supervisor has instructed > me that he must review my code before each submission to the off-site > CVS repository, and he wants to do this once a week. Then you have to play by those rules. There may be intellectual property issues. > My only > problem with this is that, even when I am the only programmer in > a project, I prefer to keep a finer-grained version control than > is possible with weekly submissions to the repository. > It occurs to me, though, that maybe I could set up a "personal" > CVS repository off my home directory Yes, indeed. Create a directory under you $HOME and run 'cvs init'. You'll have to get familiar with 'cvs import' too. Read the docs at http://www.cvshome.org/docs/manual/cvs-1.11.15/cvs_13.html#SEC104 , slowly. The first import is easy, the imports following that are more complicated. In your case, you'll want to keep yourself in sync with commits from external developers. Here's what I would do. 1) Keep a checked-out sandbox from the public repository, preferably from a read-only account so you don't commit by mistake and bypass your weekly review. 2) Import the said sandbox in your own private repository, to the vendor branch. outside-sandbox> cvs -d $CVSROOT import -I! -ICVS \ > path VENDOR import--mm-dd 3) Checkout another sandbox from your private repo. This is the copy you work on. Hack and commit normally. 4) At review time, go to your inside sandbox, and inside-sandbox> cvs commit inside-sandbox> cvs tag review--mm-dd inside-sandbox> cvs diff -N -u -rVENDOR > ../to_review.patch Go over the to_review.patch with your supervisor. If approved, apply the patch to your outside sandbox. Commit from there, using a -d option to switch to the developer account they gave you, with read-write permission. outside-sandbox> cvs -d :ext:blahblah commit Now there is the problem of keeping your outside sandbox up to date (easy) and of propagating those changes to your inside sandbox (takes some gymnastics). At least every morning, outside-sandbox> cvs update outside-sandbox> cvs import -I! -ICVS path VENDOR import--mm-dd-1 That was the import. Now the merge, inside-sandbox> cvs commit inside-sandbox> cvs tag premerge inside-sandbox> cvs update -j -j fix conflicts inside-sandbox> cvs commit inside-sandbox> cvs tag -d premerge The 'premerge' tag is in case something goes wrong with the merge. It represents your last good point before attempting the merge. If the merge is full of conflicts, you can start a branch off of premerge to continue your work while your figure out how to finish the merge. > (although I'll readily admit > that I've never set up a CVS repository of *any* kind before); I > would use it for my "fine-grain" version control, while submitting > new, boss-approved stuff to the "real" off-site repository only > once a week... > My knowledge of CVS is very limited; I know a few commands, and I > never deviate from the most basic functionality. The potentially hard part is all those imports and merges. The bit about setting up your own repository is really trivial. One annoying bit is that when you reimport your fresh commits to the external site, your merge will show spurious conflicts with the same text on both side of the conflict. You'll just have to clean them up. > This "personal" > repository idea is far more "adventurous" than anything I've done > with CVS before. Yes, but it's the perfect thing here. You commit to your private repository at your chosen pace and you generate diffs at review time. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: binary files bad idea? why?
Jim.Hyslop <[EMAIL PROTECTED]> wrote: > Spiro Trikaliotis wrote: >> This is no problem from my experience if the initial check-in was done >> from a Unix (LF-) based system, but it is a problem if it was >> done from >> a DOS (CR/LF-) based system. > There is also a remote possibility that the binary file might _happen_ to > contain what CVS thinks is a keyword, such as $Id$. Chances are pretty slim, > but it _could_ happen. But the $Id$ expansion occurs on checkout. The repository copy itself would still be intact, and problems with the file would be fixed by a "cvs admin -kb". Working copies could be restored with "cvs update". ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and end of line characters
Jo Vermeulen <[EMAIL PROTECTED]> wrote: > Op Wed, 26 May 2004 11:59:46 -0400, schreef Jim.Hyslop: >> - Always modify files on the same platform you used to check them out. > Problem is, the people on my team use Windows, and I use Linux, so were > kind of mixed :-) Don't share the working copies. You check out your copy on Linux, edit it on Linux and commit it from Linux; they check out their copies on Windows, edit them on Windows and commit them from Windows. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: line number to revision
WannaLeanOO <[EMAIL PROTECTED]> wrote: > Is there a command line tool or command that would quickly translate > filename + line number to revision number. cvs annotate ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: listing new files in a local directory
John Hanny <[EMAIL PROTECTED]> wrote: > I'd like a cvs command that tells me what files in the current > directory are new. One hack that I've been using is "cvs update." The > files that are prefixed by '?' are new. Unfortunately, this has the > side-effect of updating my local directory files if they have been > changed in the repository. Use the "-n" flag to turn off the side-effect. cvs -nq update -I! -ICVS | grep \^\\\? ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Project in a cvs, library in another
Ababccc <[EMAIL PROTECTED]> wrote: > I'm wondering what people usually do, in case there is a project on CVS > which uses a C++ library which is in a completely separated CVS. > If the library gets changed (for its own purposes) the project might get > screwed... In cases like that, I equip the client project with a big fat README file that explains how to check out a *specific release* of the library in a subtree. The subtree ends up with a sticky tag and a normal "cvs update" doesn't affect it. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: listing new files in a local directory
Jim.Hyslop <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: >> Use the "-n" flag to turn off the side-effect. >> >> cvs -nq update -I! -ICVS | grep \^\\\? > Why are you suppressing the ignored files? This could give a bunch of > spurious "new" files that you want to ignore. Because that's how I interpreted the OP's question. I figured it would be easier to get a full list and filter the chaff later, rather than to chase files that were missed because they fell in cvs' default ignore list. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Shared Source
Chris Puccio <[EMAIL PROTECTED]> wrote: > I need to be able to have one main "Core Product" code base, then be able to > suck down only certain pieces of that "Core Product" code base, which will be > the framework for another clients product. Possible, with restrictions. Bundle up the shared code in subtrees, so any client product can get shared subtrees grafted under it, rather than pick and select files at random. It forces you to organize your shared code, but that is probably a good thing. Two recommendations: 1) The "Core Product" should probably be a <> like all the others. Its only distinguishing feature would be that it has all the shared subtrees under it. 2) Each shared subtree should be a self-contained entity that you can check out individually. It should have its own test suite, for example. That way you can work on it in isolation and later propagate the changes to the client products. This doesn't preclude you from making the changes you want from a "Core Product" sandbox, it just broadens your options. > I then need to be able to have any > changes made to the "Core Product" be sync'd with any "Child" products that > received code from the "Core Product" code base. The sync would occur every time you run a "cvs update" in a "Child" sandbox. Hmmm, notice how I've been using "client" instead of "Child" ? > If anybody can give me some proper keywords on the CVS term to do this, it > would make googling much easier right now ;) Amperstand modules. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: up-to-date check failed from a lower revision to higher revision
Antony Paul <[EMAIL PROTECTED]> wrote: > I am new to CVS. I am using the cvs command line client in Linux. I have > one file whose status is as follows > cvs status: Examining . > === > File: one.txt Status: Locally Modified >Working revision:1.4.1.3 Sat Jul 10 08:53:39 2004 >Repository revision: 1.4.1.3 /home/cvsuser/cvsroot/work/base/one.txt,v >Sticky Tag: 1.4.1 >Sticky Date: (none) >Sticky Options: (none) It is unconventional to have a numeric sticky tag ... >Existing Tags: > No Tags Exist ... and no symbolic tags. Anyway, > I started with version 1.1. I created a new version using the command > cvs commit -r 1.4.1 one.txt Are you sure that's what you did ? When I try something similar, I get $ cvs commit -r1.4.1 toto.c cvs commit: Up-to-date check failed for `toto.c' cvs [commit aborted]: correct above errors first! It seems that you started with revision 1.4, not 1.1 as you said. Either that, or the revision 1.4.1.3 in your status output is wrong. It looks like you cut'n pasted the output of cvs status, so I'll assume that 1.4.1.3 is correct and that your initial 1.1 was really 1.4 . > Then I modified the file and committed several time using cvs commit one.txt That part works. > Now it is in revision 1.4.1.3. The error occurred when I committed with > the following command > cvs commit -r 1.5 -m '1.5' one.txt > What is wrong with it. I am the only person who works with this file and > repository. I tried cvs update -C one.txt. Still it is giving error. To finish off and make revision 1.5, commit one last time to the branch, return to the trunk and merge your branch. cvs commit # creates rev 1.4.1.4 cvs update -A one.txt # returns to rev 1.4 and removes the changes cvs update -j 1.4.1 one.txt # pulls in the changes cvs status -v one.txt The status should look something like this: File: one.txt Status: Locally Modified Working revision:1.4 Result of merge Repository revision: 1.4 /home/cvsuser/cvsroot/work/base/one.txt,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: No Tags Exist The file contents will be that of revision 1.4.1.4, as if you had checked out a fresh copy of 1.4 and manually edited 1.4.1.4 into it. Hence the status of "Locally Modified". Just commit the result. cvs commit # creates rev 1.5 . ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Multi-tier development CVS plan
adp <[EMAIL PROTECTED]> wrote: > Did you get a response on this? We are looking to move from a single CVS > branch (MAIN) to either a two- or three-tiered system. Would be happy with > hints. > We are thinking of this: > unstable -> stable -> release The usual way to handle this on CVS is an unstable trunk with stable+release branches. ++unstable> \\ \stable1-|-| \ rel-1.1 rel-1.2 \ \---stable2---|-> rel-2.1 Every time your unstable trunk reaches a milestone, you cut a stabilization branch. On this branch you perform only cleanups and add no new features. Eventually you tag your stabilization branch and cut a release, after which the branch becomes a bugfix branch. Promoting a new batch of changes from "unstable" to "stable" is done by starting a new stable branch. Not shown on the diagram is how the bugfixes from maintained release branches would be merged to later releases and to the trunk, but that's standard CVS fare. You *might* make the original promotion model work in CVS with floating tags: cvs tag -F -r1.6 STABLE toto.c --oops no, cvs tag -F -r1.5 STABLE toto.c etc. You could then check out with the -rSTABLE flag to get an official "stable" tree without the unstable riff-raff. That said, I don't understand the promotion model well enough to give you sound advice. To recap: > unstable: > This is where our current development goes. The trunk, also the default. > stable: > This is where we merge our soon-to-be-released code so that QA can begin > work. You don't really "merge" in the CVS sense, instead you fork a branch to isolate changes on it from the unstable trunk. > release: > This is where we merge from stable, tag an official code release, and then > push the release. You could branch the stable branch, but ususually it's easier to just tag milestones on it. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Setting up a new CVSNT or Linux server ??
Frederic Brehm <[EMAIL PROTECTED]> wrote: > [ case-sensitive client with case-insensitive server] > In your scenario, it appears to me that the only failure comes with the > CVSNT server and UNIX client. In that case, the user knows that there are > two separate files "file" and "File" in the directory and CVS should be > able to add both but it refuses. But allowing the add would be worse for the developers on case-insensitive clients. For them, the next update would yield endless messages to "move File, it is in the way". ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Import question
Lemke, Michael IZ/HZA-IOP <[EMAIL PROTECTED]> wrote: > When I do a cvs import of a new vendor version the new files become the > head revision. I'd like to do the import such that it doesn't affect HEAD. > Only after I've tested the new stuff I want it to become HEAD. Of course, > it should work with local changes merged in just like the standard way of > doing it on the trunk. How can I do this? There is no way to avoid that. Your trunk is broken between the time you do the import and when you merge the import back to the trunk. To mitigate the problem, you should tag your trunk before you do the import. If the post-import merge gives you trouble, you can at least start a branch off your pre-import tag so you can continue your work in another sandbox while you sort things out. When you finally merge the import, you go on to merge the temporary branch. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: ***glaring*** flaw in cvs import?
Robert P. J. Day <[EMAIL PROTECTED]> wrote: >following the instructions in "tracking third-party sources", i > downloaded a kernel source tree that i both want to update regularly > from the source, and make local changes to. >i pulled down the tree, cleared out all CVS directories to turn it > into a regular directory tree, then used "cvs import" to check it into > my local repo. Ok, so you checked out a tree from a public CVS server and you want to import that locally. You don't have to remove the CVS/ subdirectories. See below. >in the process of doing that import, the "cvs" command apparently > decided it didn't much care for the kernel source directory > net/bridge/core, and threw it away! why? because it's called "core"? Because 'core' is in the default ignore list. I usually reset the ignore list to just 'CVS', like this, cvs import -I! -ICVS VENDOR and then check out a fresh sandbox somewhere else. You can keep the original external sandbox untouched; that way, you can update it from the public CVS server and reimport any deltas to your internal server. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Get the list of all modules of a given repository
Miguel Lopez <[EMAIL PROTECTED]> wrote: > is there a cvs command that allows to retrieve all the modules of a > given repository? If you mean "the list of modules defined in the CVSROOT/modules file", then cvs checkout -c -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: any CVS clients, with a good user interface
shivraman giri <[EMAIL PROTECTED]> wrote: > I have my repositories in UNIX. > I m working on a machine with windows XP installed. > Is there a good CVS client, preferably a freeware, trial version > or a GNU product that gives a graphical user interface for running > CVS commands. http://www.tortoisecvs.org/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Permissions
Gaurav Vaish <[EMAIL PROTECTED]> wrote: > I am using pserver to connect and more often than not, I get the > error - "Unable to create #cvs.lock, Permission denied". > The reason is that a module or a subdirectory thereof will be > created by the permission set of the permission who created it. Though > the directory permissions are 775 and all the users are in the group > "cvs", but still the problem persists. I'm lost. 775 is the correct permission. Are you saying all the directories have that permission and you still have problems ? If subdirectories are being created with more restrictive permissions, it means that you forgot to turn on the setgid bit in their parent's permissions. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Aliasing the trunk with a branch tag
Keith Refson <[EMAIL PROTECTED]> wrote: > 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. > [ ... ] > 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 > [ ... ] > 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. It should be ok, but I'm always weary of long-lived branches. After a while you might want to re-graft your branch higher up on the trunk (for the files that do change). If you don't see what I mean, do an advanced search on groups.google.com for Message-Id "[EMAIL PROTECTED]" . -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How make cvs import
pierre <[EMAIL PROTECTED]> wrote: > Hi I want to use CVS for my project, olso I make and cvs init an cvs > import for the first init. > My problem is that I must be root for make a checkout, and all the files > are owned root. I must change the owner for edit them. > How make and cvs import in not administrateur login ? Hmmm, "root" sounds like Unix and "administrateur" sounds like Windows... Assuming a Unix-oid box below. You must have done the init and the import as root. If you have only one normal user, just change the ownership of your $CVSROOT tree to him, recursively. If you have many users, create a "cvs" group and put all your users in that group; for symmetry, create also a *user* "cvs" and put him in the cvs group; change the ownership of all *directories* in the $CVSROOT tree to user cvs, group cvs, and change the *directory* permissions to 02775 (owner rwx, group rwx, other r-x and setgid). The file permissions are probably 0444 and can stay that way. It's the directory permissions that matter most. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Checkout./export a copy to /var/www
Anand Graves <[EMAIL PROTECTED]> wrote: > I use WinCVS to checkout a copy on my PC. When I do a commit, the file > checks in a linux server. I would like a committed file to be checked > out/copied/exported to /var/www/myproject. > When I search for this, I keep finding this (for the loginfo file): > ^cyclic-pages (date; cat; (sleep 2; cd /u/www/local-docs; > cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1 > But this will update the checked out tree in `/u/www/local-docs' and my > checked out tree is on a windows PC. The checked-out tree is on Windows and the cvs repository is on a Linux box, but where is /var/www ? That sounds like Linux too. If your web server is also your cvs server, just change the "/u/www/local-docs" in the example to "/var/www/myproject" and you're done. The commit on Windows triggers the loginfo on the Linux server, which triggers the update on the Linux server. If the web server is another box, you need to make loginfo trigger an update *from the web server*. If the web server is Linux (/var/www ?) the standard solution is ssh, which when properly setup allows someone on the cvs server to run commands on the web server. If the web server is on Windows... well, I'd install Cygwin (http://www.cygwin.com) and still use ssh but that's just me. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question
Gleidson S? Barreto <[EMAIL PROTECTED]> wrote: > 1-To take place the transfer of the files stored in > the repository q they were modified for your work > area, through a sicroniza??o operation. Like this, > would to be in fact that sicroniza??o operation? I'm not sure what you mean, but... Synchronization in both direction has to be requested explicitly, by running a command. "cvs update" to receive changes made by others, and "cvs commit" to send changes made by you. > 2-CVS counts with a mechanism capable to control the > simultaneous accesses and the parallel modifications, > guaranteeing like this the integrity of the > modifications and atomicity of the operations. Would > be in fact that atomicity of operations? If I remember correctly, commits are atomic within any one directory but are not atomic across entire hierarchies. Commits are certainly atomic on a file by file basis, so you do not get corrupted files. The lack of atomicity occurs when a developers performs an update (receive) while another developer performs a commit (send). The receiving developer may get an inconsistent snapshot with some files just before their commit and some other files just after the commit. The workaround is to repeat the update. It would be a little difficult to notice in practice, because when working on an active project one has to update many times every day. Also, the trunk tends to be somewhat unstable since it is being actively modified. > 3-CVS possesses mechanism capable to identify and to > solve conflicts. However those identified conflicts > are merely textual, not existing any analysis of the > logical consistence. Here I didn't understand the > expression textual conflicts very well. A "textual" conflict occurs when two people modified lines at overlapping locations in a file, or at nearly overlapping locations (~3 lines apart or so). These conflicts have to be resolved manually. Modifications in distant parts of the file are accepted uncritically. You are correct that this could introduce logical errors in the merged file; the amazing thing is that it almost never does, because of the way people write software. In any case, cvs always gives you backup copies of the two conflicting versions of the file. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merging Issues
Dhruva B. Reddy <[EMAIL PROTECTED]> wrote: > We are doing development on a branch which has been around for a while, > and I was required to merge in changes from the trunk a few times. > The first time I did this, I did the following (in a sandbox from the > branch): > cvs up -j HEAD > and then applied a tag as recommended by the documentation. This merge > went as expected (changes made on the trunk were now available in the > branch, along with the changes checked into the branch). > A few days ago I merged changes from the trunk again. I could have > sworn I did it like this (again, in a sandbox from the branch): > cvs up -j -j HEAD > This resulted in the loss of *all* changes made on the branch (i.e., > they were overridden by the versions on the trunk). > Can anyone tell me what could have caused this (what kind of human > error, etc.) and how to prevent from happening again? My guess: when you planted the you tagged the branch by mistake, instead of tagging the trunk. That would explain why the second merge undoes all the branch work. Workaround: don't commit this sandbox where you attempted this second merge, just delete it and start over. Now go back to the trunk and create a new branch. Get on the new branch. Merge the changes on the old branch, cvs update -r cvs update \ -j <1st-branch-branchpoint> \ -j and go fix the conflicts. You have to expect vacuous conflicts, because many changes between <1st-branch-branchpoint> and the tip of the old branch are also present on the trunk. The conflicting text will be the same on both sides, so just pick one. Sometimes cvs (diff3, really) manages to get it right but as a rule you have to expect spurious conflicts. Well, fix them, that's the price you'll have to pay. Commit the new branch, and abandon the old branch. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
Ones Self <[EMAIL PROTECTED]> wrote: > I'm running a CVS server which compiles and tests the current > files in CVS every hour. I would like to make new checkins > available _only_ if they compile and pass the tests. > So, if a user checks in something which does not compile, for > example, other users who check out at that time will not get > the new version until the problem is fixed. Everytime you > do an update, you know you're getting a clean version of the > source; one that compiles, and in which the tests pass. I don't think you can do that. Well, you could trigger a full recompile from commitinfo and allow the commit only if the build succeeds, but your commits would be a bit sluggish that way. What you *could* do is trigger the build from loginfo (post-commit) and update a moving tag if the build is successful. That way your trunk can contain garbage, but the last successfully built commit will have an unambiguous marker on it. Your users can choose the unstable tip, cvs checkout foo or the last known good version, cvs checkout -rLAST_GOOD foo but in the latter case they won't be able to commit changes. (Well, they could start a branch, but that's taking us off-topic.) The loginfo trigger would be asynchronous, as in https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175 and there would be negligible delay to a commit. Simple question: why can't the developers do a top-level "make test" before committing, and sidestep the question ? Or do the unit tests take that long to run ? If the latter, you'll have to guard your build-test-retag script against multiple instances of itself. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
Maarten de Boer <[EMAIL PROTECTED]> wrote: > > What you *could* do is trigger the build from loginfo (post-commit) > > and update a moving tag if the build is successful. > > [ ... ] > But why would you to that from the loginfo? Wouldn't it be easier to > have that tag moved by a virtual user, the dedicated test build machine, > which is building and testing in a loop, everytime the compilation is > correct? Hm, my language was ambiguous. What the loginfo would trigger is one script, running on the test machine, that updates the test sandbox, builds, runs the tests, and finally moves the tag if the tests pass. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Using moving tags
Yamuna Ramasubramaniyan <[EMAIL PROTECTED]> wrote: > I have a question about using moving tags. You tag > the repository with LAST_GOOD today. Someone removes > a file. This file still contains the LAST_GOOD tag. > The next person checking out the module with the > LAST_GOOD tag will get this deleted file. Do you use > a commitinfo trigger to remove the moving tag from the > deleted file? Are there any other ways to handle this > case? D'oh. I hadn't thought of that. Maybe the tag mover could look for files that are 1) dead on the trunk, 2) not added on a branch, 3) still have the tag; and then remove the tag from those files. Not so easy to do from a sandbox from which the file has been removed. Well, it wasn't my requirement so I'm still ok ;-) -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
Robin Rosenberg <[EMAIL PROTECTED]@dewire.kom> wrote: > Pierre Asselin wrote: > > Hm, my language was ambiguous. What the loginfo would trigger is > > one script, running on the test machine, that updates the test sandbox, > > builds, runs the tests, and finally moves the tag if the tests pass. > Trigging rebuilds for every commit is insane. Well, the OP wanted to trigger a test build in the pre-commit check. I was proposing a less heavy-handed solution. Not that it's entirely free of "gatchas". > [ sane process elided ] -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Using moving tags
Doug Lee <[EMAIL PROTECTED]> wrote: > Er...now maybe I'm the one missing something. I don't see the > problem: > Say the LastGood tag was applied on Monday. Tuesday someone removes > a file and commits that, but LastGood is not moved yet. But the tag *is* moved, if the testing robot succeeds with its post-commit build. If it weren't for deleted files, the robot could be just this: #! /bin/sh cd /the/reference/sandbox cvs update make test && cvs update -F LastGood If files are removed, that's not enough. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: setting up branch with code changes already in it
Royce <[EMAIL PROTECTED]> wrote: > (from top directory within tree) > cvs tag v2_0_unstable_root > cvs tag -b -r v2_0_unstable_root v2_0_unstable followed by cvs update -r v2_0_unstable > I have not checked in the files because I wanted to be sure they will > check into the branch. How can I verify the code will check into the > branch? I'd do a 'cvs status | less' and make sure every file has the sticky tag. Maybe also 'cvs -nt commit' (-n to block the actual commit, -t for a trace of what would happen), but I'm not sure that will show you what revision numbers would be used by a real commit. > cvs log doesn't seem to show that info. I read somewhere that > the branch gets created on commit - is that true? Yes, if you really commit to the new branch. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: DOS Command to get current branch?
Talos <[EMAIL PROTECTED]> wrote: > My question is: Is there a DOS command that let's you know what > branch name the sandbox you're currently is? Run "cvs status " and look for any "sticky tag" listed in the output. If your sandbox is on the branch, you'll see your branch name there. If you're on the trunk, it will be empty. Of course that only checks the one file, not the entire sandbox, but if you only tag and branch entire projects it's a good sanity check. (This assumes that you have cvs or cvsnt installed somewhere on your path as "cvs.exe'.) -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merging question - from and to
Jeeva Sarma <[EMAIL PROTECTED]> wrote: > I have a file soa.pc, branched out at 1.2, now at > revision 1.2.4.1 on branch, and 1.2 on trunk. I > check-out from trunk, then do > [ ... ] > cvs update -j 1.2 -j 1.2.4.1 soa.pc Yes, like that. The command means, merge all changes that occurred between 1.2 and 1.2.4.1 into the working copy, which is what you want. What is confusing you is that there are *three* revisions involved: the base of the changes to merge, here 1.2, the endpoint of the changes to merge, here 1.2.4.1, and the working copy, which doesn't need to be called out by revision because it is the file sitting in your sandbox at the moment. In your case, the working copy is identical to the base, but this isn't always true. > RCS file: > /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v > retrieving revision 1.2 > retrieving revision 1.2.4.1 > Merging differences between 1.2 and 1.2.4.1 into > soa.pc After which the soa.pc in your sandbox should be identical to 1.2.4.1, but once again this was a special case because your starting point was identical to 1.2 . > cvs update -j HEAD soa.pc > RCS file: > /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v > retrieving revision 1.2 > retrieving revision 1.3 > Merging differences between 1.2 and 1.3 into soa.pc If you omit the first "-j", it defaults to the most recent common ancestor of the given "-j" and of the working copy. Here HEAD means 1.3, because you or someone else committed changes after you checked out the sandbox with 1.2 . The common ancestor of 1.3 and 1.2 is 1.2 so once again you end up with a special case where the base and the working revision are identical. You are grabbing the changes from 1.2 to 1.3 and injecting them in 1.2, the result being identical to 1.3 . BTW, if you lose track you can always do rm soa.pc cvs update soa.pc to get a clean copy of the HEAD of the moment. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: history of version changes
Saad Sheikh <[EMAIL PROTECTED]> wrote: > I am a new to CVS. I wanted to know if there is a command that will > list all the versions of a project. There is a perl script, "cvs2cl.pl", that consolidates the log messages of a sandbox in chronological order. Try Google. > I wanted a history of versions of the project AND the files that have > changes from one version to the next, like the history command in VSS. >From the VSS comment I infer that you're on Windows. If cvs2cl is the right solution you'll have to install perl first, either by Cygwin or from www.activestate.com . It can get messy. I always find it painful to integrate new tools into Windows "integrated" environment ... Different culture, partly. For what it's worth, I run cvs2cl.pl from Cygwin all the time. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: how to check out a project which contains modules from different branches
Li Chou <[EMAIL PROTECTED]> wrote: > Hi, I tried to figure out a single step of check out a project that > contains modules from different branches of different project. > For example, Project X has 3 modules, A and B which are from other > projects. I need to check out module A's of Project Y branch_2.5, > and module B of Project Z's main trunk. If they both were in the > main trunk, I know I could add "X C &A &B" in modules file. Now > how do I check out them both at the same time? is it possible? > Thanks Would a two-step process work for you ? Recently I've been thinking about a "wrapper" project. Something that would work thus: $ cvs checkout X-wrapper U X-wrapper/README U X-wrapper/checkout.sh and the README file would say: Run "sh checkout.sh" to get the rest of the tree. Bye. The checkout.sh script would contain these commands, cvs checkout C cvs checkout -r branch_2-5 A cvs checkout B and by running it you would get the correct revision of each subtree. The script is rev-controlled, so it can track changes in branch tags when subprojects get merged to their trunks. I guess this sort of thing (programmability) comes more naturally in *nix. Bah, even Windows lets you write a checkout.bat, so it will work there too. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: keyword for branch-name?
"Voigt, Ulrich" <[EMAIL PROTECTED]> writes: >Is there a keyword for the branch-name of the currently checked out file? I >want to use it in a version file, in which I have to print the branch name. The closest thing is $Name$, but 1) It expands only release tags, not branch tags. 2) The expansion occurs on checkout -rTAG or export -rTAG, but not on update -rTAG. This is from memory, I may be wrong. If you need the branch information, you'll need to extract it in a build script using cvs status. And that will only work from a checked-out sandbox, not an exported tree. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Vendor Tag & Release Tag
eric07 <[EMAIL PROTECTED]> writes: >What are these used for. Using WinCVS and when importing there is a >Initial vencor and release tags section >with Vendor tag: avendor ( this is the default value ) >Release tag: arelease ( this is the default value ) >what do they mean as far as usage? The vendor tag is cruft. Normally there is only one vendor branch (1.1.1) and the vendor tag just refers to it. Pick some string that you'll never forget and use that. `avendor' is fine. The release tags *are* important. Pick something that describes the distribution you are importing, e.g. `psutils_1_16' or `Mesa_3_4'. When you import a new release, use an appropriate successor tag, e.g. `psutils_1_17'. If you made local changes, you will need these release tags to merge them into the new release. See the manual. If you are importing *your* sources, make up some release tag. You will probably never use import again so the release tag isn't too important. Just pretend. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ye olde issue of symlinks
Simon Perreault <[EMAIL PROTECTED]> writes: >We are programming a WWW administration interface (think Webmin), and so >there are project files scattered all over the test machine's filesystem. >What we do is that every programmer has its own development machine (be it >VMware or physical) and mounts every partition using NFS. Then we have our >personal ~/cvs directory which contains tons of symlinks to files and >directories on the NFS-mounted partitions. You are trying to share ,v files across multiple repositories using symbolic links and NFS mounts? Be glad it doesn't work! If it did, you would soon corrupt your repositories due to missed locks, not to mention NFS bugs. You're also trying to manage entire filesystems with CVS, and that doesn't work well. What you need: 1) A central repository, accessed through pserver or ext, *not* NFS mounts. 2) Sandboxes for each developer. 3) A simple `make install' step that copies files from the sandbox to all over the development machine's filesystem. Your approach was common with RCS, but CVS is different. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS & a Web site
Jason Purdy <[EMAIL PROTECTED]> writes: >What is a good scheme of automating synchronization between a CVS repository >and a Web site >[...] >2) Create 'trigger' scripts which would be triggered when the developer >'commit'ed their changes, which would also affect the changes on the Web site >directories. Yes, like that. It's documented in the manual. Try searching for "Keeping a checked out copy". You could tweak the approach therein to keep an exported copy instead. Also, it would be a *really, really good idea* to run multiple copies of the web server, one for each developer sandbox, each running on a private high-numbered port. That way, the developers can browse and debug their sandboxes before committing. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Identifying the head revisions currently in main
"Sherman Tse" <[EMAIL PROTECTED]> writes: >I'd like to do an rdiff between one of my branches in the cvs and the head >revisions in the main trunk. Is there a way to do that? If your trunk revisions are all of the form 1.x , the trunk is effectively a "branch" with branch number "1". So, $ cvs diff -r1 You can also try $ cvs diff -rHEAD but I'm not sure of the exact semantics if your sandbox is on a branch... -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Forcing the date on a check-in
[EMAIL PROTECTED] (Paul DeWolf) writes: >I'm in the process of moving from SourceSafe to CVS, and I'm writing a >Python script to convert from one to the other. (The website with the >vss2cvs Perl script seems to not be available anymore). >I want to keep the old dates of the file versions, so I want to be >able to commit a version to CVS, explicitly setting the date/time >instead of using the current date and time. >Is there a way to do this? If you're willing to build the ,v files with RCS commands instead of cvs calls, the ci(1) command has a -d option that would do what you want. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Sharing
"Jason Mowat" <[EMAIL PROTECTED]> writes: >I would like to know if this is one area that = >CVS can do (VSS can do it): sharing. In Visual Source Safe, you can = >share a single file among projects. When the shared "centralized" file = >changes, it changes in all the projects. When the shared file in a = >project changes, it changes all related files in other projects by = >updating the centralized copy. You can do that in CVS, if you are willing to share entire directories or directory trees as opposed to isolated files. Use submodules ("amperstand modules") in the modules file. You may need to reorganize your source tree to avoid mixing shared and non-shared files. In any one directory of a checked-out sandbox, all the files must originate from a single directory in the repository. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How do you work out "automatically" the set of branches and the latest version of each branch within a CVS project ?
"James Ball" <[EMAIL PROTECTED]> writes: >I need to work out the set of branches within a given project, and the >latest "version" expressed by the latest TAG for each branch within a >project. From what I've read there doesn't seem to be any obvious way >to do this, which is puzzling given knowing what code you've got is >normally a given, or at least essential. Yeah, isn't that a bummer! >From a checked-out sandbox you can do a `cvs status -v README' (substitute a random existing file for README) to list all the tags and branches *on that one file*. It's generally a bad idea to branch individual files, so hopefully the list applies to the entire project. Without a sandbox, I think you need a shell account on the machine that holds the repository. You do a plain RCS "rlog README,v" and extract the branch list form the output. To the list: does cvsweb provide a solution to James' problem? -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to import with some binary files?
"Chris Bailey" <[EMAIL PROTECTED]> writes: >I have a bunch of files I want to add to add to a new CVS module. The >problem is that some of the files are binary, and some that are binary >don't have file extensions (this is on Linux, with CVS 1.11) Is it third-party source, or is it your source tree and you're only using import for convenience? If it's your source tree, you could move the binaries out of the way, do the import, check out a sandbox, copy the binaries into the sandbox, and cvs add them with the -kb option. If this is really a third-party source tree, you could import from Linux and manually do an `rcs -kb' on the repository files (assuming you have a shell account on the cvs server). You could even check out a sandbox on Linux and do a cvs admin -kb form there. >[...] But, I've added plenty of .gif files to our repository >with just a straight "cvs add file.gif", and it works fine. Our >cvswrappers file does not have anything in it right now. How is this >working? The -kb does two things: 1) turn off line-ending conversions; 2) turn off the expansion of RCS keywords. If you only work on Linux, (1) is a no-op anyway. Your .gif files must not contain any byte sequences that look like RCS keywords, so (2) hasn't triggered yet. But it could happen. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Deadlocking sandbox?
Suppose I have this in my modules file: common path/to/common/files project_A path/to/A &common project_B path/to/B &common So far, so good. I just have two projects, A and B, that share a common subtree through the amperstand module "common". Completely normal. But what if I add this? gotcha &project_A &project_B A checked-out copy of "gotcha" will have two independent copies of the "common" subtree. My question: Can I do a "cvs commit" from the top of "gotcha" ? It seems that CVS will want to acquire two write locks on the "common" tree in the repository and irremediably deadlock itself. Is that correct, or is CVS smart enough to recognize the first lock as its own? (I'm assuming that I'll be able to check out "gotcha" in the first place, but that only seems to involve multiple *read* locks, so it should be OK.) To those who say "If you do that, you deserve whatever happens to you" I reply "I agree". But I have a case where such a sandbox would actually be useful. I would want to update from the top of "gotcha", but not do anything that requires write locks. Any advice? Maybe I'll try it on a test repository. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: what's the strategy for managing mostly common code with a few project specific files?
"HEILES,KATRINA (HP-Vancouver,ex1)" <[EMAIL PROTECTED]> writes: > I have a set of code that is used by several projects. Most of > the code is common, but some are project specific/configuration > files. What's the best way to manage this? Orgarnize each project so that the common files are segregated to a single directory (or directory tree). Then set up your modules file like this: common path/to/the/common/subtree proj_A path/to/project_A &common proj_B path/to/project_b &common ... When you check out module "proj_A", your sandbox will look like this: proj_A/ files... directories.../ more_files... common/ the common subtree... > I'm envisioning that each project will pull the common code from > a labelled version of the trunk. I generally put a big README file at the top of proj_A that says something like this: This project needs revision 1.4 of the common subtree. Before building, execute the command $ cvs update -rREV_1_4 common This README file is under revision control like the rest, and you update it when you port to a higher rev of common/ . Note that you won't be able to commit changes to common/ from the proj_A sandbox, which may be a good thing. The common/ subtree had better be mature and stable, or you'll soon be in trouble. Also, it helps a lot if you can check out, build and regression-test the common/ submodule by itself, without any files from an enclosing projet. CVS will let you check out common by itself. > Does it makes sense to have the project specific files specified > differently in a modules file? I'd like projects to be able to pull > from the same label but still have the ability to have a few files > not come from that label. I'm not sure what your first question means, but if you mix tags you do so at your own risk. You may find yourself unable to rebuild proj_A because you forgot what exact combination you were using under common/ . -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Log INFO
"Alex Flores" <[EMAIL PROTECTED]> writes: >How would I see the "cvs log" info for a file from one tagged version to >the next. I am trying to find bug defects fixed between loads. $ cvs log -r: Also, you should *really* look at rcs2log , in the contrib directory, or at cvs2cl.pl, at http://www.red-bean.com/cvs2cl/ . -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: tag aborted - cannot rename file
Mike House <[EMAIL PROTECTED]> writes: >cvs.exe [tag aborted]: cannot rename file >c:/files/cvsroot/sys5/swim/man/,HELP_14.DOC, >to c:/files/cvsroot/sys5/swim/man/HELP_14.DOC,v: File exists >Ideas what I can look for? >TIA, >Mike Maybe variant spellings of HELP_14.DOC in your repository/sandbox/ CVS/Entries file, where the spelling differs in case only. (Not likely, though.) -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Branching from Working Directory
[EMAIL PROTECTED] writes: >I would like to create a branch based on my current working directory. >Well the problem is that the current working dir contains a lot of >locally modified files. I dont want them to be reflected in the main >trunk but only in the new branch. I just answered that on comp.software.config-mgmt ! Anyway, no problem. $ cvs tag my_branch_bp $ cvs tag -b my_branch $ cvs update -rmy_branch $ cvs commit hack, hack, hack... $ cvs commit hack, hack... -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Using Common files across multiple projects
[EMAIL PROTECTED] (Thomas Frasher) writes: >I'm trying to change the repository that we are using here. >There are several projects that use some of the same files, headers and .cpp >files. >[...] >I'm confused reading the documentation, it seems the ampersan commands are >what is needed here, but I haven't been able to figure out how they work. Amperstand modules are exactly what you need. >Ideally I would like the checkout to get the files automatically, whether >they are in a different repository (i.e. a different module) or whether they >are local. You can only mix files at the granularity of a directory. You *can not* have one directory populated by files from two different modules. It's generally not too hard to structure your sources that way but if you can't, you have to give up on CVS. The simplest example would have a modules file looking like this: common path/to/common/files project_1 path/to/top/of/project_1 &common project_2 path/to/top/of/project_2 &common ... When you check out project_1, you get: project_1/ file file ... common/ common-file common-file ... > Also I need to put them back to the "home" repository when the > changes are committed (all this without the need to commit me at > the end of it). Check. When you commit project_1, the common/ subtree is committed with it and people working on project_2 have to update. Be careful that changes to project_1/common not break project_2 ! -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: branch-naming
"Gianni Mariani" <[EMAIL PROTECTED]> writes: >If you go to the repository and run this : >You probably should back up your repository before doing this ... > rcs -nNEWTAG:OLDTAG (on every RCS file that contains OLDTAG) >then this will create an alias (NEWTAG) for you. If this works, you can save yourself some trouble by using cvs admin. It will run the rcs command on all the files for you. However, I suspect that the above command will only make NEWTAG a synonym for the *tip* of branch OLDTAG. If that's true, your only recourse is to edit the ,v files ! Use a sed or perl script. Double-backup that repository ! -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS commitinfo trigger question
"Bill Buie" <[EMAIL PROTECTED]> writes: >I want to use a commitinfo trigger that will require a script of my = >design to complete with zero status before permitting checkins to = >certain branches. The most obvious way to tell what branch a file is = >being committed to would be with the cvs status subcommand, but I have = >run into a catch. The cvs commit subcommand locks the repository such = >that the commitinfo script hangs when it tried to invoke the cvs status = >subcommand. You can use "cvs -n status" to get the info despite the lock. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: removing from rep.
"Michael L. Hostbaek" <[EMAIL PROTECTED]> writes: >What would happen, if I went and just did a cvs import >some_module_that_exists in a devel dir ? It would add your file tree to the tip of the vendor branch. You will then need to perform a merge on the trunk. Something like $ cd some/where/clean $ cvs checkout -j -j $ cd fix conflicts $ cvs commit This is in the manual, under "Tracking sources". -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Reporting
[EMAIL PROTECTED] (Guy Scharf) writes: >I need to produce a report of all files in a repository updated within >some date range. I want the report to include any log comments on >changes made during that period. http://www.red-bean.com/cvs2cl -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Changing branch name
"Casey T. Zednick" <[EMAIL PROTECTED]> writes: >I named a branch dev1-00, but I meant to name it dev0-11. I have already >merged the branch back into the trunk, but have a back up of the cvs-root >before I did the merge. This is actually in the FAQ at www.cvshome.com . From the top of your sandbox, $ cvs admin -ndev0-11:dev1-00 $ cvs tag -d dev1-00 You might want to cvs status a few files to make sure the dev0-11 is there before you delete dev1-00. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: tagging problem
Sangeetha Parthasarathy <[EMAIL PROTECTED]> writes: The "tag" command works from a checked-out sandbox. The "rtag" command works from anywhere, but it requires 1) a date or existing tag, to know what revisions to tag 2) a tag name 3) a module name, to know what files to tag. >cvs rtag -n -r versionNumberOne SManager ^^ ^^ revision name module name? >But it won't work. I tried the same without the -n option. It still >would not work. The -n option only stops the program specified with -t in the modules file from running --if there is one. It has nothing to do with your problem. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Administrative database file protection problem
Dustin Cavanaugh <[EMAIL PROTECTED]> writes: >My repository is on unix (Sun); the owner is "cvs" and the group is "cvs". >Whenever a user changes one of the Administrative database files, cvs >complains of Permission denied. Users (developers) are members of the cvs >group (though its not their primary group). >I notice that when the database is rebuilt (either by commit or init), all >the database file protections are reset to -r--r--r--. I then su to cvs, do >a cvs init, and then manually reset the protections to -rw-rw-r--. What about the directory permissions? They should be group-rwx, group cvs and preferably setgid (so that directories created under them inherit the group ownership). The file permissions will revert to r--r--r-- but that doesn't matter: committing creates new files and unlinks the old. What's required is the write (and execute) permission to the *directories*. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How can we maintain modules/directories/files between production and development environment using CVS
"Datla, Raghav" <[EMAIL PROTECTED]> writes: >Hi, > As a CVS administrator, How can we maintain modules/directories/files >when we have environments like production, stage and Development. >I mean once Developers develop some code, test it and then I want to keep >these files or code in the production cycle after testing is done. One way is to do the development on the trunk, i.e. normal CVS == development tree. When the code does to staging, that's a release and it needs to be tagged. At the same time, create a bugfix branch starting at the staging tag. $ cvs tag STAGE_4_0 $ cvs tag -b STAGE_4_0_bugfix Then go off and check out a tree on the bugfix branch. That's your staging tree. It is initially identical to what you just tagged on the trunk, because the bugfix branch is empty. If you find bugs, they will be committed to the bugfix branch. $ cvs checkout -rSTAGE_4_0_bugfix project (Start qa work.) When the code goes from staging to production, that's another release and you tag it again (while still on the bugfix branch). Then you go elsewhere and check out or export with the production tag to get your production tree. $ cvs tag -rPROD_4_0_0 $ cd /production/area $ cvs export -rPROD_4_0_0 project You may or may not want to start a production-bugfix branch off of the production tag. It's easier not to, and it wouldn't do you any good if the production trees are exported. Just do all your bug fixes on the staging tree and re-tag, re-export to production. Finally, merge the bugfix branch to the trunk periodically $ cd /your/old/development/tree $ cvs update -jSTAGE_4_0 -jPROD_4_0_0 (fix conflicts) $ cvs commit $ cvs tag -F -rPROD_4_0_0 STAGE_4_0_MERGED The last command plants a "moving tag" (-F option) at the point you just merged. If you fix 3 more bugs and rachet up to PROD_4_0_3, you can merge the new bugfixes from where you left off, then move the tag. $ cvs update -jSTAGE_4_0_MERGED -jPROD_4_0_3 (fix conflicts) $ cvs commit $ cvs tag -F -rPROD_4_0_3 STAGE_4_0_MERGED IMPORTANT: Resist the urge to merge cool new features from development to staging and production. Branches are much easier to handle if the merges are unidirectional. If the development tree is that good, start over with STAGE_4_1. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs merge crash !!
"Zanabria, Moises" <[EMAIL PROTECTED]> writes: >That does mean that is no way to check a merge before I really want to >merge?? Yes there is. The merge isn't really over until you commit the result. The entire process looks like this: 1) Check out a *clean* copy from the tip of the trunk. After the check-out, all the files in the local copy have a status of "up to date". 2) Do the merge, with "cvs update -jbranch_start -jbranch_end" . This changes some of the files in the local copy, they now have a status of "locally modified". Some of them have conflict markers and some don't; nevertheless, they all appear as "locally modified" *as if you had made the changes manually*. 3) You fix the conflicts, if any, and make sure everything works. Nothing is permanent yet, you still have a local copy with locally modified files. The go/no-go decision comes at the next step. 4a) You commit the result. The changes go in the repository and the local copy appears "up to date" again. 4b) You give up and delete the local copy. It's as if nothing had ever happened. You can combine steps (1) and (2). No matter. The result of a merge is a sandbox with locally modified files. The fact that most of the modifications were done by CVS is immaterial. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cannot commit ... sticky tags
I missed the original, but the followup had enough quoted text... >donald >On Mon, Jan 07, 2002 at 05:12:44PM -0800, Schwenk, Jeanie wrote: >> I'm using cvs 1.11 on hpux. >> >> I tagged the Aug 21 release with the tag Release_Aug21_2001. Just a plain >> tag. >> >> While I was out for several weeks, the vendors who happen to be on the other >> side of the world put a sticky tag on every file, including those I am >> editing. This doesn't make sense. A tag can only be sticky in connection with a sandbox. Assuming you're not sharing sandboxes (say you're not sharing sandboxes!) the only one who could have stuck your sandbox is you. One easy (too easy) way to get a sandbox with a sticky tag is to do $ cvs checkout -rRelease_Aug21_2001 or, from an already checked-out sandbox, $ cvs update -rRelease_Aug21_2001 Presto, sticky tag (as witnessed by "cvs status"). What does this mean? That if you issue a cvs command from that sandbox, there is an implied argument "-rRelease_Aug21_2001". In particular, "cvs commit" really meand "cvs commit -rRelease_Aug21_2001", and that's not allowed. The usual way out of this predicament is $ cvs update -A This is appropriate if you're done with Release_Aug21_2001 and you want to keep developing on the trunk. From your message, this is what you want. The update does two things: 1) Removes the sticky tag *from your sandbox*; "cvs commit" will now mean plain "cvs commit". 2) Merges the uncommitted changes you made in the sandbox with whatever changes other people have committed to the trunk since Release_Aug21_2001 while you weren't looking. If nobody else committed anything, this step will do nothing. If there have been intervening commits, the merge will do something nontrivial and may generate conflicts, like a "cvs update" from a normal sandbox. 3) Mark your files as based on the tip of the trunk, when before they were based on the revision numbers that correspond to Release_Aug21_2001. That is, your files are now "up to date". OK, three things not two. Check for conflicts and fix them. You can now do a "cvs commit". The unusual way out is to get on a branch. This is appropriate if your changes are *not* part of the mainline development but are bugfixes to Release_Aug21_2001 only. To branch, $ cvs tag -b -rRelease_Aug21_2001_bugfix $ cvs update -rRelease_Aug21_2001_bugfix The first command just creates the branch. The second command again does two^Wthree things: 1) Replaces your sticky tag of Release_Aug21_2001 by a new sticky tag of Release_Aug21_2001_bugfix. That is, "cvs commit" will really mean "cvs commit -rRelease_Aug21_2001_bugfix" from now on. 2) Merges the uncommitted changes you made in the sandbox with whatever changes other people have committed on the branch. Well, the branch is still empty, so this step does nothing. 3) Marks your files as based on the tip of the branch. You're already on the tip, so nothing really happens. Now you can commit. The sticky tag doesn't get in the way, it just puts your changes on the bugfix branch instead of the trunk. After you commit, a "cvs update -A" gets you back to the trunk (without the bug fixes). This is another vacuous merge: the changes required to transform the tip of Release_Aug21_2001_bugfix into your sandbox (empty, you just committed and didn't change anything), plus the changes required to transform the tip of Release_Aug21_2001_bugfix into the tip of the trunk (not empty, just a straightforward patch). Result, you're up to date with the trunk --and the sticky tag is gone. The bug fixes are not on the trunk. To get them, you merge the branch. Tag the tip of the branch and merge. $ cvs tag -rRelease_Aug21_2001_bugfix Release_Aug21_2001_p01 $ cvs update -jRelease_Aug21_2001 -jRelease_Aug21_2001_p01 Fix conflicts, tests, etc. Commit. Ship Release_Aug21_2001_p01. Optionally, plant a moving tag to remember what you merged. $ cvs tag -F -rRelease_Aug21_2001_p01 Release_Aug21_2001_bugfix_MERGED -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cannot committ ... sticky tags
"Schwenk, Jeanie" <[EMAIL PROTECTED]> writes: >Thanks everyone for their responses but I need some additional >clarification. >1) I checked out all my files prior to the vendors putting the sticky tags >on. We all think the vendor did no such thing. >So why are the sticky tags effecting me? Either you ran "cvs update -r", or you did a "cvs checkout -r". In your first message, you said you created the tag yourself. >2) removing the sticky tags (cvs update -A), does not effect the sticky >tags in the repository just in my local copy? There are no sticky tags in the repository, just tags. There is a sticky tag in your local copy if, after creating the tag in the repository, you ran a "cvs update -r..." or "cvs checkout -r..." as above. A "sticky tag in a local copy" means that, if you run a cvs command from that local copy, there is an implied "-r..." flag even if you don't spefcify one on the command line. Nothing more, nothing less. >3) Do I need to worry about any conflicts because there is a tag and a >sticky tag with identical names? There is only one tag, there can't be a conflict. The tag is in the repository, and it is visible from all local copies (try "cvs status -v "). In your local copy it is visible, and sticky --implied with every CVS command-- until you reset the stickyness with "cvs update -A". >It must not have given the vendors any >warning but it just doesn't seem right to have a tag for release with the >same name as a branch tag. If there is a release tag and a branch tag, they must have different names. Run a "cvs status -v" on one your files and post the output. >[...] >Is it because commit verifies >that the selected files are up to date with the current revision in the >repository? It doesn't make sense that it would be looking at the branch >tags ... doesn't it compare with the trunk from where I originally checked >out? Well, it depends: if your local copy has no sticky tag, "cvs commit" means just "cvs commit"; it checks against the tip of the trunk and tells you to update if someone committed in front of you. If you are up to date, your commit can finish and the contents of your files become the new tip of the trunk. If you have a sticky *branch* tag, "cvs commit" really means "cvs commit -rBRANCH_TAG", so it checks against the tip of the branch named by BRANCH_TAG. If someone committed to the branch before you did, you will be told to update. Your "cvs update" will mean "cvs update -rBRANCH_TAG" and you will be brought up to date with the tip of the branch. If you are up to date, your commit can finish and, because of the implied "-rBRANCH_TAG", the contents of your files become the new tip of the branch. If you have a sticky *release* tag (which is the pickle you're in), then "cvs commit" means "cvs commit -rRELEASE_TAG", so it checks that nobody committed to RELEASE_TAG while you weren't looking. Of course nobody did, it's impossible. Therefore your files are up to date, and the commit proceeds to the next step... which is impossible. Just do a "cvs update -A". It will unstick your local copy and do strictly nothing to the repository. You'll like the result. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Any Real time examples of Branching, Please!!!
"Datla, Raghav" <[EMAIL PROTECTED]> writes: > Can anyone post me examples of branching in real time >Dev-Stage-Production environment if you are using it. I will appreciate your >help. Mine is not a real-time environment, but it is a real environment :-) In a nutshell, we promote to QA by tagging and starting a branch, and we promote to production by tagging on the QA branch. Development is on the trunk. When the product has the features we want, we tag the tip of the trunk for a QA-release and start hacking on newer features. QA starts a QA-bugfix branch off development's QA-release and starts looking for bugs. Bug fixes are commited to the QA-bugfix branch. When it looks good, we tag the tip of QA-bugfix for a Production-release but we keep fixing bugs on QA-bugfix. Production exports the Production-release, builds it and runs it. Bug reports from production are fixed on the QA-bugfix branch, a new Production-release is tagged, and production takes it. I suppose we could start Production-bugfix branches off the Production-releases, but we don't. After a while tHe QA-fixes branch is merged to the trunk, so Development has the bug fixes too. Eventually, Development makes a new QA release. A new QA-bugfix branch is started and the old one is abandoned. The mechanics of this has some nitty gritty. Read the manual at cvshome.org many times over. --- General rules: 1) Always know why you created a branch, and stick to its purpose. Example: no new features on QA-bugfix. 2) Merge in one direction only. Example: from QA-bugfix to the trunk, never from the trunk to QA-bugfix (no new features). Some organizations prefer to develop on branches, for example one branch per feature. When the feature is ready, merge with the trunk and abandon the branch. Then the trunk is used for integration more than for development. Releases to QA and Production can proceed as above. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Is there anyway to not change a file when there are conflicts?
"Stanton, Curt (NCI/IMS)" <[EMAIL PROTECTED]> writes: >Here is the problem. When CVS tries to merge a file and fails, it creates >the two different versions of the code snippit seperated by the >>>>>>=<<<<<. Or somesymbols like that. We find that to be hard to deal >with most of the time. We use another program called beyond compare to >merge the two together. We do this by getting rid of the file it crearted >with those symbols and starting with the working copies modified file and >the newest repo version. My question is. Is there any way to leave the >file as is (in the not updated modified state) and mark it as having a >conflict? We still want it to merge the two if there weren't conflicts. >Thanks in advance -m 'COPY' in a .cvsignore file. See the entry for 'cvsignore' in the manual. With that, "cvs update" should leave the conflicting copies in your directiry --not sure how they will be called, I don't use that feature much. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Forking off a remote public cvs. Howto merge the parallelldevelopment?
Erik =?ISO-8859-1?Q?Sj=F6lund?= <[EMAIL PROTECTED]> writes: >What possibilities are there to merge in new releases=20 >from the public cvs into our forked code in the future? It's standard. It can be difficult if a new distribution has a radically reorganized file tree, but since they are also using CVS, that's not too likely. >Is there a way to do it by importing multiple times, maybe? Exactly. cvs import VENDOR release_1 cvs checkout cvs commit cvs commit cvs commit ... cvs import VENDOR release_2 cvs update -jrelease_1 -jrelease_2 (fix conflicts) cvs commit cvs commit cvs commit ... cvs import VENDOR release_3 cvs update -jrelease_2 -jrelease_3 (fix conflicts) cvs commit ... -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Any Real time examples of Branching, Please!!!
Wim Kerkhoff <[EMAIL PROTECTED]> writes: >I'm interested in this well. We've recently moved to CVS, and I'm >working on massively re-writing all our build scripts to support this. >We use a scheme similiar to your Dev-Stage-Production environment. >How do you plan to handle versioning? On the old system we used a 4 >digit build number for each distributed file as well as each >distribution. Ie, periodically make a release (e.g. Build 3200), but >regularly we release new versions of files via an update system within >the product. So, if they do an update today a new foo.jar might get >pulled in with a build number of 2783, or a new docs.pdf with a build >number of 1087. This has come to mean nothing, especially as a component >gets moved up from Dev to Stage, it takes over the build number of the >previous build number in Stage plus 1. This seems to be a distribution issue as much as a versioning problem. Where is the build number stored? Directly in the file? For source files (foo.jar but not doc.pdf) you can embed a $Name$ keyword in a comment, or even a displayable string. If you do a cvs export of your tree (also cvs checkout, I think), the keyword is expanded with the tag you specified in the -r option. So one solution to your problem is to distribute your releases with cvs export. The $Name$ keyword is not expanded during a "cvs update" of a checked-out sandbox, even if you specify a tag. I sometimes wish it were, but it isn't. If you "distribute" by having your customers update a sandbox, I don't know how to embed meaningful numbers in your files. However, the sandbox owner can still see what he's got by running cvs status, say, from the sandbox. "cvs export" works fine for big releases, but it becomes clumsy to use if you issue little patchoids all the time. Updating a sandbox works better for these informal releases, but they are closer to the bleeding edge. The .pdf files are more difficult. If they are generated from text sources, embed $Name$ in them, processing it if necessary. I've done that with LaTeX, for example. If you use a WYSIWYG tool to edit the pdfs you're stuck with the usual limitations CVS has with binary files. Can't do much. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cost of CVS...
"vincent_choplin" <[EMAIL PROTECTED]> writes: >I work in a small but still growing company and we're beginning to >need something like CVS... >[...] Is it worth hiring a temp. or consultant to install and >teach us? A consultant may be a good idea in such circumstances. The trick is to find a good one. Where are you? In France? Zut, c'est un peu loin. >would we have to stop working while we put CVS up or can one of us do >it while the others go on with the developpement? Nah, don't stop. When CVS is ready, import what you have and save the original into prehistory.zip . >Is it really better to use linux on the server or are the winNT >versions good enough? If you have a Linux box you probably have CVS already. If you only know Windows or only have Windows machines, try www.cvsnt.org , it might be the path of least resistance. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs for dos
"Schwenk, Jeanie" <[EMAIL PROTECTED]> writes: >Anybody know if there is a way to access CVS using pserver from a Windows >2000 command line? ?? I thought the Windows distribution on cvshome.org *was* a command-line version? -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Developer branches
"Steve Ebersole" <[EMAIL PROTECTED]> writes: >we have, >as of yet, been unable to perform a successful build precisely because >everyone is checking in code which does not compile with work of other >developers. They must be committing single files. Tell them to commit wholesale ("cvs commit" from the top-level directory, no other arguments). They will get a complaint from cvs that their sources aren't up to date and that they should please run "cvs update" first. Once they do *that*, they have all the changes made by the others and they can attempt a make --er, Ant-- to see if that builds. If not, fix it and commit only when it works. So the sequence goes like this: cvs commit --darn, out of date cvs update Ant --darn, won't build (fix conflicts) Ant --success cvs commit On a hyperactive repository you might find yourself unable to keep up: somebody always commits another change while you're fixing the mess after the update, so by the time your build completes you're still out of date and have to update again, then fix, etc. Frankly I doubt that a team of six can commit that often, but if it happens you can start creating development branches. One branch per feature/subproject/whatever, not one branch per developer. You want to keep *some* of that update-fixit madness, that's the joy of concurrent development! Seriously. If you coordinate your work just a little, the productivity boost is well worth the trouble. If you do create development branches, you end up using the trunk for integration. You still have to make sure each branch builds cleanly before attempting a merge, but you have a litle bit more flexibility: you can put a branch on feature freeze without slowing the other branches. When a branch looks good (it had better build!) you can merge it to the trunk and deal with conflicts (the integration work). >... >However, I don't think I really liked the idea of tags to perform this step >because it is either adding responsibilities back on the developers to tag >their code which is ready for build release (which the idea alone of them >making that decision scares me) or back onto the release manager to >determine what is eligible for release to build. No, no. When you tag from a sandbox, the tag is applied to the versions *as of your last commit*. If you've made changes without committing them, the tag misses them --it has to, the changes aren't in the repository. I go back to your statement, >we have, as of yet, been unable to perform a successful build That is an anomaly. Committed code should build, mostly. It can crash at run-time, but it should build. How do you know it will build? because you built it before committing --automated test, no reason to skip it. >We are a team of 6 and the >project is huge, so adding any substantial additional work to one person's >plate could be detrimental. One of you has to play release manager. It can be any one of you, maybe even on a rotating basis, and with collegial input from the whole team. Once you reach a milestone, the release manager tags it and starts a QA branch. The QA branch is reserved for bug fixes (including build failures, in extreme cases). No new features. When the QA branch looks really good, you tag it and you ship what you just tagged. You also merge the bug fixes from the branch to the trunk. And don't tag or branch individual files, you'll get a mess. Tag the whole project. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Partial checkout of an ampersand module
"Bill Biessman" <[EMAIL PROTECTED]> writes: >QUESTION: >Is there a way to check out just one file from the tree below an ampersand >module specifying the complete path? >MORE DETAIL: > >I have a line in my modules file that looks like: >whole_thing&part_one &part_two First of all, you can already check out part_one by itself: cvs checkout part_one If you really want a single file from part_one, figure out what part_one is. There should be a line in the modules file that says something like part_onepath/to/part_one You can then do cvs checkout path/to/part_one/subdir/myfile and you will get myfile, 4 directories deep. >... >look at the file for a while with a script, and then: >cvs update -C -P -d whole_thing >to get the rest of the files in the project. Won't work. Commit myfile from your deep sandbox and wipe out the sandbox. Then do a full checkout of whole_thing. But if you're going to check out whole_thing eventually, why not do it up front and keep it checked out? -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: reverting changes
Arcin Bozkurt <[EMAIL PROTECTED]> writes: >The latest change to our repository was to commit some tens of files which >caused the code to break. I am trying to get back to the state a day ago and >commit it back to the repository effectively overriding the change made >(obviously this development had to be done on a branch but ) >I cannot use update -D yesterday, because the result is sticky. removing the >stickiness with -A takes me back to what the repository has. >can we used -j with dates? Dates on -j only can be added when you have a >version/branch to point to. Hmmm, if you're sure of the dates, you could do $ cvs tag -D '2 days ago' tmp_pre_goof $ cvs tag tmp_post_goof $ cvs update -jtmp_post_goof -jtmp_pre_goof When you're satisfied with the results, commit the sandbox and delete the tmp_ tags. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Working directory & laptop?
Eric Siegerman <[EMAIL PROTECTED]> writes: >On Fri, Feb 08, 2002 at 09:55:45AM -0600, [EMAIL PROTECTED] wrote: >> If I copy my working directory to my laptop, do some modifications, copy >> it back and do a commit, will I have any issues >[pitfalls described] >This is exactly the sort of confusion CVS can help with, so why >not take advantage of that? Instead of copying your desktop >sandbox, do a fresh checkout directly onto the laptop; then you >can commit those changes independently of your work on the >desktop machine. The standard CVS multiuser thing; it's just >that both users happen to be you :-) I'll second that and raise it: install CVS on the laptop and import the sources there. Desktop: cvs tag trip_bp : branch point cvs tag -b -rtrip_bp trip : branch (cd somewhere else...) cvs export -rtrip scp -r you@yourlaptop: rm -rf : the exported tree, that is Laptop: export CVSROOT=~/cvsroot cvs init cd cvs import -m'work on trip' VENDOR start_of_trip cd .. rm -rf cvs checkout cd (take it away...) When you come back, Laptop: cvs commit cvs tag end_of_trip cd cvs rdiff -kk -rstart_of_trip -rend_of_trip > trip.patch scp trip.patch you@yourdesktop:trip.patch Desktop: cvs checkout -rtrip: new sandbox on the branch cd patch -p2 < ~/trip.patch (the patch should apply cleanly) cvs commit cvs tag trip_endpoint Now you can go to a regular sandbox and merge your work: cvs update -jtrip_bp -jtrip_endpoint The only drawback is that your main repository sees only the start and endpoints of what you did on your laptop, without the intermediate stages. Then again, do you want them? Personally, I only use the intermediate stages between milestones as fall-back positions in case I mess up. When things are solid, I stop caring about the micro-history. Just make sure your "trip" branch is in good shape before you merge it. If not, you should first polish it up on the main computer, in the sandbox that's on the branch. BTW, I'm assuming both computers use a unixoid OS, but all of this can be done in Windows. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Root Merge
Dave <[EMAIL PROTECTED]> writes: >We distribute our source to a remote location that does not have a network >connection to our main CVS repository host. We tar the CVS root on tape and >extract it on the remote host. Strange. Does the remote site have to see the detailed revision history? If not, I would just use cvs export to send them tarballs of tagged releases. They can import the tarballs into their own independent CVS repository. They can send you patches when they make significant changes, and they can reimport and merge when you make significant changes. In other words, you pretend they are a privileged customer, they pretend you are a responsive vendor. >The problem is we need a way to capture the changes made during the >installation in our main CVS root. Your distribution method is unconventional, but they can still generate patches and send them to you. If you want tighter integration of the two sites, you're going to need some sort of network... -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: trading files without ",v" suffix
Claudio Klingler <[EMAIL PROTECTED]> writes: >i have some files imported into my cvs repository. These files name's do and >should not end with the ",v" suffix. Unfortunately cvs ignores this files. This is not clear. If you are trying to import files ending in ",v", do a "cvs import -I! ...". You'll get files ending in ",v,v" in your repository, that's all. To the list: is "-I!" safe nowadays? I used to type "-I! -I. -I.. -I.#*" to avoid recursive trouble, but that was a long time ago. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: using files with .xls and .doc in CVS
Rob Helmer <[EMAIL PROTECTED]> writes: >Why do so many on the list poo-poo using binaries in CVS? Here's an excerpt from my cvswrappers: *.bmp -k 'b' *.ico -k 'b' *.lib -k 'b' So I do put binaries in CVS, mostly when I don't have a better place to put them. They tend not to change much. But .doc files? yuk. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Hierarchical team integration in CVS
"Earl Williams" <[EMAIL PROTECTED]> writes: >Team A is responsible only for the internals package, and has written a >harness project to help them test their classes in isolation. Team B is >responsible for all other classes in the app, and has written stub classes >to stand in for Team A's work. Both teams use the classes in the two >utilities packages. >How should these teams use CVS? Adapt your tree structure. Do *not* mix files from teams A and B in a single directory, CVS won't handle that well. The modules file can package things nicely for you, if you can live with the resulting sandbox structure. _utils -d utils path/to/utilities _team_A -d A path/to/team/A/files _team_B -d B path/to/team/B/files These aren't meant to be checked out. If you did check out module "_team_A", you would get team A's tree under a top-level directory called "A" (from the -d option). It wouldn't do you any good because the shared utilities aren't there. Next, create wrapper modules for each team. Team_A &_team_A &_utils Team_B &_team_B &_utils If you check out "Team_A", you'll get a tree like this: Team_A/ utils/ (the shared utilities tree) A/ (team A's subtree) and similarly for "Team_B". These are complete trees, useable by the teams, if they can stomach the layout. Lean on them. You'll also need to check out the joint project, so create a module for that: Fullpath/to/glue &_team_A &team_B &_utils A checked-out sandbox would look like this: Full/ (glue files) utils/ (the shared utilities) A/ (team A's subtree) B/ (team B's subtree) The "glue files" could include a top-level Makefile that knows what to do with the subtrees, plus a README or two. It could even be a big sutbree in its own right. Put in whatever you need to integrate the two subprojects. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: problems with simple cvs update - changed file is not updated
Heirler Stefan <[EMAIL PROTECTED]> writes: >Scenario: >cvs checkout foo.c >... do nothing with foo.c, but others commit changes to foo.c >cvs update foo.c >no changes are retrieved >This does not happen everytime doing an update but from time to time. Is >there a known fact leading to duch a problem? Just a wild guess, but are you using client-server? is there a time skew between the two machines? -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Hierarchical team integration in CVS
"Earl Williams" <[EMAIL PROTECTED]> writes: >Thanks very much for your detailed suggestions. It seems that in order to >use CVS, the directory structure of my project must be driven by short-term, >division-of-labor-during-development concerns (Team A, Team B, Shared) >rather than by the conceptual structure of the classes in my project. Too >bad. I guess I need to learn more about Software Configuration Management. ?? The division into teams doesn't follow the logical structure? Strange. Anyway if the division of labor is short-term, just ignore it. Everybody check out the full Monty, just mind your own files. Actually there is a way out, but I'm not sure I would recommend it. Lay out your full project's repository (and sandboxes) any way you want. Check out a full sandbox. Then selectively create a branch tag for the files that belong to team A. Similarly, create a branch tag for team B's files. After that, if you do "cvs checkout -rteam_A_branch project", you get a sandbox for team A. If you "cvs checkout -rteam_B_branch project", you get a sandbox for team B. If you do a plain "cvs checkout project", you get a full sandbox... with none of the changes your teams have made on their branches! To get their work on the full project, the teams have to merge their branches to the trunk periodically (or have an integration guy do it for them). The merges have to be done often, with floating tags to keep track of what's already merged, etc. When your division of labor changes, stop using the branches and create new ones. Like I said, I wouldn't recommend that approach, because of 1) the perils of branching selectively; 2) the need for frequent merges and floating tags; 3) the minimal advantage if gives you in hiding files that you could just as well ignore. The big, big weakness of CVS surfaces when you want to massively reorganize your source tree. CVS just isn't good at that. It does ok on static layout, subject to constraints that personally I can live with, but it's hard to get the right layout on the first try! -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Newbie: howto share modules
Syver Enstad <[EMAIL PROTECTED]> writes: >I have a subproject in CVS (a directory in a module) >where I want to have some other subprojects from CVS as >subdirectories. >Let's say we have: >The following structure: >(C++ is the root module) >C++/Applications/MyApp >C++/Libraries/TheFirstLib >C++/Libraries/TheSecondLib >C++/Libraries/OtherLibs >... >Where I want to have >C++/Applications/MyApp/TheFirstLib >C++/Applications/MyApp/TheSecondLib I'll assume you want to check out only MyApp and the two libraries. Put something like this in your modules file: TheFirstLib C++/Libraries/TheFirstLib TheSecondLibC++/Libraries/TheSecondLib ... Myapp C++/Applications/MyApp &TheFirstLib &TheSecondLib The first two are straightforward module entries. You can check out "TheFirstLib" and have it appear in ./TheFirstLib . The third entry is the application, and it implicitly checks out the two libraries as submodules. The sandbox looks like this: ./Myapp/ (Myapp files...) TheFirstLib/ (1st library files...) TheSecondLib/ (2nd library files...) -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checking out to remote working directory
Michael Sims <[EMAIL PROTECTED]> writes: >At 09:15 PM 2/16/2002 -0500, Aden, David wrote: >>[wants to check out on a remote NT machine] >Install Cygwin on the NT server hosting the developer sandbox, >and setup the Cygwin sshd to run as a service. I agree, but using Cygwin has security implications. The distribution explains them better than I can, but I *think* the sshd won't be able to hide its address space from other NT processes, so your sessions are vulnerable to snooping. Mind you, someone would have to crack the NT box first, at which point you've already lost that battle. But there's no reason to open your other accounts to the intruder, so *use a custom password for this ssh account*. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Exclusions while tagging
"Ben Baker" <[EMAIL PROTECTED]> writes: >dist >-non-media1 > -non-media1.1 >-non-media2 >-non-media3 > -media // Here's the media. It's embedded within the dist tree >-non-media4 >[ ... ] However, it would also help our build process a >great deal to be able to tag or rtag everything on dist except the media >module. Would it work to tag the whole shebang, then remove the tag from the media files? cd dist cvs tag TEST cd ./-non-media-3/-media cvs tag -d TEST -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multiple modules inside a module hierarchy
Bruno Mussard <[EMAIL PROTECTED]> writes: >[ ... ] I should like to set-up the following hierarchy >configuration for a new "top-level" module MY_PROJECT : > MY_PROJECT/ ---> IP_BLOCKS/ ---> USART/ > | | > |-> USB_DEVICE/ > | > -> ARM_CORE/ Nested amperstand modules? I think they work. If I understand your diagram correctly, USB_DEVICE path/to/USB_DEVICE USART path/to/USART IP_BLOCKS path/to/IP_BLOCKS &USART &USB_DEVICE ARM_COREpath/to/ARM_CORE MY_PROJECT path/to/MY_PROJECT &ARM_CORE &IP_BLOCKS -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Any Real time examples of Branching, Please!!!
Wim Kerkhoff <[EMAIL PROTECTED]> writes: >In fact, I have taken the liberty of converting your post into a page on >Wiki site that I have set up on practical release branching with CVS, >over at: >http://www.nyetwork.org/wiki/CVSReleaseManagement Can't stop you, but you made a transcription error: >>> QA starts a QA-bugfix branch off of development's QA branch, <<< Should be "off of development's QA release", as in the usenet article. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: modules file
Arcin Bozkurt - Archie <[EMAIL PROTECTED]> writes: >The following are defined in modules file: >CppAlgo-a CppAlgorithms >SelAlgo-a SelAlgorithms >Algorithms &CppAlgo &SelAlgo >algo Algorithms >The last definition is not recognized. Does the "Algorithms" module work as you want? If so, try simply algo&CppAlgo &SelAlgo In the modules file, module definitions (the simpler ones, anyway) have the form modulename path/to/the/top/of/the/module/tree where the path is relative to $CVSROOT. Then there are alias definitions, amperstand modules, etc. Your definition of "algo" sent cvs looking for a directory $CVSROOT/Algorithms, *not* a module "Algorithms". -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: capturing test code in CVS
Arcin Bozkurt - Archie <[EMAIL PROTECTED]> writes: >What is the best way to capture test code for a module? We had a thread on this not long ago. All right, let's start from the beginning: what language? -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - import to 1.1
"Matthew Persico" <[EMAIL PROTECTED]> writes: >Is there a way to cvs import into 1.1, not 1.1.1.1? Without the branch, the >first lock and commit attempts will work as advertised. >If I cannot do this, then I have to create an empty project and then write a >script that will recurse a tree of code, doing cvs adds as appropriate and >I'd rather not do that. Doesn't "cvs add" recurse? The procedure I remember goes like this: mkdir emptydir cd emptydir cvs import -mdummy path/to/project/root DUMMY dummy cd .. rmdir emptydir The import just creates an empty directory in the repository. The import message, vendor branch name and release tag are lost, there aren't any files to hold them! Add the new directory to your modules file: cvs checkout CVSROOT cd CVSROOT echo projectnamepath/to/project/root >> modules cvs commit cd .. cvs release -d CVSROOT Then, cvs checkout projectname cd projectname : copy your source tree to where you are : Hmmm... you may need to cvs add the directories first : find . -type d -print | xargs cvs add : : Darn! I could have sworn that "cvs add" recursed once the : directories were in, but I can't make it work on my : (admittedly old) cvs. : Here's a find incantation to add all the files. : find . -type d -name CVS -prune -o -type f -print | xargs cvs add : : all the files are added cvs commit The files will show up at revision 1.1. The second "find" works by 1) excluding the CVS directories from the search, and 2) listing all the files found elsewhere. Works great in a unixoid environment. If your're stuck in Windows, well that's tough. So it's work, but I wouldn't call a pair of one-liners a huge scripting job. If your files have spaces in their names, use find ... -print0 | xargs -0 ... -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Newbie: nonsensical documentation
<[EMAIL PROTECTED]> writes: >I'm being forced by my supervisor to start using CVS, which I hate. Does your supervisor --or anyone else in the group-- know any CVS? The learning curve is steep if you have to do everything, but if you're joining a group that already has everything set up, they could just teach you cvs checkout, update and commit and you could start hacking right away. There used to be a CVSHELP(1) man page in the distribution way back when. I found it very useful. >On page 29, one is instructed to do this: > $ cd $WDIR > $ cvs import -m "Imported sources" yoyodine/$RDIR yoyo start > $ cd .. Yow, imports. They're slamming you into it. Ok, here's an overview of how import works. * Unpack or copy a clean source tree somewhere. * cd to the top of the source tree. * Run the import command. * cd back up one directory and wipe out the source tree. >I've done this (though, of course, I've changed "yoyodine/$RDIR" to >"MyModule", and "yoyo" to $USER). Good, so your source tree is now in CVS, rooted at directory "MyModule" at the top of the repository. The next step would have been to put an entry in the modules file, but since your module is at the top-level of the repository this is superfluous. Now you want to cd to a clean directory to try out your import. >Next, the instructions say to do >try this: > $ cvs checkout yoyodine/$RDIR Did they say to go to a clean directory first? >so I try: > $ cvs -n checkout MyModule That should work. Er, why the "-n" option? paranoia? >but I get an error message: > cvs checkout: cannot chdir to MyModule: Not a directory > cvs checkout: ignoring module MyModule It's the "-n" option. CVS should create a top-level "MyModule" directory, cd to it, and proceed to populate it with a copy of the sources. It didn't create the directory because of the -n option and it should have known better than to try to cd into it. If I'm right, you found a bug! Workaround: be bold. $ cd $ mkdir scratch $ cd scratch $ cvs checkout MyModule -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: File sharing
"Ben Baker" <[EMAIL PROTECTED]> writes: >We're in the process of converting from another source control system to = >CVS and one of the things our previous system did that CVS does not is = >file sharing. If you mean what I think you mean, CVS can share files among modules, but only at directory granularity. In other words: in a checked-out sandbox, all the files in any one directory MUST come from a single directory in the repository. If your previous setup mixed the shared files, you have a reorganization job to do before switching to CVS. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: dual repositories - please give me your thoughts
"Daniels, David" <[EMAIL PROTECTED]> writes: >Someone has proposed a CVS setup to me which I would very much like comments >on. In this proposed system, there would be two CVS repositories. The first >would be open to the development staff and would be for general use. The >second would be an rsynced version of the first and would be for creating >releases for testing or production. I could see that if you have a slow link between two sites, but otherwise why not use a single repository and eliminate the middleman? "cvs export" works fine for releases. >The second repository also would have >the users who have access limited to the release manager for the project. >The reasons I was given for a second repository include security and better >manageability. Any thoughts? Hmmm, you *might* be able to tune access more finely with a second repository, but the argument isn't very convincing to me. Any specifics? I don't think it can hurt much, when in doubt the development repository is authoritative, but I don't see how it helps. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sharing cvs root?
"Hanser, Kevin" <[EMAIL PROTECTED]> writes: >My boss seems to think it would be a good idea to share our CVS root so we >can easily browse it. I don't think this is a good idea... can anyone give >me the pro's or con's of doing this? If it's read-only, there wouldn't be much harm... >We have our cvs repository located on a linux box, and are using winCVS to >do our checkouts/updates/commits, etc. He wants to be able to browse the >cvsroot so he can see the modules If your modules file is well-maintained, There's "cvs checkout -c | more", or "cvs checkout CVSROOT". Recent versions of cvs have "cvs rlog", which will tell you basically everything about a module, short of the actual sources --you might want to pipe it into a script or two. -- Pierre Asselin Westminster, Colorado -= Posted via Newsfeeds.Com, Uncensored Usenet News =- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -== Over 80,000 Newsgroups - 16 Different Servers! =- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merging changes between branches
In <[EMAIL PROTECTED]> "Yuval Rotem" <[EMAIL PROTECTED]> writes: >We want to employ branches as a relatively isolated development environment, >[ ... ] >However, according to the docs, it seems that using CVS branches for this >purpose isn't that trivial, at least in one respect: It should be possible >to perform an update to merge changes from the main trunk into a branch (or >vice versa). In CVS this requires me to remember when the last update was, >and update with two -j flags, which is a bit awkward. For multiple merges from branch to trunk, you plant a moving tag after each merge. $ : on the trunk $ cvs update -jbranch_lasst_merge -jbranch_tip $ cvs tag -F -rbranch_tip branch_last_merge It's clumsy, but doable. I'm not sure what to do for bidirectional merges. This could work: -- On the branch, periodically merge *everything* from the trunk since the branch started, planting a moving tag on the trunk as above. One moving tag per live branch. -- To merge from branch to trunk, temporarily restore the trunk to its state at branch creation time and merge the whole branch. $ cvs update -jHEAD -jbranch_starting_point $ cvs update -jbranch or $ cvs update -jbranch_starting_point -jbranch_tip (Use the latter command if files get deleted on the branch.) It is essential that you merge all trunk changes to the branch, otherwise you will lose code. Hmmm, you may not need a moving tag on the branch if you do it this way, since you always end up merging the whole branch. Caveat: I've never tried it, and someone (Larry?) said that CVS would get confused by two -j-j merges without an intervening commit. Not sure why, though. Proposals to keep track of previous merges pop up on this newsgroup from time to time. Usually they entail extending the RCS grammar (the "newphrase" production in the rcs(5) manpage). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problems using CVS transparently
In <[EMAIL PROTECTED]> Sonam Chauhan <[EMAIL PROTECTED]> writes: >PROBLEM #1: CVS usage must be transparent. This means no 'CVS' >meta-directories are allowed [ ... ] Give up now before you get an ulcer? >SOLUTION #1: The way I solved this problem (I think) was by creating >a parallel source controlled directory hard linked to the development >hierarchy. Does that work? CVS has a way of ignoring files with link count greater than 1. >PROBLEM #2: How to add large numbers of files and directories to >an existing cvs module. I use find, on the fly. If there are new directories, $ find . -type d ! -name CVS -print | xargs cvs add and ignore errors for directories that are already added. For the files, $ find . -type d -name CVS -prune -o -type f -print |\ > xargs cvs add and also ignore double-add errors. >I've also hit what seems to be a bug in CVS >while trying the script the addition of some directories. cvs tells >me they've already been added. For e.g. it says: >cvs [add aborted]: there is a version in dir22/source already >exists The 'dir22/source' directory also has a CVS sub-directory. >But doing a cvs checkout does not create the dir22/source directory. >Am I doing something wrong? Are there any files in dir22/source, and if not, are you pruning empty directories? (the -P option). >PROBLEM #3: How can I detect and commit changes to the development >codebase when making a release? cvs -nq update . >As described in problem #2, new >directories may be added or deleted arbitrarily by the development >environment. General impression: you can have your development environment or you can have CVS, and you can't have both. Maybe you should treat your dev environment as a virtual vendor. Export trees, not checkout, to use in development. When ready, import them back, not commit, into CVS, as if you were releasing a tarball to yourself. This is an extremely clumsy way to use CVS, turning it into a glorified closet. It also means that you develop without the benefit of a source-controlled environment: no cvs diff, no cvs update, etc. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question on multiple repositories
In"Max" <[EMAIL PROTECTED]> writes: > I'm brand new at the CVS game and have no senior resource available at >work, so I'm hoping that I can get some help here. > The specs I was handed at the office call for an open development >repository and a secure QA/production repository. Once developers finish >their stuff, a baseline is made and the code is replicated to the QA >repository. This is the step where I'm having a problem. Complicated. Call it a formal release from dev to QA: cvs export from dev, cvs import in QA. At the same time, dev creates a bugfix branch and checks out a sandbox on it. When QA fixes a bug, it sends a patch to dev, who applies it to the bugfix sandbox, commits, and merges back to the trunk. > I'm hesitant to use "import" because (as I understand it) this command will >club the previous versions under the same name (down the road). That's what you have to do, though. The QA people will just have to learn how to do pre-import tags and post-import merges. It's a lot more trouble for them too, but those are the consequences of the rules imposed on you. Note that an import doesn't destroy previous imports. It can break the trunk until the post-import merge is finished, but past imports are always available through their tags. Faint glimmer of hope: what do they mean by "secure QA"? If "secure" really means secure, you're in the import/export business and that's that. If "secure" only means "commits to QA tress are restricted", then you *might* get away with commitinfo scripts that reject commits by developers when on a QA branch. Understand that this is not "secure" at all, in that a developer determined to break company rules can probably defeat the system. It will only prevent casual or inadvertent commits. If acceptable, this would be *much* better for all: a single repository, dev releases to QA simply by creating a tag, QA creates and manages the bugfix branch, dev merges directly from the branch to the trunk. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problems using CVS transparently
In <[EMAIL PROTECTED]> Sonam Chauhan <[EMAIL PROTECTED]> writes: >The proprietary IDE (something called 'webMethods B2B'), though >lacking version control, has a inbuilt release mechanism. It zips >up release directories in the working set. These ZIP files are then >distributed to other servers. Hence we end up with CVS directories >in 'live' servers. This takes us far far away from 'support land' >and also may cause complications with the software's internal >functioning. Can you intercept the .zip files and launder them? My zip man page says: zip -d foo foo/tom/junk foo/harry/\* \*.o will remove [from foo.zip] the entry foo/tom/junk, all of the files that start with foo/harry/, and all of the files that end with .o (in any path). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: FW: Symbolic tag information after a 'cvs release'
In <[EMAIL PROTECTED]> Sonam Chauhan <[EMAIL PROTECTED]> writes: >Sorry - Having never done *software* releases" with CVS myself, I misphrased my >query. What I really meant was 'cvs export'. In other words, we do a 'cvs >export' of a tagged branch as part of our release process. I wanted to capture >the tag name of the cvs-*exported* branch by processing a CVS variable in a >file. This does not seem possible. There's the $Name$ keyword, but it won't give you the name of the branch, just the name of the *release* you exported. It makes no difference if the release is on a branch or on the trunk. Note: you shouldn't export and ship with a branch tag, because you won't know what you shipped. You get the tip of the branch, and that changes as the branch grows. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: repository orgnization
In <[EMAIL PROTECTED]> Joi Ellis <[EMAIL PROTECTED]> writes: >I manage a CVS repository which I've used to store all of my projects >for the past two years. Recently my manager asked me to migrate this >repository from my own workstation over to a company server so that >everyone in our Engineering group can use it. >I use JBuilder with my CVS repository, and the structure I have is simple: > > CVSROOT/module1 > CVSROOT/module2 > CVSROOT/module3 > ... Commit and release all your sandboxes and change that to CVSROOT/leave_me_alone/module1 CVSROOT/leave_me_alone/module2 CVSROOT/leave_me_alone/module3 ... Add entries in your CVSROOT/modules to reflect the change: module1 leave_me_alone/module1 module2 leave_me_alone/module2 ... You should be able to 'cvs checkout module1' exactly as before. >The guys are migrating code from an ancient SourceSafe server into my >repository, and they are building a tree-structure with their stuff: > CVSROOT/Engineering/Libs > CVSROOT/Engineering/APi > CVSROOT/Engineering/Firmware/i386 > CVSROOT/Engineering/Firmware/strongarm Ok, so now copy your CVSROOT/leave_me_alone/ tree to *their* CVSROOT, add the entries in their modules file, and away you go. The basic function of the modules file is to specify named subtrees of the entire repository. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ampersand module question
In <[EMAIL PROTECTED]> Martin Heinen <[EMAIL PROTECTED]> writes: >On Tue, Apr 09, 2002 at 01:09:27PM +, Jay Glanville wrote: >> [ ... ] >> Now, is there a way to say that module amp1 should be included in module mod >> and be placed in a directory called tools. For example, when I do a >> checkout of module mod, I get the following directories: >> mod >> mod/tools/amp1 >> mod/amp2 >The -d option renames the working directory: >| amp1 -d mod/tools/amp1 amp1 >| amp2 amp2 >| mod &1 &2 I think it should be '-d tools/amp1', the 'mod/' is implied by the amperstand mechanism. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ampersand module question
In"Jay Glanville" <[EMAIL PROTECTED]> writes: >Thanks Martin. It's a good start, but not all that I was looking for. By >using the "-d" option, what I'm doing is "front-loading" the naming >architecture. In other words, anytime I use module amp1, it will be under a >directory tools I create dummy modules for that purpose. For example, amp1path/to/amp1 amp2path/to/amp2 _amp1 -d tools/amp1 path/to/amp1 mod path/to/mod &_amp1 &2 The convention is that a module beginning with an underscore is not meant to be checked out by itself --although nothing prevents you to. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs