[cvsnt] Re: Modules and Shared Libraries - tagging strategy?

Bo Berglund Bo.Berglund at system3r.se
Fri Nov 12 09:42:55 GMT 2004


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.


OK,
can you then explain how using import can make it possible for the developers
to update the common code and commit it to the original location???

To do what you propse means the following operations (correct me if wrong):

1. cvs export the common files you need for the new project into a folder
   in the new project sandbox.

2. cvs import these folders and specify the location to be a part of the
   new project module (a submodule).

With these operations the common sources are effectively disconnected from the
new module and what you have accomplished is to create a duplicate of the common
code inside the new project.
If someone else using the common code finds and corrects a bug and commits his
changes it will not be reflected in your project, nor will it be committed to
the original common folder. Thus noone else will benefit from the bugfix...

I still think using import is not appliable in this circumstance.

/Bo

-----Original Message-----
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org]On Behalf
Of torsten at tiscali.dk
Sent: den 12 november 2004 08:48
To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
Subject: Re: [cvsnt] Re: Modules and Shared Libraries - tagging
strategy?


Bo Berglund wrote:

>On Thu, 11 Nov 2004 22:27:37 +0100, Torsten Martinsen
><torsten at tiscali.dk> wrote:
>
>>We also used this approach previously, but have found that using "cvs

>>import" is a superior solution - after all, cvs import was designed for

>>tracking third-party sources.
>>
>
>No, you don't understand the situation!!
>There are no 3rd party sources involved at all. Instead we have many
>projects that use common functionality, which we have stored in a
>"Common" repository. We have utility functions and we have common
>database classes and things like that.

Yes, I *do* understand the situation. This is exactly the same scenario
that we have. Understand that "third-party" can be relative to the *project*,
not necessarily relative to the *organization*.

>The real projects are stored in various other repositories, mainly
>because of isolation issues when we started CVS. This precludes using
>modules and modules2....

Exactly the situation we have.

-Torsten


_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook