Question about links
This may be a wierd one. If there are two different repositories on one machine, would it be a bad thing to link part of one repository to the other. I.E. if there is a module in repository A call whatever, and the dir is linked to repository B will the cvs server (we are using pserver method), handle it correctly? Harold Lynch ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about links
--- Forwarded mail from [EMAIL PROTECTED] Lynch, Harold [EMAIL PROTECTED] writes: This may be a wierd one.=20 =20 If there are two different repositories on one machine, would it be a bad thing to link part of one repository to the other. =20 I.E. =20 if there is a module in repository A call whatever, and the dir is linked to repository B will the cvs server (we are using pserver method), handle it correctly? I will assume that by 'linked' you mean that one of the repositories has a symbolic link to the directory in the other repository... You will NOT be able to use LockDir with either of the repositories involved. You will also need to take care that the commit criteria of your CVSROOT *info scripts are consistent across both repositories... You will also want to have a consistent understanding of how your users map across both repositories. In fact, you will probably end up with a great deal of CVSROOT being duplicated between the two to get this to work. So, you need to ask yourself why you even bother to have two separate repositories on the machine... That said, I have not tried the setup you suggest. It might work, but it is probably not the best idea I have seen mentioned. I have used such a method successfully in the past, but I would not recommend it. It's much better to write the overlap into your modules definitions, though that method also has its limitations. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
How to delete multiple tag
How to delete multiple tag on project/module from a given point of time. e.g. I would like to delete all the tags placed on project $CVSROOT/project1 from Jan-2003 Jun-2003 Thank you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to delete multiple tag
[EMAIL PROTECTED] writes: How to delete multiple tag on project/module from a given point of time. e.g. I would like to delete all the tags placed on project $CVSROOT/project1 from Jan-2003 Jun-2003 RCS (and thus CVS) does not track when tags were applied. -Larry Jones I'm crying because out there he's gone, but he's not gone inside me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update times
On Fri, Nov 14, 2003 at 01:55:55PM -0800, Richard Pfeiffer wrote: The project in question (Proj A) and one I'm using for comparison look like this: Proj A is half the size as Proj B, but did have more directories. I might have to find out just how many more. Proj A took 2m15s to checkout, Proj B took 10m30s. Proj A took 1m14s to update, Proj B to 1m20s. How long do the du -k commands take? (Make sure the data is *not* in the buffer cache.) The time for a du is proportional to total number of filesystem objects, not to directories specifically, but the numbers might still be interesting. So Proj B is twice the Kb, takes 5 times longer to checkout but updates in the same time as Proj A. I'd be interested to know counts of files and directories for both projects. Not sure what use all these numbers would be, but they couldn't hurt :-) I would just write it off to # of dirs, but users claim it was much faster last week. I'll have to check and see if they checked in a bunch of files all in seperate directories, etc. Hmm, it just occurs to me. How about changes on the client side? Could it be that the project-A people (but not the project-B people) installed some app on their Windows boxes that interacts badly with WinCVS? Or in the network? Is there a flaky hub in the project-A room, or is someone there downloading DVDs in the background and saturating their uplink? :-) Could indivdual file or directory sizes have any bearing? Sure, they could be confusing the issue. If project B has N large files, and project A has N small files, I'd expect to see something very roughly like you're seeing -- though the twice the KB, 5 times longer to check out part is mystifying. But that aside, I'd expect the update times to be similar (assuming, of course, that the sandboxes were already up to date). Unlike actually fetching updates, merely checking up-to-dateness isn't proportional to the file sizes. Does a checkout's locking structure differ from an update's locking structure? I wouldn't think so, but if that was true, I would think the co and update times would be proportional for these two projects. Didn't someone say that co locks the whole tree, but update only locks one directory at a time? I don't see how that would affect things, though. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
