RE: [OJB-developers] CVS

[<Joa...@tp...>]

> take a deep breath and relax.

Sorry, if my mail sounded as a flame or like I was angry or anything. It
was not intended. I just wanted to know wether those were known issues.
None of these issues had any _major_ impact on my working with ojb, but I
still watch ojb with beginners eyes and every thing that disturbs me from
just getting it to run is disturbing (and potentially stopping someone else
from takeing a closer look at ojb, which should be avoided, I think).

[broken newlines]
> No, this is not the fault of CVS, but of the ScriptTool that is used
> for preprocessing the java files. This is already a known issue.

i see ...

>> 2.) other files are marked as binary (sticky -kb tag), 'though they
>> should be text (-kkv) (i.e. src/test/ojb/repository_*.xml)
>
> True, but that can be fixed easily (cvs admin -kkv *.xml).

i know, i just wanted to mention it, as someone should really fix it (and I
don't have cvs write access).

>> 3.) Some classes (namely those in ojb.tools.mapping.reversedb)
>> depend on gnu-regexp, which is not in the lib-directory
>
> This is recently contributed code that Thomas added to CVS a few days
> ago. He might have missed the gnu-regexp package.

I understand, but I think such things can easily be avoided. If you require
each used library to be put into /lib then every decent IDE (or CVS client)
will show you that you have libraries in the directory that are not under
CVS control.

>> 4.) i seriously doubt that ojb-1-0/build should be under cvs
>> controll
>
> All the things you mentioned are not the fault of CVS or because of
> several people working concurrently, everything you described would
> have happened even if the project was not under CVS control. Human
> being make errors. But it is nothing that cannot be fixed.

I know that each of these things can be fixed and that none of it is an
inherent problem with CVS (although such problems do exist).

>> (now I understand why you closed down cvs, Thomas!)
>
> And I hope it remains under CVS, it makes it a lot easier to
> contribute code.

I do hope so as well, but for it to be usefull such issues have to be
sorted out and avoided in the future (probably by the "rules of conduct"
that Thomas mentioned in one of his previous mails).

I hope I don't give a bad impression. I didn't mean to just run into this
list and flame away. I wanted to raise some issues, as I know from personal
experience that some of these issues usually aren't detected when you just
work on the same working copy and that they only disrupt the workflow for
newly checked out sources and thus get less attention.

> best regards, Florian

regards
Joachim Sauer