[Koha-devel] CVS or 1.3RC's?

Tonnesen Steve tonnesen at cmsd.bc.ca
Wed Sep 11 21:35:05 CEST 2002


On Thu, 12 Sep 2002, Ambrose Li wrote:

> if I want to look at the MARC code (the library I work with
> uses MARC; it wouldn't make sense for me to look at something
> that doesn't use it), should I look at the CVS version, or
> should I look at the 1.3RC's?
> 
> I'm a bit lost here because I did look at CVS, but the
> tarballs have a different directory structure than the CVS,
> and it is not obvious how to make a proper installation
> using the CVS version. If CVS is the way to go (for people
> who are willing to dab into the Perl code and stuff) and no
> one is working on installation docs, I'd be happy to update
> the installation docs for CVS; but if I shouldn't be looking
> at CVS, I'd be happy if someone told me I should look at
> the 1.3RC's instead.
> 
> Is there a place I can look for lists of things like which
> parts of CVS (or the 1.3RC's) are working, and which parts
> are not working? Or which parts have people working on them?


There will soon be release candidates of the 1.3 code.

The way we are handling the discrepancy between the layout in CVS and the
cleaned up layout of the tarballs is with a script called "buidrelease" in
the root of the CVS directory.  You can run this script to create your own
tarballs, and the files should be in the right spot.  I only ask that when
buildrelease asks if you want to tag the CVS repository, you answer No.

For this reason, I think your patch to installer.pl is not really
necessary.  I think it's better to handle cleaning up the directory
structure in CVS with a separate script (buildrelease) that end users
won't ever have to see. 


A rough description of the current state of 1.3 (the trunk branch of CVS)
is that the backend data structure is now highly MARC compliant, meaning
that we can store MARC record data with zero loss of information.  There
is still a lot of work to be done as far as viewing MARC data, managing
marc records, searching MARC data, etc.

Steve.





More information about the Koha-devel mailing list