[BioPython] [bip] [OT] Revision control and databases

[Leighton Pritchard]

On 24/10/2008 10:08, "Giovanni Marco Dall'Olio" <dalloliogm at gmail.com>
wrote:

> The problem is that BioSQL doesn't support yet Population Genetics record
> (see another thread in biopython mailing list), so I would have to implement
> something like that in BioSQL or wait for the developers to do it.
> Maybe I will do this later, but now I don't have the time.

To be fair, that's a different problem from version control...

>> How often do you use the old versions in your git repository?
>> How do you use the old revisions in your git repository?
>> Do you even use the information of an older version if a newer version
>> exists?
>> How many users that can make changes?
>> How often do you have conflicts?
>> Are the conflicts hard to solve?
> 
> These are all very good questions.
> The problem is that I consider revision control as a 'good practice'

I think that you're right - it is good practice, and Bruce raises excellent
questions here: what individuals want or need from version control depends
greatly on their own situation, and whether a particular package fits your
own needs will depend on what they are.  If you don't know what they are
before choosing a package, then there's the risk of making an unsuitable
choice.

It's worth noting that revision control can also mean slightly different
things to different people.  Some might say that a version number and an ID
for the entity (human or automated) making that change is sufficient.  Some
might say that you ought not to stop short of conflict resolution and branch
control.  It depends on the needs of your project, IMO.

> I think this is a big issue for bioinformatics. How is it possible that nobody
> has never tried to implement such a functionality for databases

Databases (DBMS, to be picky) are a general-purpose solution for many
different kinds of problem.  Revision control is an inhomogeneous problem
with no optimal solution that can be implemented in many ways and not only
using DBMS.  There are plenty of revision control examples implemented in
databases, and the examples that first come to mind in Python for me are
content management systems such as Zope and Plone.  I think that BASE
implements one, but it's a long time since I looked at it.

> Unfortunately I think revision control would be very useful for me.
> The data in the database will be used and uploaded by 4 or 5 people.

Then at a minimum you may need a solution that records version changes, and
associates versions with individuals (and perhaps individual runs of
scripts).  You may also need locking and collision detection/conflict
resolution (which DBMS like MySQL and PostgreSQL support internally via
transactions; they don't generally implement version control because it
would be wasteful), depending on whether you expect that multiple people
might modify the same file at or at about the same time.

Best,

L.

-- 
Dr Leighton Pritchard MRSC
D131, Plant Pathology Programme, SCRI
Errol Road, Invergowrie, Perth and Kinross, Scotland, DD2 5DA
e:lpritc at scri.ac.uk       w:http://www.scri.ac.uk/staff/leightonpritchard
gpg/pgp: 0xFEFC205C       tel:+44(0)1382 562731 x2405


______________________________________________________________________
SCRI, Invergowrie, Dundee, DD2 5DA.  
The Scottish Crop Research Institute is a charitable company limited by
guarantee. 
Registered in Scotland No: SC 29367.
Recognised by the Inland Revenue as a Scottish Charity No: SC 006662.


DISCLAIMER:

This email is from the Scottish Crop Research Institute, but the views 
expressed by the sender are not necessarily the views of SCRI and its 
subsidiaries.  This email and any files transmitted with it are
confidential

to the intended recipient at the e-mail address to which it has been 
addressed.  It may not be disclosed or used by any other than that
addressee.
If you are not the intended recipient you are requested to preserve this

confidentiality and you must not use, disclose, copy, print or rely on
this 
e-mail in any way. Please notify postmaster at scri.ac.uk quoting the 
name of the sender and delete the email from your system.

Although SCRI has taken reasonable precautions to ensure no viruses are 
present in this email, neither the Institute nor the sender accepts any 
responsibility for any viruses, and it is your responsibility to scan
the email and the attachments (if any).
______________________________________________________________________