Re: [PATCH] Release candidate patch for adding external locking filecode to svn_repos_open

Well, I guess I'm wondering what the right answer should be.

Luckily I don't work in an environment where running a server is an issue.

But then, I'm not working in the I/S department right now, even though that's
my role in the business unit I'm in.

However, I *know* that in many of the I/S depts I've worked in, they tend to
be pretty old school.

To use a localilized revision control system is overlooked. You can use
whatever makes you happy.

Even if you want to store the contents on a network fileshare so that you can
get to it from wherever.

The moment you want to run a server, now it has to conform to corporate
policy, be approved, budgeted, support personnel be assigned, and so on. I
know. There is only 2 corporate environments I've been in where we had free
reign in the development arena, but had strict controls in production.
Everywhere else, it was tight if we were in I/S. Lax elsewhere. And if
something went wrong and I/S came in and found out you were running a server,
it got shut down.

So my question in light of all that is:

When faced with the fact that you have to run a local repository, but need to
take advantage of the ubiquitous networking infrastructure where more than one
person can use the data, how should one take advantage of a tool like
Subversion, or should one stick to good old CVS and RCS and SCCS which offer
client-server operations, but also allow for a non-server envvironment?

I mean, we could always use a MS-Access backend - at least that would allow
network concurrency. (Sorry for the analogy, but I'm confused as to why BDB
can't operate correctly across smb/cifs/nfs whereas a dumb technology like
Access can).

I don't see this as a new protocol. Does everyone else really? I mean, isn't
it just the file access protocol with a single-user mode thrown in? W/ the
option to open files in exclusive mode to overcome the shortcomings of the
back end?

Or am I just totally off track here. I mean, we did follow Greg's suggestion
to not create a new scheme.

Could we have done this with hooks or something? I don't know.

-- 
Shamim Islam
BA BS
kfogel@collab.net said:
> Garrett Rooney <rooneg@electricjellyfish.net> writes:
>> I really don't like the idea of supporting this kind of hack.  We have
>> two real solutions for accessing a repository over a network already,
>> solutions which don't require exclusive locking of the repository on
>> access.  If you must use this kind of hack, it should be as a local
>> change, IMHO.
>
> The only reason I haven't said "-1" is that no one's actually proposed
> putting it in mainline Subversion yet (unless I just missed it).
>
> When an organization has no problem with the features of the existing
> network layers, yet still won't permit itself to run Subversion over
> them, I don't think our response should be to make a new protocol.
>
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org