It does not. There was a discussion about this being a repository
setting, but I chose to take this approach for the following reasons:
1) This "feature" should never be used. If you want to have multiple
users accessing a Subversion repository you should use Apache or run the
SVN server program. If you take a look at svn_ra_lock__split_URL, it
sleeps for two seconds after creating the lock file, and then tries to
perform a sanity check on it. This would get in the way of a normal
setup.
2) OK, if this should never be used, why did I do it? I blame the
Network Nazis at the place where I work. They will not let me run Apache
or the SVN server. We currently use Visual SourceSafe, which allows for
multiple client program access to a VSS repository on a LAN drive.
3) Most importantly from a newbie Subversion hackers perspective, this
was the easiest way for me to plug my code into the program. So I
thought this would be OK as a proof of concept.
After thinking things over a bit more, I am beginning to think that this
should be a repository setting. In that case, I guess the lock code
should be moved to svn_repos_open in repos.c.
If it was put in repos.c, I would have to add code to check the
repository properties, and only do this if the appropriate property was
set. Are there any examples of this? And how do you set the repository
property to begin with?
David Kopp
On Mon, 2003-11-03 at 11:10, Craig L. Ching wrote:
> > I have hacked in a lock protocol in my working copy. I added a
> > libsvn_ra_lock directory and implemented it as a new RA
> > layer. I choose
> > to do this because I thought this functionality is a property of the
> > repository location, not of the repository itself.
> >
> Does it do the right thing (e.g. stop an operation) if someone uses file:// to access the repository? It seems to me that the lock is a repo setting and NOT a user setting. At least I wouldn't rely on my users specifying lock:// to access a shared repository. Just a thought.
>
> > David Kopp
> >
>
> Cheers,
> Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 3 19:08:31 2003