 |
 |
And yet, as someone who has used such a system regularly, my routine pattern of use is not to refer to an explicit version of a file.... I deal with a dynamic system: often, what I get out is different to what I put in. This is often a Good Thing in that it demonstrates that others are working on the project. I do agree with you that the fact that nothing is completely removed is an important, and perhaps more 'repository'-like feature. Paul On 12 Mar 2009, at 22:13, Mark Diggory wrote: > Having worked quite intimately with SCM on a day to day basis as a > software engineer, I would be very dismayed if what I got out was > not what I had put in when refering to an explicit version of a > file. The illusion of "being dynamic" is really a play on > addressability of the stored resource. SCM are "cold storage" for > each version of a file, it is very difficult to "remove" something > you've committed to Sourceforge completely, a version will always > persist unless something is done under the hood to remove it by the > administrators. > > Mark > > On Thu, Mar 12, 2009 at 2:57 PM, Paul Walk <[log in to unmask]> wrote: > Good to see a successful application of LOEKAS (Lots of Eyeballs > Keep Acronyms Safe)..... > > Paul > > On 12 Mar 2009, at 21:38, P Burnhill wrote: > > I take it you mean LOCKSS? In fact I looked for LOCKKS, and noticed > quite a few uses of LOCKKS when LOCKSS as intended. > > But back to your point. The so-called source repositories seem to be > acting more as a dynamic database than a 'cold repository', a cold > store of things that are chilled so that what is available to take > out is *very close* to what has been put in. And the general case > for mutable objects is that they are taken out, cooked in some > interesting way, with a few added ingredients and then chilled down > and put in the cold store with enough metadata to see how that one > differs from the other (original recipe) on the shelf below. > > This analogy to a cold store of objects for a repository is in stark > contrast to the characterics of a midden, onto which objects are > discarded with the expectation that decay will set in after a short > to medium period of time - and if you leave it long enough, its just > bits. > > Which brings us back to Paul's pointer to LOCKSS, which is geared to > detect change in copies/surrogates/versions of an object. This > prompts thoughts about provenance, and work down by Peter Buneman's > group on algorithmic approach to changes in dataases over time. > > > > > On Thu, 12 Mar 2009, Paul Walk wrote: > > Les has drawn the distinction between the essentially 'live' nature > of content in source-code repositories and the generally rather > static aspect of content in our average IR. Of course there are > plenty of examples of source-code repositories which are no longer > being used to support 'live' code (swathes of sourceforge.net > resemble a graveyard of abandoned software projects), but this > distinction is nonetheless true and important. > > I would like to point up another distinction: the source code > repository is, pretty much by definition, designed to support a > *team* (or at least a pair) working on the same project. Version > control is fundamental, but equally important are a set of tools and > practices supported by the repository to aid collaborative > development. A typical interaction with the average IR is, I > venture, a more solitary affair. > > Having said this, it has occurred to me that there may well be an > overlap, in terms of architecture at least, between LOCKKS and a > relatively new source-code version control system called 'Git'. > > Paul > > > > On 12 Mar 2009, at 18:50, Peter Burnhill wrote: > > Without wanting to disappear up an ontology of .... > On 12 Mar 2009, at 16:43, Leslie Carr wrote: > On 12 Mar 2009, at 16:36, Peter Burnhill wrote: > I think repositories are a place to store things. > Store? Get? Keep? They're all services :-) > well, they are verbs/actions, and as noted below, I am wary of using > repository as a word for every set of managed data - as a variant of > database, say. > I need a bit of assistance to separate Store & Keep, but would > expect that Put (deposit/ingest) & Get have to be among the minimum > set of verbs. In a source repository, which has that set, there is > greater need to attend to amend/edit and provenance/trail than is > usual among the repositories of objects usually included in > discussion. Being a 'data person', I am aware of some of the > natural history of data generation (manufacture/collection) and the > management of databases and datasets but not yet convinced that > there is as much carry-over as supposed. > I've never signed up to the idea that they are a set of services, > except that a repository might be thought to be capable of > supporting three essential services: ingest (deposit), keep-safe and > access (use). Of course, for a digital/network repository each of > those may have multiple interpretation: typically m2m as well as hci > for the ingest and access, say. At least that is how we conceived > the minimally sufficient functionality for Jorum. Keep-safe also > needs some interpretation. > Perhaps the key part of a source repository is that it is made to > look after (store, get, keep) a large number of highly synchronised, > formally interpretable modules. The services (oops) that it offers > are related to the business of using (and reusing) software code. Of > course, code is manufactured and used by users, so the whole social > network thingy might look very familiar. > As for code preservation (language migration, version retrofitting > etc) well, that is an issue, but no-one is suggesting that a > specialised group of librarians will do it instead of the code > producers themselves. > data librarians and data curators do deploy information management > skills, rather than leave it to the data producers > (nstrumentalists?) or even the researchers, but I digress > Peter > -- > Les > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > -------------------------------------------- > Paul Walk > Technical Manager > UKOLN (University of Bath) > http://www.ukoln.ac.uk/ > [log in to unmask] > +44(0)1225383933 > -------------------------------------------- > > > > ********** ********* ******** ******* ****** ***** **** *** ** * > > Peter Burnhill > Director, EDINA national data centre & Head, Data Library > > Causewayside House > University of Edinburgh > 160 Causewayside > Edinburgh EH > Scotland, UK > > tel: +44 (0) 131 650 3301 fax: 3308 mobile: +44 (0) 774 0763 119 > Email: [log in to unmask] URL http://edina.ac.uk > > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > -------------------------------------------- > Paul Walk > Technical Manager > UKOLN (University of Bath) > http://www.ukoln.ac.uk/ > [log in to unmask] > +44(0)1225383933 > -------------------------------------------- > > > > -- > ~~~~~~~~~~~~~ > Mark R. Diggory > Home Page: http://purl.org/net/mdiggory/homepage > Skype ID: mdiggory -------------------------------------------- Paul Walk Technical Manager UKOLN (University of Bath) http://www.ukoln.ac.uk/ [log in to unmask] +44(0)1225383933 --------------------------------------------