[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Common code across multiple projects
From: |
thomas . maciejewski |
Subject: |
Re: Common code across multiple projects |
Date: |
Wed, 28 May 2003 08:09:47 -0400 |
actually I wouldnt use ln -s for CVS
Firstly I would be worried that CVS would get confused
secondly it just doesnt "feel right"
what you are suggesting can be accomplished using the modules file under
CVSROOT
$CVS/CVSROOT/modules
and using & modules
where I can have common
ProjectA &common
ProjectB &common
but again this doesnt work for the versioning.
Who is in charge of what goes into CVS?
I think this would be huge if CVS had the ability to branch via modules
I may be willing to work on this.
Please let me know
The other solution is to jar up common ( yes this is java ) and then to
only add the jars into CVS as needed.
I would prefer to have the source however
Tom
Srinivas P shenoy
<address@hidden To: address@hidden
om> cc: address@hidden
Subject: Re: Common code across
multiple projects
05/28/2003 12:14
AM
On Wed, 2003-05-28 at 01:00, address@hidden wrote:
> I have a related question to this to which I am seeking an answer.
>
> I have two projects: ProjectA and ProjectB
> both of them use part of a common code base that is in a project called:
> Common
>
> I would like to set up CVS that I can have a reference to Common shared
by
> both ProjectA and ProjectB
> something like:
>
> ProjectA/Common
> ProjectB/Common
>
> and common being in its own project:
> Common
>
you can create softlinks to common project in your CVS repository for
ProjectA & ProjectB.
some thing like this.
lets say your CVS is placed in /home/cvs/
in /home/cvs/ you have
CVSROOT/
common/
ProjectA/
ProjectB/
now in Project A you can create a symbolic link to point to common
$>cd ProjectA
$ProjectA> ln -s /home/cvs/common common
Similarly for Project B.
> Common code should be able to grow on its own and the current development
> branches and main trunk of ProjectA and ProjectB should see these
changes.
> I should be able to go into ProjectA/Common and make a change and commit
> and when I update from ProjectB I should see these changes.
>
the symbolic link will work for you just the way you want it. any
changes made in ProjectA/common/ or ProjectB/common will reflect in
common & vice-versa. There may be problems if two different persons
modify same file belonging common/zzz.x in Project A & B, and try to
check in. ( every one have to make sure they are locking files using cvs
edit so that only one person has access to the common/ files at a given
time )
any one else using softlinks in cvs repository ??
any draw backs in this approach ??
please correct me if i am wrong.
> However when I create a production branch I want to have have my own copy
> of common.
> That is, once I do the production branch and then make a production bug
> fix
> to ProjectA/Common I do not want it to show up in Common nor in
> ProjectB/Common
>
This i am not very sure how to go about it. just a guess.
may be you can tag the Project A & Project B with different branch tags.
using cvs tag -b <tag name> Project A/common
then check out Project A/common in local sand box with tag name.
you should get the branch. fixs made will be in this branch.
may be you can create a temporary CVS repository , have a common,
Project A & B modules in that and try creating a symbolic link for
common in Project A & B. Then try tagging Project A & B with different
tags.
> I tried to do this via & modules but I found that even when I branched
> ProjectA common
> was not also branched within there so if updated the branch I would get
the
> current development
> version of Common and if I check in a production bug fix it would then be
> part of the main production branch
>
> Does anyone have a solution to this?
>
> I am sure this is fairly common to most companies that have multiple
> projects but wish to have code re-use
>
> Tom
>
>
>
>
>
> **********************************************************************
> The information contained herein is confidential and is intended solely
for the addresse(s). It shall not be construed as a recommendation to buy
or sell any security. Any unauthorized access, use, reproduction,
disclosure or dissemination is prohibited.
> Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall
assume any legal liability or responsibility for any incorrect, misleading
or altered information contained herein.
> **********************************************************************
>
>
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
>