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

Re: svn commit: r11930 - in branches/locking/subversion: include libsvn_fs_base

From: Michael Sweet <mike_at_easysw.com>
Date: 2004-11-22 20:41:12 CET

C. Michael Pilato wrote:
> ...
> dictating keys to you" or you have to deal with the fact that the one
> lock in your dump is only gonna use 1 index in your repos, which means
> that it will get a different UID than it had before the dump.

OK, let me open my own special can of worms... :)

If you implemented locks as properties, and the properties are
versioned, then you wouldn't need lock UIDs, right? And the dump/
restore code and format wouldn't need to be changed to handle the
lock properties, right?

Granted, there is still the issue of "is this file locked?", but
couldn't "svn lock/unlock" do a commit of the property changes, so
the current "svn commit" would show an out-of-date revision of the
locked file? Wouldn't that work with existing clients, too (server
could reject commits if the existing rev has a lock property that
doesn't match the user doing the commit)?

Or am I totally off my rocker?

Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 22 20:44:17 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.