Re: What could go wrong with this scenario?
>> A good description from the list archive: >> http://www.mail-archive.com/info-cvs@gnu.org/msg14117.html > From this message... > ...probably need to set the set-group-id (SGID) bit on the directories > in your repository (chmod g+s) -- that usually makes newly-created files > and directories get their gid from the parent directory instead of from > the creating process on systems where that doesn't happen by default... > - usually? yes, not all Unixen actually do this; it is a BSD thing, and used not to be available everywhere. IOW, check if it works. > If I understand correctly when I use chmod g+s on the project directory > and I do this once the directory is created every addition and > modification of whatever user will make sure that the file is in the > right group Yes. This includes newly created directories (which also will get their SGID bit set if all's well). > and the file belongs to the creator (in the case of adding a > new file) and preserves the ownership when committing a change. no: it's about gid, not uid. So >> What is the underlying problem you are trying to fix? > See above, that is the basic idea. New files are owned by their creator > and stay that way (this happens by default right?) No. There can be several checked-out copies of files, which will each have the ownership and default permisssions of the person that checked them out. If you talk about 'the' ownership of a file, I can only assume that you mean the repository file ($CVSROOT/foo/bar,v). This will be owned by the latest commiter. But this is pretty much irrelevant with group-write access (which is the common mode of operation). > others in the group > have write rights on the file (in normal shell environment) Which file ? checked-out copies: full rights. Repository files: everything read-only for everyone. This is because CVS used to use RCS, which relies on access permissions to know what it's doing. > and if > applicable commit rights on it. Others not in the group have no rights. I can't seem to find you original post, so I guess you want to use access control lists; this is not very common nor considered useful with CVS. > This is the first of a series of activities to come to a repository > which can hold secure files (customer owned) and free sources mixed into > one repository. We used to have different repositories for it, but I > have decided to plunge in and try to have them in one repository without > daily manual maintenance to get guarantees that information is secure. Don't use different repositories for this; use the same repository with different modules. Check customer-owned files/trees into their own vendor branch, and lock it down. A quick search on groups.google.com gave this: http://groups.google.com/groups?hl=en&threadm=H9db0ada4da3.0991676620.kcopmp06%40MHS&rnum=3&prev=/groups%3Fq%3Dcvs%2Block%2Bbranch Cheers, Philip -- The mail transport agent is not liable for any coffee stains in this message - Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Anybody any idea on how to set back a revision number?
> On Tue, 30 Oct 2001, Mark wrote: >> >> maybe, restore the repository from backup, prior to the command run. >> > There is just the daily backup of the repository -- I do not want to > redo the changes of the last day... I suppose you could try and produce a huge recursive context diff of the last days' changes, and the apply those as patches to the version from backup tape ... >> -or- maybe release version 3 of your software instead of version 2, what >> happened to version 2 can become folklore in your company >> > probably the best way Or go one better, and bump RCS revisions to 20.0 for the 2.0 product, revision 21.0 for the 2.1 release, etc. Philip -- The mail transport agent is not liable for any coffee stains in this message ----- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Organizing many CVS projects: How to?
> James Knowles writes: >> >> I've struggled a bit to figure out how to best set up CVS to handle these. I >> can create a zillion projects under a single CVSROOT location, but that very >> quickly gets messy. However, it does have the nice benefit of only one >> $CVSROOT environment variable. Which is irrelevant, since a checked-out module 'knows' its CSVROOT, so you don't see it and it doesn't matter if they differ across projects. If it's all the same to you, why not keep the hierarchy, where the top few levels are just for organizational purposes (and eg. would not be visible in released products). You can use the CVSROOT/modules file to have aliases and combinations of bits and pieces at lower levels into new 'checkoutable' configurations. > Why do you say it gets messy? Pretty much the only reason to consider > multiple repositories is if you need to have different things in the > administrative files in $CVSROOT/CVSROOT. More importantly (in a multi-user enviroment at least) for different access rights/policies. The way I look at repositories is as a unit of authorship/authority, where as a module is a unit of logic or (domain) functionality. Philip -- The mail transport agent is not liable for any coffee stains in this message ----- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Anybody any idea on how to set back a revision number?
On 30 Oct 2001 16:12:15 +,
"me" == Philip Lijnzaad <[EMAIL PROTECTED]> wrote:
me> If you change this to
me> head2.1;
me> everywhere, things will probably work out fine.
Oops, wrong. You also have to change pretty much all the lines that contain
just the revision number ('3.x' in your case) to 2.x, and you also have to
change all the lines that look like ``next 3.x;'' to ``next 2.x;''.
In all likelihood, it is not worth the trouble, so the short answer to your
question is still: don't do it, it's mostly pointless. Cheers,
Philip
--
The mail transport agent is not liable for any coffee stains in this message
-----
Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Anybody any idea on how to set back a revision number?
> Does anybody know how I can set the revision number to be 2.0 back > from 3.0 ? In general, the individual file revision numbers are, or should be, largely irrelevant; the thing that is really needed are the tags (because in general, the revision of one particular file is meaningless, since it has to be consistent with many other files). But I can imagine that there may be cosmetic reasons for controlling this a bit. > -- Do I need to create a script that I must run over the > CVS repository? You're in dire straits ... If nobody made any changes (let alone branches or tags) until now, you may be able to get away with the following: The *,v files in your repository will all start with the following line: head 3.0; If you change this to head2.1; everywhere, things will probably work out fine. If not (i.e., if there were changes or tags, you just might be and globally change all the 3.x to 2.x inside the 'administrative' part of the ,v files. But I'd be very, very wary of this). But it might be a good idea to make a backup in case you screw up (and of course, disable access to the repository and tell everyone to remove their working copies). Philip -- The mail transport agent is not liable for any coffee stains in this message ----- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Sharing
Bryon Lape wrote: > Ah, the typical Unix answer"roll your own"... Do I detect an ever so slight hint of sarcasm here ? If so, you are, of course, perfectly welcome to go elsewhere and pay for your support and bitch about it. People try to be helpful for free, and a modicum of politeness is appreciated. Regards, Philip -- The mail transport agent is not liable for any coffee stains in this message ----- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The CVSROOT field
> " > It should be something like [EMAIL PROTECTED]:/cvsroot. > Never enter the ":pserver:" or ":kserver:" directly, use the radio buttons > instead. > " > I don't really understand that, do I have to create an environment variable > that contains the path to CVS ? no, to the repository; it might be on any machine on the Internet. I think this kind of path only works for machines that you log in to (prolly a Unix machine). > What "[EMAIL PROTECTED]" stands for ? username 'alexp', loggging in to machine 'cvs.strata3d.com' to gain access to the CVS repository on that machine that is to be found in directory /cvsroot (there might be several repositories on that machine). I'm sure you can access local disks containing repositories; though I don't know how to do this under M$ os's. Under Unix, CVSROOT sould contain the path to the repository. Philip -- The mail transport agent is not liable for any coffee stains in this message - Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to Create Report of Updated Files
> The 'cvs update' command will update all files to match the current > versions in the repository. Is there a way to get a report of what > update would do, without actually performing the update? I'd like to > see a list of what cvs is going to do before actually doing it. cvs -n up This is actually the standard way to find out which of your files are out of date or locally modified. (many cvs commands will take a global '-n' option that actually shows what would be done, but not do it). Philip -- The mail transport agent is not liable for any coffee stains in this message ----- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cannot open file Utils.pm for comparing: No such file or directory
Philip Lijnzaad <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Dear all, > > I have a strange problem: I can cvs update and commit and everything without > a problem, but when doing a cvs diff, I get: > > cvs [server aborted]: cannot open file Utils.pm for comparing: No such file or >directory > > The CVSROOT is ':ext:[EMAIL PROTECTED]:/ebi/cvs' and my CVS_RSH is ssh. > > What can cause this kind of behavior ? It looks a bit like the repository > side can't create a temporary file to 'diff' against. Turns out that I had ''diff -kk'' in my ~/.cvsrc. Out-commenting this made the problem go away. Incidentally, this problem only occured on Solaris and TrueUnix, not SGI and Linux. The version I used it with was 1.10 halibut. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: -chroot patch for CVS ?
> The author of rsync has a 'pserver' wrapper program which chroots before > running cvs pserver. It's used for the samba and rsync anonymous cvs > access. See the note about 'how it's done' on this page: > http://www.samba.org/samba/cvs.html > It directs you to check out the code itself from cvs: > cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot co pserver > I've examined it a while back but have not put it into practice. Brilliant, thanks! (unfortunately, http://www.samba.org is currently not very responsive, though, so I'll have to wait before trying). Incidentally, in case it interests people (or posterity browsing groups.google.com :-), I also found another patches/projects that would appear to be relevant to securing public CVS access: idx-chrooted-ssh (http://www.idealx.org/prj/idx-chrooted-ssh-cvs/index.en.html) cvs-nserver (http://alexm.here.ru/cvs-nserver/) Enjoy, Philip -- The mail transport agent is not liable for any coffee stains in this message ----- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
-chroot patch for CVS ?
on Google Groups I found the following: From: Justin Wells <[EMAIL PROTECTED]> Subject: patch to make CVS chroot Date: 2000/08/04 Message-ID: <[EMAIL PROTECTED]>#1/1 Original-Date: Fri, 4 Aug 2000 12:18:58 -0400 Original-Message-ID: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" I've patched CVS 1.10.8 so that it supports a new command line option: cvs --chroot /some/chroot/root/ The patch is attached to this email. I hereby grant permission to everyone in the entire world to use this patch in whatever way they like for whatever However, nowhere could I find this patch. Is it still relevant, and if so, where could I find this ? If not, I'd be interested in other mechanisms to secure pserver access. Many thanks in advance, Philip -- The mail transport agent is not liable for any coffee stains in this message ----- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cannot open file Utils.pm for comparing: No such file or directory
Dear all, I have a strange problem: I can cvs update and commit and everything without a problem, but when doing a cvs diff, I get: cvs [server aborted]: cannot open file Utils.pm for comparing: No such file or directory The CVSROOT is ':ext:[EMAIL PROTECTED]:/ebi/cvs' and my CVS_RSH is ssh. What can cause this kind of behavior ? It looks a bit like the repository side can't create a temporary file to 'diff' against. Philip -- The mail transport agent is not liable for any coffee stains in this message ----- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ": ambiguous redirect" error
> I've tried to add the ability to have a place that always contains the > updated files, as described in the CVS ducument in section C.7.2 and placed > the line > ^Test (date; cat; (sleep 2; cd /home/rabusch/testing; cvs -q update -d) &) >>> $CVSROOT/CVSROOT/updatelog 2>&1 > in the loginfo file, but it didn't work, and when I commit something, I get > the message ": ambiguous redirect". I think that should be: ^Test (date; cat; sleep 2; cd /home/rabusch/testing; cvs -q update -d ) >> $CVSROOT/CVSROOT/updatelog 2>&1 & (untested though). Make sure that the default shell for this user is right (sh-style, not csh). I think the extra pair of braces is needed, so I left them out. Philip -- The mail transport agent is not liable for any coffee stains in this message --------- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Soft link in CVS
> Hi, > =20 > Does anyone know of the best way to support soft link in UNIX in a > CVSROOT ? > =20 > I want some files that reside in one directory to be linked to files > exist in other directory. When I checkout/update/commit the files in any > of the directories it will update the second one. > Thanks=20 Kaz Kylheku posted this here a while back. I haven't used it, but it does look useful (and I'd be interested in feedback on it). Cheers, Philip From: [EMAIL PROTECTED] (Kaz Kylheku) Subject: possible solution! (was Re: symbolic links in repository) Newsgroups: gnu.cvs.help Date: Fri, 07 May 1999 17:35:51 GMT Organization: Psycho-Neurotic Institute for The Very, Very Nervous Path: hgmp.mrc.ac.uk!server1.netnews.ja.net!server5.netnews.ja.net!HEAnet!newsfeed.esat.net!nntp.primenet.com!newsfeed.direct.ca!newsgate.direct.ca!kaz References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> X-Newsreader: slrn (0.9.4.3 UNIX) Lines: 38 NNTP-Posting-Host: 204.239.179.1 X-Trace: newsgate.direct.ca 926098551 204.239.179.1 (Fri, 07 May 1999 10:35:51 PDT) NNTP-Posting-Date: Fri, 07 May 1999 10:35:51 PDT Xref: hgmp.mrc.ac.uk gnu.cvs.help:74 On Fri, 07 May 1999 00:20:29 GMT, Kaz Kylheku <[EMAIL PROTECTED]> wrote: >Say I have a file called ``xyzzy.c,v'' inside the repository for module >``foo''. And I symbolically link to it from module ``bar''. If two programmers >are concurrently commiting the file in separate modules, or if one is commiting >while another one is reading, there will be a problem. I mean, looking at >foo/xyzzy.c,v alone, you have no clue what links may be pointing at it, short >of doing an exhaustive search. It would be good if CVS would go to the >directory where the file actually resides and create the lock there, but it >doesn't seem to do that. I have figured out an ingenious way to use symbolic links among files in modules and have correct locks. This method is based around the ``LockDir'' feature of CVS 1.10. Here is how it works: say you have two modules foo and bar which have links (hard or sym) to each other's ,v files in the repository. In order to have consistent locking, you edit your CVSROOT/config file to set up a separate locking hierarchy using LockDir=. Then you create that top level lock directory and check out foo and bar. This will create the lock directory structure. Now here is the trick: you now perform some symbolic link magic within the lock directory structure. If foo and bar share files, then what you want is to merge their lock directories so that whenever foo is locked, bar is also locked. The way you do this is to turn one of them into a symbolic link to the other. So from the point of view of locking, there is now only a single directory for both modules, even though the are distinct directories. Simply rmdir bar, and then ln -s foo bar. CVS is fooled; it follows the symbolic links in the LockDir hierarchy and creates its lock dirs and files wherever you want it to. For more then two modules, you simply have to do more merging by transitive closure of the sharing relation. So if module A and B share files, and module B and C share files, you have to treat things as though A and C share and create a single locking directory for A, B, and C. (Of course, this merging of locks reduces concurrency. Looks marvellous to me so far. Any comments from CVS experts? -- The mail transport agent is not liable for any coffee stains in this message - Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: commit as root.
> Hello everybody! > I have a question. I need to work as root in a specific project. (I would try to find another solution, frankly) > But, when I > try to commit the modified files, I get a message telling that commit cannot > be done as root. Are you using the :ext: protocol, or direct file access? If the latter, switch to :ext:. If the former, are you using rsh (boo! hiss! all the more if you're root, although usually root acccess for the r-commands is disabled)? If so, put something like the following in your .ssh/config: Host rootcvs HostName some.machine.co.uk User root Then check-out as: cvs -d ':ext:rootcvs:/path/to/cvsroot' co the-module (and/or change the contents of CVS/Root to this above string). From this on, things should work, provided that ssh allows root access (which I'm not at all sure about). You will probably want to add localhosts's identity.pub to cvsroot host's ~root/authorized_hosts, and also you'll want to run an ssh-agent to take care of passwords. Cheers, Philip -- The mail transport agent is not liable for any coffee stains in this message ----- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SQL shema
> hi, > I was wondering how u people are working with SQL-shema changes... say I > have it under CVS control... > How u automate adding/removing tables and fields, and as special case > populating some of the tables...!! CVS is not a build tool. To make sure that all the schemata and the application code (all of it) is consistent, you really have to have regression tests that exercise all of the table definitions. Only when all regression tests pass would you commit *.sql and application code to CVS (or rather, it would be commited earlier, but given it some significant tag or branch when everything flies again). This is not trivial, especially if people have to hand tweak the schema's inside the databases (which is not uncommon). If they do so, dump the schema from the database, can commit it. I would suggest using a layer of view definitions (to be used by the application code) can help insulate you from schema churn. A final scenario is that the tables definitions are embedded in the applications (e.g. if you have some object layer). In this case, *.sql is a derivation, hence should not be stored under CVS. -- The mail transport agent is not liable for any coffee stains in this message ----- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 2.0?
> Are there any official plans for CVS 2.0? What is going on with future > development? I dunno ... some would argue that CVS has reached the end of the line (which, incidentally, is not a bad thing). Major new functionality requires too much fundamental architecture changes. SubVersion is touted as the heir to CVS's throne http://subversion.tigris.org/ (they recently went self-hosting, which is promising). Cheers, Philip -- The mail transport agent is not liable for any coffee stains in this message --------- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS, NFS Filesystem, and failover
> I've heard it mentioned on this newsgroup that mixing NFS with CVS is a bad > idea. Running CVS with the repository and/or the local working copies on NFS-mounted disks is fairly common, I would say. But it won't be immune from general NFS problems, of course. I once tracked such a problem down to a $CVSROOT/SomeModule/Some/Sub/Dir/.nfsSomeFilelock still lying around; removing it manually solved it. I've seen similar things in user directories. > The idea in mind is a CVS server has a repository that is NFS mounted from > an external storage system. > (CVS server) (Backup CVS server) >| >| > [NFS] >| >| > (Server exporting) > (NFS /cvs filesystem) > The goal here is to have; > 1. A backup CVS server, in case the first one fails. Mmm ... I'm not sure how this should work, I can imagine that you can get concurrency of locks? > 2. Disk storage from an external source (such as a NetApp system), that hase > high capacity, is used for several different storage systems, and can > centralize backups. yes. For e.g. ext or pserver access, it would be nice to have direct disk access, though. > 3. Possible to have backup CVS server come on line if the primary CVS server > fails (mounting the NFS system, and taking over the IP address of the first > machine) Again, locks that get stuck may become a problem. Philip -- The mail transport agent is not liable for any coffee stains in this message - Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Microsoft Visual Studio
>> Hi >> >> From everyone there using CVS with Visual Studio, what aproach are you >> using? Igloo? Other tools? None, but I just note that there is vscvs; doesn't seem very active or mature though. See vscvs.cvshome.org. Philip -- The mail transport agent is not liable for any coffee stains in this message ----- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: files in CVSROOT
>> Brilliant, that was what I needed. I remembered there was something like it >> (maybe even in 1.9?), but the CVS manual does not explain it under the >> 'Administrative Files' heading, but under the ``CVSROOT storage'' node. > It looks to me like it's explained there: > <http://www.cvshome.org/docs/manual/cvs_18.html#SEC154> Excellent, it's in a more obvious place than for the CVS 1.10 manual. I wasn't aware that CVS 1.11 was now the latest and greatest; sorry. Cheers, Philip -- The mail transport agent is not liable for any coffee stains in this message ----- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: files in CVSROOT
> To get arbitrary files checked out automaticly, you'll need to use the
> "checkoutlist" feature.
Brilliant, that was what I needed. I remembered there was something like it
(maybe even in 1.9?), but the CVS manual does not explain it under the
'Administrative Files' heading, but under the ``CVSROOT storage'' node.
An @xref{bla} in ``Administrative Files'' to CVSROOT storage would be useful.
Philip
--
The mail transport agent is not liable for any coffee stains in this message
---------
Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: files in CVSROOT
> [Larry Jones - Tue at 02:24:29PM -0400]
>> Just checkout CVSROOT like you would any other module/directory and go
>> to town. :-)
> You forgot the most important part; edit the files, and then "cvs commit".
> CVS automaticly updates the "live" files in $CVSROOT/CVSROOT.
I believe this is only the case for cvs 1.10; cvs 1.9 seems to only keep an
automically cvs update-d copy inside $CVSROOT/CVSROOT for the standard
{log,commit,etc}info files, not for manually added files. Or did I miss
something ?
Philip
--
The mail transport agent is not liable for any coffee stains in this message
-----
Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: different sites with 50% common files
> Hi > 2 sites having 50% of total files as common so put the common stuff in CVS repository somewhere, and make site A and B use CVS for the common stuff. > modifying one of the file in one site to > same change should get reflect into other site > i.e. want to synchronize common-files in both the > times If this is for developers, they can just cvs update whenever needed. If this is something to be done automatically (with no risk of merge conflicts), this is not CVS's job in life; use rsync or rdist instead. Cheers, Philip -- The mail transport agent is not liable for any coffee stains in this message --------- Philip Lijnzaad, [EMAIL PROTECTED] \ European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: adding a directory tree to existing module; checkout of subdirectory
> hi! > suppose you have some module in the repository; > (doing a checkout of the whole module and configuring some apache files --> > voila it works) > now i would like to add an other application (directory tree with code) from > another server > into the same module of the main server into a certain directory. do you mean 'add forever' ? If so, just use cvs import (which allows you to import things as a sub(sub(sub)) directory of an existing module. You can still re-import from the same source, so it's not really 'forever' anyway. > desired result: > server1:/home/repository/module1/some/.../path/applicationX > with ability to maintain the subdir of module1 from > server2:/home/applicationX Look into the documentation of ``the modules'' file (e.g., $CVSROOT/CVSROOT/modules, or the manual or FAQ). You can create aliases and lump things together for checkout. Alternatively, use a script that creates the appropriate symbolic links in the checked-out copies. Philip -- The mail transport agent is not liable for any coffee stains in this message --------- Philip Lijnzaad, [EMAIL PROTECTED] \ European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Two questions, simple I hope
> Hello all, > In an effort to streamline some of our release proceedures, I'd like to > collect all the check-in notes from a particular date or version forward. > I'm primarily a WinCVS user and can't seem to find a simple way to do it > there. Is there one, or one from the CLI? If WinCVS has a command line interface, would cvs log -d '1 year ago' [file(s)] work? > Another issue recently arose that I'd like to help out my admin with. We've > hired a 3rd party consultant to beef up some of our db code, and as a result > they'll need access to our CVS repository. However the CVS server is inside > our firewall and that's not open to negotiation. Any pointers here? the only thing I can think of is to give the consultant ssh access, and make him use setenv CVS_RSH ssh (or whatever the equivalent is in WinCVS). > Is there any way to have two severs maintaining a single repository? Why, how ? if security is a concern, don't use a pserver in the first place; just use the ext protocol, which uses plain ssh access, and doesn't require servers. Philip -- Real programs don't eat cache (Malay) ----- Philip Lijnzaad, [EMAIL PROTECTED] \ European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: how to handle more than one project??
> On Fri, Sep 14, 2001 at 12:31:44AM +0530, P.V.Sridhar Reddy wrote:
>> My problems are:
>> 1) How do i create the repositories???
> cvs import a file to start with (say, a readme explaining what the project
> is). Or do something like "cvs co -l . ; mkdir foo ; cvs add foo"
Often it is useful to first create an empty repository as
cvs -d /the/cvs/root/directory init
this will populate the $CVSROOT/CVSROOT/* files as well.
>> 2) I dont want the developers of one project to be able to do any kind of
>
>> CVS operations on other project.
>>
>> 3) Within in a project, i want only one person to be able to checkin, and
>> for others only checkout permissions.
> Both of these can be handled with usual unix permissions. Use g+rs on the
> top level directory, for instance.
why g+s ? g+rx would seem more logical (g+s sets directory-groupid on file
creation, but files won't be created).
If you have a big directory tree, do
chmod -R go+r,go-w $CVSROOT
find $CVSROOT -type d -exec chmod go+rx,go-w {} \;
Philip
--
Real programs don't eat cache (Malay)
-
Philip Lijnzaad, [EMAIL PROTECTED] \ European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Stickiness
> Does someone have a good definition of what > "stickiness" is in relation to CVS? Thanks. The CVS repository doesn't know or care what you or others check out of it; it is typically the latest stuff on the default branch, but need not be. The details of your check-out are stored locally (in CVS/Entries). If something (i.e., a file; nothing else can be) is sticky, it simply means that it is checked out using a non-default setting. This can be either a different branch, a different revision (e.g. 3.2, rather than 'the latest on the default branch), or a different date. Perhaps worth repeating here: the CVS repository knows absolutely nothing about who checked-out/updated which versions where. (Well, actually, it might have recorded it somewhere, but it certainly doesn't care). All the 'state' of a repository is stored in the topology of the directories under $CVSROOT, and in the contents of the *,v files in this tree; nowhere else. Philip -- Real programs don't eat cache (Malay) ----- Philip Lijnzaad, [EMAIL PROTECTED] \ European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
