RE: [Axiom-developer] SVN on sourceforge

[Page, Bill]

Ralf, 

On Wednesday, September 13, 2006 10:40 AM you wrote:
> 
> somehow you are contradicting yourself.
>

You are right. I have been thinking about this for a while
and I realized that I had become suckered into this whole
'svn:eol-style' thing, too. Part of the problem is that
svn is trying to be "all things to all people". If they
had just learned to say "no" life would be so much easier...
 
> >> So please tell me what filetypes should keep/get the
> >>
> >> svn:eol-style=native
> >>
> >> property (ie change to native line endings at checkout).
> 
> > Actually my understanding is that if we remove the
> > svn:eol-style properties from all files and set that as 
> > the default, then SVN will just leave all the files alone.
> 
> In a previous mail
> 
>
http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00294.ht
ml
> 
> you suggested:
> 
> >> I think it would be better to be selective and leave
> >> the svn:eol-style property as set on the text files.
>

I have changed my mind. It is true that they probably "do no
harm" right now so they could be retained. But it is only
an accident of the conversion from CVS on SourceForge that
they are there at all. To save us having to re-visit this again,
and again, say when people do checkouts to MAC (\r line endings)
and Windows (\r\n endings), God forbid that anyone should ever
try to install Axiom under VMS on a VAX computer...

I think we should get rid of them now. All text files in the
Axiom source distribution should use unix-style line endings -
period. When porting to other platforms it is the responsibility
of the port as to how to deal with this. On Windows almost all
text processing software treat \n and \r\n identicall. There
is a patch to the BOOT and SPAD compilers on the Windows version
of Axiom to do exactly that.
 
> I've already locally modified the eol-style and was just about
> to commit. The following files and extensions are left with the
> "native" eol-style set.
> 
> I believe it is OK if they are left as text files and change the 
> line-endings.
> 

Ok.

> In particular, I would like to see it for .pamphlet files. It
> gives a terrible mess if some windows user changes ONE line in
> a file, commits the thing and I run a diff to the previous version
> and see that ALL lines have changed.

That is an elementary Windows developer error. Don't expect the
archive software to save them - revoke their archive access
privileges!  ;)

> 
> The copyright files...
>    .AXIOM
>    .B
>    .BULL
>    .CC
>    .CCL
>    .EAY
>    .FSF
>    .NOWEB
>    .RAND
>    .SMC
> 
> Some other obvious text files.

Having to make the distinction between 'text' and 'non-text'
files is annoying and unnecessary.

> I actually don't understand why in the repository is anything 
> else than pamphlets.

I agree.

> I can understand .fig, .jpg, .png or such files,

I don't.

With the very rare exception of essential graphic artwork (eg. book
cover) I think all such files should be generated from source - by
running Axiom, noweb, LaTeX, dvipng, graphviz, etc.

> I think we should only keep the source but not .lisp, .tex, .sty,
> .text, .h.

Right.

> Maybe .booklet is special.

'booklet' is an experimental type of source file like 'pamphlet'.

> 
> Any reason why there are such non-pamphlets?
> 
>    .H1 <-------- I am not sure about that one. Looks like a .h file.
>    .booklet
>    .h
>    .lisp
>    .pamphlet
>    .patch
>    .sty
>    .tex
>    .text
> 
>    CHANGELOG
>    ChangeLog
>    FAQ
>    Makefile
>    README
> 
>    axiom
>    configure
>    document
>    showdvi
>

There may need to be a small number of files to simplify the
'bootstrap form pamphlet' process. And some (e.g. README) are
present to conform to open source packaging common practices.

> These files are probably not needed anymore...
>    boxhead
>    boxtail
>    boxup
>

I agree.
 
>  From CVSROOT
>    checkoutlist
>    commitinfo
>    config
>    copyright
>    cvswrappers
>    editinfo
>    loginfo
>    modules
>    notify
>    rcsinfo
>    summary
>    taginfo
>    verifymsg
> 

These are CVS control files that should not be in the
SVN archive.

Regards,
Bill Page.