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

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