Earlier on in the project analysis I was pursuing a Git solution because it 
seemed all its features would work with documents/code/files of any kind and so 
would be perfect for scientific reproducibility.  But its ability to 
efficiently archive non-documents is quite hit and miss, and the file size 
limitation becomes a major problem on top of that when it doesn't.
I will try to design the system so that handlers for different types of 
databases/files can be called into play to retrieve versioned content.

Its just that this fall I'll only have time to provide the handlers for fasta 
file archiving (the key-value database update approach enables fasta versioning 
and all the spinoff data from that.).
The next priority would be a handler for any type of file that needs to be 
replaced as a whole from version to version (one just needs hard drive space to 
accommodate this, since caching is pointless).
A git handler for well-behaved document content would also be a possibility.

Typo: I said yesterday "I wasn't going to leave that as just "fasta" datatype 
since it seems tools like makeblastdb don't allow anything else ..." - but I 
meant 'I WAS going to leave that as just "fasta"...'

Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

To search Galaxy mailing lists use the unified search at:

Reply via email to