> since after the directory 'cvs_v2' changes, only that person will have
> a clue what was compiled. i still suggest tagging a new version each
> time you have something important enough to compile and install in the
> blast library.
that is still the plan and has not changed. But then this week (added few
channels, then added some more) we would have require new tags on monday
and wednsday. It's preferable to have a tag every 1-2 weeks.
> the object files don't tell you anything about what changed.
running diff with the object files tells you if this is the same object
file you find in the cvs directory. That is useful.
-- ________________________________________________________________________________ Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124 research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^On Thu, 8 May 2003, Chris Crawford wrote:
> hi tancredi, > > Tancredi Botto wrote: > > >I wanted to make a note about cvs to all users of the blast online > >analysis. You may already recognize this system from last year. If you > >have problems contact me. > > > >We have a fluid reconstruction software and not eveybody feels comfortable > >with cvs. For this reason we often "tag" the reconstruction code. However, > >a) you can't tag everyday b) after a tag you can't submit even a minute > > > i sent out instructions a while ago to revert to the code at an > arbitrary point in time. [BLAST_ANAWARE] cvs: reverting back to an > earlier untagged version > <http://blast.lns.mit.edu/BlastTalk/archive/1396.html> > > also, i have been submitting changes to tags (just bugfixes of course). > each tag (i.e. v2_18) has an associated branch (ie. b2_18) with the > latest fixes. > > >change (to the tag) and you have to go back to the head of branch (where > >you'll receive also all other changes). > > > >Presently the reconstruction code is on cvs branch 2, the last tagged > >version is v2_18 (see below). On the blast account we have the cvs_v2.18 > >and cvs_v2 directories. Obviously in cvs_v2 we have the latest code, the > >one that has already surpassed v2_18 and is presently in use. In cvs_v2.18 > >we have an earlier working copy of the sources. > > > >The libBlast and nsed versions used online are compiled in the cvs > >directory. They are then copied to ~/lib and ~/bin respectively (e.g. > >cp -rp libBlast.so ~/lib/libBlast.so.2.18b). The lib (bin) directory is > >effectively a repository of all compiled copies of libBlast.so.XXX > >(nsed.XXX), each with a version number. When I compile in cvs_v2 the first > >time the version number is v2a. If I update cvs_v2 and compile again the > >version number is v2b and so on... > > > these versions will only be useful to the person who compiled them, > since after the directory 'cvs_v2' changes, only that person will have a > clue what was compiled. i still suggest tagging a new version each time > you have something important enough to compile and install in the blast > library. > > if you want to go back and make changes to b2_18, (only bugfixes), you > can check them in and tag them as v2_18_1, v2_18_2, etc. > > > > >** In ~/lib, (~/bin) the symbolic link libBlast.so (nsed) points to the > >one copy effectively in use ** This is more than enough to always know > >what you are using. You can link to any of those versions from your > >account. You can run diffs with the object files left in the ~/cvs. > > > the object files don't tell you anything about what changed. > > > > >Similarly it is done for the montecarlo (from the v3 branch in cvs_v3) > > > >If you need to change libBlast version I suggest you first link to your > >desired object from the LOCAL you are working from (e.g. the analysis > >directory). This will always work since . is first in LD_LIBRARY_PATH. > > > >Only people that really know what they are doing should update the > >cvs directory and recompile. > > > >Note that in the future we may have only one cvs version (e.g. v3) but > >I can imagine we will still be using tags for convenience. > > > yeah. very soon, we won't have the v2 branch to worry about anymore, > but we will still tag v3_x snapshots. > > --chris > >
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST