[Bioperl-l] First cut svn repository [was Re: SVN and ...Re: Perltidy]

[David Messina]

> I have just been through the t/data dir and added a list of  
> extensions I found

Thanks! That's a big help. I'll add prop definitions to those shortly.


>  There are some files without extensions, how should these be dealt  
> with?

If you look in the text files section, there are some files there  
which don't have extensions, e.g. AUTHORS, BUGS. There's also

	Makefile.*

so we have some flexibility in how svn knows to auto-prop a file. I  
haven't read up on the details yet to find out how it handles files  
that match multiple criteria -- it may be dependent simply on the  
order they're defined.



> There seems to be a plethora of file naming styles which means  
> there's a pretty long list of non-standard extensions. So at some  
> point someone will commit a new data file with a new extension  
> (often describing what program created the output or the test for  
> which it's intended) that won't be in the auto-props file - can you  
> think of a way around this?

Ive been thinking about this a bit. How about this?

- We have just "standard" files and extensions (like *.blast,  
*.fasta) in the auto-props list.

- We manually add props for the files that have nonstandard,  
arbitrary extensions so all the files have now are prop'd.

- At some point we rename those nonstandard files to have standard  
extensions. Especially for the t/data/ files, we'll have to make sure  
to update the tests that rely on them.

- We can have the suggested list of extensions for new files that get  
added. I don't think we need to strictly enforce this just for the  
sake of svn (after all, its primary function of version control will  
work just fine without any properties set), but it would be nice if  
we could try to keep to it mostly.

Many distros come with an /etc/mime.types file which has the list of  
officially registered MIME types. I found a script that will take  
this list and convert it into auto-props format. I don't think we  
need to support *all* of the gazillion filetypes since most of the  
them our repository will never see, but we certainly could.


Dave