History of bitweaverCVS
Version 44
bitweaverCVS
Developer Management of bitweaver Source Code
Our CVS is hosted at SourceForge
Check out our groovy CVS Stats
An introduction to CVS use on SourceForge is Basic Introduction to CVS and SourceForge.net Project CVS Services.
Information on usage of SourceForge CVS is in Section F of the SourceForge Docs page.
To get code for ReleaseOne, you want to check out the code from Sourceforge.
Developer Access: If you are you a member of the bitweaver project then you should (NOTE!! Make sure you "export CVS_RSH=ssh" in your /etc/profile or CVS shell first):
General Access: If not, you can get anonymous access. Note this method users a mirrored CVS and has a 24+ code delay with the :ext: method indicated above.
To get the latest and greatest code from cvs HEAD ( currently ReleaseTwo ), don't use any tags at all:
_adodb - the latest import and merge of the adodb library supported by bitweaver
_smarty - the latest import and merge of the smarty library supported by bitweaver
Fixes in STABLE get merged into TESTING as needed.
Fixes in TESTING, including those from STABLE, get merged into HEAD as needed.
Several tags are maintained on DEVELOPMENT, TESTING, and STABLE to manage the merge process. In general you should simple checkout the latest version of the brach you are working on. See ReleaseProcess for what should be done where.
Format:
Check out our groovy CVS Stats
CVS Introduction
An introduction to CVS use on SourceForge is Basic Introduction to CVS and SourceForge.net Project CVS Services.
Information on usage of SourceForge CVS is in Section F of the SourceForge Docs page.
How is the bitweaverCVS organized
Modules
Our CVS tree has a cvs module for each package. However, a virtual CVS module is use to create our two primary distributions: bitweaver and tikilite. Every bitweaverRoadMap has a CVS branch named after it. The branch is create AFTER we have gone into schema freeze for the project.To get code for ReleaseOne, you want to check out the code from Sourceforge.
Developer Access: If you are you a member of the bitweaver project then you should (NOTE!! Make sure you "export CVS_RSH=ssh" in your /etc/profile or CVS shell first):
cvs -d :ext:yourusername@cvs.sf.net:/cvsroot/bitweaver co -r R1 bitweaver
General Access: If not, you can get anonymous access. Note this method users a mirrored CVS and has a 24+ code delay with the :ext: method indicated above.
cvs -d :pserver:anonymous@cvs.sf.net:/cvsroot/bitweaver co -r R1bitweaver
To get the latest and greatest code from cvs HEAD ( currently ReleaseTwo ), don't use any tags at all:
cvs -d :ext:yourusername@cvs.sf.net:/cvsroot/bitweaver co bitweaver
Other modules:
_adodb - the latest import and merge of the adodb library supported by bitweaver
_smarty - the latest import and merge of the smarty library supported by bitweaver
Branches
As discussed in ReleaseProcess there are three active branches in cvs: STABLE, TESTING, and DEVELOPMENT. See ReleaseProcess for which branch is currently in which state.Development/HEAD
DEVELOPMENT is the cvs trunk also known as HEAD.Fixes in STABLE get merged into TESTING as needed.
Fixes in TESTING, including those from STABLE, get merged into HEAD as needed.
Several tags are maintained on DEVELOPMENT, TESTING, and STABLE to manage the merge process. In general you should simple checkout the latest version of the brach you are working on. See ReleaseProcess for what should be done where.
Format:
- Branch - Comment
- Tag - Comment
- Tag - Comment
HEAD - Current Mainline
- This is the leading edge of development.
Bonnie - Release 2
- R1 - Release 2
- R1_LASTMERGE - Point at which the most recent merge to HEAD took place.
- R1_NEXTMERGE - Point to which the next merge to HEAD will end. (Only used for a few minutes at a time while merging)
AL - Release 1
- AL - Release 1 - No longer Maintained
- AL_LASTMERGE - Point at which the most recent merge to HEAD took place.
- AL_NEXTMERGE - Point to which the next merge to HEAD will end. (Only used for a few minutes at a time while merging)
- AL_RC1 - Release Candidate 1
- AL_RC2 - Release Candidate 2
- PURETIKI - Initial import of Tiki 1.8 for fork
Version Merging
How merge to HEAD is done:
In R1/bitweaver directory:
cvs update -dP
cvs tag -cF R1_NEXTMERGE
In merge/HEAD directory:
cvs -d :ext:btodoroff@cvs.sourceforge.net:/cvsroot/bitweaver co bitweaver
cd bitweaver
cvs update -j R1_LASTMERGE -j R1_NEXTMERGE
cvs commit -m "Merge recent changes from R1 into HEAD"
cd ..
rm -rf bitweaver
Back in R1/bitweaver directory:
cvs tag -r R1_NEXTMERGE -F R1_LASTMERGE
In R1/bitweaver directory:
cvs update -dP
cvs tag -cF R1_NEXTMERGE
In merge/HEAD directory:
cvs -d :ext:btodoroff@cvs.sourceforge.net:/cvsroot/bitweaver co bitweaver
cd bitweaver
cvs update -j R1_LASTMERGE -j R1_NEXTMERGE
cvs commit -m "Merge recent changes from R1 into HEAD"
cd ..
rm -rf bitweaver
Back in R1/bitweaver directory:
cvs tag -r R1_NEXTMERGE -F R1_LASTMERGE
How a release branch is created
In <release> directory:
cvs -d:ext:..... co bitweaver
In <release>/bitweaver directory:
cvs update -dP
cvs rtag -b -D <today date="" plus="" year:="" yyyy-mm-dd=""><release> bitweaver
cvs rtag -r <release><release>_LASTMERGE bitweaver
In <release> directory:
cvs -d:ext:..... co bitweaver
In <release>/bitweaver directory:
cvs update -dP
cvs rtag -b -D <today date="" plus="" year:="" yyyy-mm-dd=""><release> bitweaver
cvs rtag -r <release><release>_LASTMERGE bitweaver
Including 3rd party code in CVS
How merge to HEAD is done:
Let's say we want to import the excellent database abstraction layer
ADOdb version 4.60 into our CVS repository:
Now, we're going to check it out from CVS and fix a bug we found:
Now, we want to upgrade to version 4.62:
This command completed successfully, but reported the following:
1 conflicts created by this import.
Use the following command to help the merge:
So, let's delete the imported directory:
And checkout as instructed above.
Manually resolve any conflicts that were reported.
Now, let's commit our 4.60 changes into 4.62:
And finally remove our directory:
(Source: http://tikiwiki.org/tiki-index.php?page=UsingLibrariesInCVS)
</release></release></release></today></release></release>Let's say we want to import the excellent database abstraction layer
ADOdb version 4.60 into our CVS repository:
$ wget http://phplens.com/lens/dl/adodb360.tgz
$ tar xvzf adodb360.tgz
$ rm adodb360.tgz
$ cd adodb
$ cvs import -m 'Imported ADOdb 4.60' _adodb PHPLENS_COM R4_60
$ cd ..
$ rm -fr adodb
Now, we're going to check it out from CVS and fix a bug we found:
$ cvs checkout _adodb
$ cd _adodb
...hack, chop, whittle...
$ cvs commit -m "Fixed bug #12345: Replace doesn't use native REPLACE command, if available"
$ cd ..
$ rm -fr _adodb
Now, we want to upgrade to version 4.62:
$ wget http://phplens.com/lens/dl/adodb462.tgz
$ tar xvzf adodb462.tgz
$ rm adodb462.tgz
$ cd adodb
$ cvs import -m 'Imported ADOdb 4.62' _adodb PHPLENS_COM R4_62
This command completed successfully, but reported the following:
1 conflicts created by this import.
Use the following command to help the merge:
cvs checkout -j -jR4_62 _adodb
So, let's delete the imported directory:
$ cd ..
$ rm -fr adodb
And checkout as instructed above.
$ cvs checkout -jR4_60 -jR4_62 _adodb
Manually resolve any conflicts that were reported.
Now, let's commit our 4.60 changes into 4.62:
$ cvs commit -m 'Merged our 4.60 changes into 4.62'
And finally remove our directory:
$ rm -fr _adodb
(Source: http://tikiwiki.org/tiki-index.php?page=UsingLibrariesInCVS)