[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Backing up locks: dump doesn't maintain lock state?

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-12-20 15:23:00 CET

Erik Huelsmann wrote:
> On 12/20/06, Troels Arvin <troels@arvin.dk> wrote:
>> On Tue, 19 Dec 2006 15:36:09 +0100, Erik Huelsmann wrote:
>>> A lock is not a versioned event, so why do you expect it in the
>>> version history dump?
>>
>> I think that the word "dump" would normally signal a way to export
>> all current state to a form which can be imported to re-create that
>> state. And I consider locks as part of a repository state.
>>
>> At least, I think that it should be clearly noted somewhere in the
>> docs for "svnadmin dump".
>
> I'm cross posting this to dev@, in order to see what others think
> about this issue.

'svnadmin dump' isn't a repository state capturing mechanism, so we have
the luxury of being selective about what we save. We don't keep
unfinished transactions or the changes associated with them. We don't
attempt to preserve those repos-unique node-revision-IDs. And we don't
try to represent locks.

Maybe there's some dispute about the name 'dump' and what it implies,
but our dumpfile format is merely a way to carry the version history of
a Subversion repository from one place to another. Locks aren't part of
that versioned history; they are these transient, timeless things that
have no revision association. Remotely managed, eternally deep ACLs of
a lesser nature. I dunno. But not version history.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Wed Dec 20 15:24:04 2006

This is an archived mail posted to the Subversion Dev mailing list.