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.
Hi Curt! Thanks for the info. You have an interesting challenge! Our shared code is mostly plain text so its hard (impossible?) to prevent folks from making changes to the shared library in their sandboxes. I have a hard time now with folks editing code in the Production folder instead of their sandbox (SAS programmers don't generally come from a programming/computer science background). If we treat the shared library as a separate module that they import into their project, any changes they make may never make it back into the shared, separate module for availability in other projects. That is why I liked the approach for aliased modules. However, your points about the separate module do have a lot of appeal. In addition to code shared among projects that belong to a single client, we may also have code we wish to share across multiple clients and their projects. These may span several offices and repositories, so in a very short while I will be in a situation similar to yours and I want to choose a solution that is scalable. I'm now leaning toward the shared library as a separate module. When starting a new project, the lead programmer would check out the shared code to a separate location, then copy that code into the new project. CVS Add, CVS commit and manage code from the "shared" module within the individual project from that point forward. Its far from ideal. I'm likely to change my mind again in a few minutes....:-) Thanks again! Tim -----Original Message----- From: Lehman, Curtis [mailto:CLehman at carrieraccess.com] Sent: Thursday, November 11, 2004 11:44 AM To: Williams, Tim; cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: RE: [cvsnt] Modules and Shared Libraries - tagging strategy? My company is currently trying to resolve basically the same problem. We have the added problem that the multiple projects that the library needs to be shared among reside on different physical CVS servers in different states. That makes the alias checkout method you describe below not viable. All the projects our library goes into have differnt directory structers, nameing conventions, and tagging policy's. We are solving the problem by treating the library as it's on project. It has it's own version and tagging system. The library will will have releases that are delivered to each project. Each project that uses the library can then check-in the .a and .h files into there project however they like. (We also will deliver an api and other documentation with a release.) All the other projects treat our library like a third party software. Some of the benifits of this are: 1. Faster builds becasue the projects that use the library don't have to recompile the library every time, just link it. 2. The projects can't modify the code, they have to work through the group that own's and delivers the library. This helps keep the code generic and reusable. We are planning on useing doxygen to deliver a read only version of code in case they want to look at how the code works. Hope this helps, - Curt -----Original Message----- From: Williams, Tim [mailto:WilliamsTim at PRAIntl.com] Sent: Thursday, November 11, 2004 9:12 AM To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook 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