RE: Possibly not possible

[Thornley, David]

> -----Original Message-----
> From: Emmanuel van der Meulen [mailto:address@hidden
> Sent: Thursday, October 04, 2001 2:13 PM
> To: address@hidden
> Subject: Possibly not possible
> 
> 
> requirement, and then d) where this is not possible but you 
> find this of use,
> could CVS please be extended to cater for this requirement - 
> then how would I go
> about requesting this as an extension to CVS.
> 
You would go about it by providing working code, along with
supporting documentation and test cases.  CVS is open source
non-commercial software.  If you do not have the resources to
provide the code yourself, you can either try to talk somebody
else into it or pay somebody to do it.

> Here goes;
> 
> Overview;
> I want to make use of several repositories (at second level 
> of structure)
> intercommunicating with each other via a root (at top of 
> structure), with
> working directories (third level of structure) feeding off 
> their repositories
> (at second level), thereby keeping different versions of 
> source separate but
> enabling updating across separate 'routes' of development.
> 
Why do you need different repositories here?  If you have a
specific need for actual separate repositories, CVS isn't going
to work for you.  Could you use different branches in one
repository?
> 
> Detail of CVS repository and working directories;
> 1).
> ProdSource - CVS root
> ReleaseSource - CVS working directory with ProdSource as CVSROOT
> 
> 
> 2).
> QASource - CVS root as well as CVS working directory with 
> ProdSource as CVSROOT
> QAWorkSource - CVS working directory with QASource as CVSROOT
> 
It seems odd to me that you would want QA to have its own code
base.  One would think that QA would normally use the production
code, and possibly sometimes the developer code.
> 
> 3).
> DevSource - CVS root as well as CVS working directory with 
> QASource as CVSROOT
> DevWorkSource - CVS working directory with QASource as CVSROOT
> 
> 
> Usage of above;
> With above configuration, whenever source is COMMITted to 
> ProdSource, from
> either ReleaseSource or QASource, those changes could then be 
> used to UPDATE
> source in either ReleaseSource or QASource - enabling that 
> when changes are
> applies from ReleaseSource, those are also available to 
> QASource and visa versa.
> 
Do you mean that changes from ProdSource will be merged into the
ReleaseSource and QASource branches?  CVS does not itself support
working directory code merged from different branches, although
you can do that manually in individual cases.  It sounds to me
like you may want to be able to deal in some sort of "change sets"
that can be handled as objects, and in that case CVS is probably
not going to work for you.

> This would make changes applied to 'service packs' available 
> to QA of next
> release and visa versa.  In addition any change made in QA 
> which applies to the
> previous release, is made available to further 'service 
> packs'.  These changes
> are in addition also made available to development of the 
> next release, seeing
> as DevSource gets source from QASource.
> 
How we do it:

There is the head, on which most development will ideally occur.  When
it is time to create a release, we cut a release branch and get it
into shape to ship.  We cut patch branches on those, and so when bugs
are found they are first added to a patch branch, and then merged to
the release branch and then to head.  We can cut off a patch branch when
it seems ready, and package all changes along that branch into a patch
or service pack or whatever you want to call it.

This means that head is basically the development source, and changes made
on releases are propagated into it.  The release branches are effectively
the production source, and QA doesn't have a source base of its own.