Dear info-cvs, we have a problem with cvs 1.10.3 (repository on afs, all Linux client for cvs ci, cvs up etc). The problem described below manifests itself in the same way also on HP-UX clients. The
Hello again, Ok, Now, the question is: How to implement the cleaneast way to find out if more than one file is addressed? After looking through the code, I see two possibilities: 1. In get_server_res
You could always force commits (with descriptions) to cover the missing source versions. The code will not change, which will mean very little wasted space in the repository. See the -f flag of cvs c
Because that's what import does -- it puts the files on the vendor branch. Use add rather than import. Alternatively, after importing do: cvs admin -n trunk:1 # add a branch tag for the trunk cvs adm
Why is it that when I run a cvs import to create a new repository, it always creates all the files with revision 1.1.1.1? Once I do any change it changes back to the normal 1.2 but the problem is tha
Yes, but don't do it. Revision numbers are for CVS's internal use only. If you want meaningful version numbers attached to the code, use tags. -Larry Jones I'm getting disillusioned with these New Ye
Yes, but why do you want to? The revision numbers should be considered internal to CVS, and the only external use should be as opaque identifiers, and in this case "1.100" is just as good as "2.0".
Hello David, Well, it became obvious quite soon, that CVS will not do it without some tricks. What I tried to bring across: The idea of using branches in such a context might make it easier! .... Tha
[ On Saturday, February 2, 2002 at 09:14:40 (+0100), C. Wienberg wrote: ] Of course -- that's about the only way you'll ever make any kind of change management system make sense! Huh? Nope. Not a pro
[ On Thursday, August 23, 2001 at 14:31:11 (-0700), BCC wrote: ] That's not a reason. That's a VERY poor excuse that reveals some glaring problems in your development process! Yeah, those kinds of th
I have a question about a CVS behaviour that makes me wonder for a long time. When I import some files with the following command: $ cvs import -m "1st import" some/path/in/repository mygroup start t
I get this error: $ cvs -d:pserver:address@hidden:/cvsroot/clocc up - -r 2.0 rpm.lisp M rpm.lisp $ cvs -d:pserver:address@hidden:/cvsroot/clocc up - -r 1.17 rpm.lisp RCS file: /cvsroot/clocc/clocc/sr
Hi Michael, I have read some content on the Web regarding this... below are few extracts <extract url="http://gforge.org/themes/gforgegroup/viewvc/help_rootview.html"> In CVS Repositories, ViewCVS ad
Just to confirm - this fixes my problem. Thanks for the quick work, Jim! -- Steve McIntyre, Cambridge, UK. address@hidden "It's actually quite entertaining to watch ag129 prop his foot up on the desk
OK, I've tracked it down to client.c, in send_fileproc. 1.11.20 (which works properly) has this code to test if the file has been modified: else if (vers->ts_rcs == NULL and 1.11.21 has changed the t
I've tried the patch, but still no joy: tack:/tmp$ cvs-1.12.13-markpatch -q up seyon1 RCS file: /home/cvs/seyon/Seyon.c,v retrieving revision 1.37 retrieving revision 1.38 Merging differences between
[ On Wednesday, December 3, 2003 at 12:36:35 (-0600), address@hidden wrote: ] Yes, that's sort of what I was getting at. Indeed. It's just important to very clearly make the distinction between fat-f
I can think of specific examples where testing, etc. may not happen in a 'working copy' of the code. For example, one of the projects I am using cvs for is a website. I have a script in cvs that, upo
[ On Tuesday, October 8, 2002 at 22:32:18 (-0700), Mike Ayers wrote: ] Me too! :-) Well, in theory you could check out a working directory with the new tag and test it then, and you could adjust the