Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Oops, The sample modules file entry got messed up. It should be file: b32awt b32awt b32awtu -a util/awout.for util/clout.for util/pageno.for Proj_b32awt &b32awt &b32awtu Regards, Erik -----Original Message----- From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Warren, Erik Sent: Thursday, November 11, 2004 1:29 PM To: cvsnt at cvsnt.org Subject: RE: [cvsnt] Modules and Shared Libraries - tagging strategy? Tim, I use a very similar strategy with my FORTRAN code. We keep project specific files in a module bearing that project name (e.g. module b32awt contains files b32awt.for, b32cfg.for, b32n05.for, etc) but there are many files which are used in all our programs and they reside in the Util module. Nearly every project we have uses several items from the util module but no project includes all the files in the util module. We therefore create an alias module for each project which includes the specific files within the Util module which are used for that project. So for the b32awt project we have the following entries in our modules file: b32awt b32awt b32awtu -a util/awout.for util/clout.for util/pageno.for Proj_b32awt &b32awt &b32awtu This way when you checkout Proj_b32awt you get the util module with only those files used in the b32awt project. We tag our code at each release with Rel_<project name>_<major>_<minor> e.g. files used to build b32awt.exe v2.3 would get tag Rel_b32awt_2_3 This tag can be done 2 ways. First, you can checkout your project using the ampersand module Proj_b32awt and apply your tag to that module in your sandbox. Second, you can use rtag to tag the ampersand module on the server. This method does require care because you might build a file using an out of date file in your sandbox but the up to date version on the server gets the tag. Also, the rtag command breaks when using ampersand modules if you use some more recent cvsnt executables. I use the second method and my server and clients are all cvsnt 2.0.34 I have not tested this with all subsequent versions but I do know that 2.0.51 and subsequent all have the rtag problem. I may go to the first method if the rtag issue is not resolved so that I can continue to take advantage of the improvements that continue to go into CVSNT. Regards, Erik Warren -----Original Message----- From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Williams, Tim Sent: Thursday, November 11, 2004 11:12 AM To: cvsnt at cvsnt.org Cc: Williams, Tim Subject: [cvsnt] Modules and Shared Libraries - tagging strategy? Hi folks, I have a question about how best to use and manage a code library that is used in multiple projects. Take for example two projects that share a code library. The projects are PROJ1 and PROJ2, both in the same repository. They share a common library I'll call PROJ-SHARED that I check out with each project using ampersand module specification. My modules file would look like: PROJ-SHARED -d PROJ-SHARED PROJ/PROJ-SHARED/SAS PROJ1-MAIN -d SAS PROJ/PROJ1/SAS PROJ2-MAIN -d SAS PROJ/PROJ2/SAS PROJ1 &PROJ1-MAIN &PROJ-SHARED PROJ2 &PROJ2-MAIN &PROJ-SHARED So if I checkout PROJ1 in my sandbox I get: ....\williamstim\PROJ1\SAS\... ....\williamstim\PROJ1\PROJ-SHARED\... Now let's say I am ready to tag PROJ1 for a Release. We use a tagging convention: Release1, Release2, Release3.... for all of our projects. I want to tag PROJ1 with the tag "Release1" and I do this by applying the tag to the \SAS folder my sandbox (*not* to the \PROJ1 folder, because the files in PROJ-SHARED are used in other projects that may not be ready for release, or have already gone past Release1. If I checkout PROJ1 to a production area using the tag "Release1" I get all my PROJ1 files, but not any files in the shared library, since I did not tag it "Release1". The only solutions I see at the moment are: 1. Change the tagging convention so I tag at the PROJ1 level and tag both the \SAS and \PROJ-SHARED folder in the sandbox, using a tag that includes the project identifier. For example, Release1 becomes PROJ1_Release1 or similar naming convention. In this way, the shared library gets tagged appropriately for each project that uses the shared library. This would break naming conventions we already have in place, so I am hoping for another solution. Some of our project identifiers and tags are already long strings, so the resulting tag names become longer and more prone to user entry error. (E.g : FOO100XX-FOO01_InterimRelease1 instead of simply: "InterimRelease1") 2. Maintain the shared code library as a completely separate module. This would not allow a strong link to the project moved into production, since the library may not be tagged with the same tag as the project (PROJ1). In fact, if we do not change our naming convention, it would not be tagged at all!? (bad!) I would enjoy hearing from anyone who uses shared code libraries between multiple projects and how they manage them using CVS. Thanks in advance, Tim SAS Systems Administrator PRA International Charlottesville VA, USA _______________________________________________ cvsnt mailing list cvsnt at cvsnt.org http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt cvsnt downloads at march-hare.com https://www.march-hare.com/cvspro/en.asp#downcvs @CVSNT on Twitter CVSNT on Facebook