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
--------------------------------------------
|