You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Kopp <da...@bellsouth.net> on 2003/11/04 23:12:03 UTC
[PATCH] Release candidate patch for adding external locking
filecode to svn_repos_open
Hello again,
I have made a few modifications to Shamim's patch and come up with the
attached patch.
I moved some of the functions to the top of the file in order to satisfy
the compiler. I also removed lock_time from svn_repos_t and made it a
static variable of create_external_lock_if_requested. (It doesn't work
otherwise).
So, what do the rest of you think? I would like to have this added,
because then I would be able to use Subversion at work.
David Kopp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release candidate patch for adding external locking filecode to svn_repos_open
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Nov 4, 2003, at 7:56 PM, Files wrote:
>> 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,
>
> We have a way to access a networked repository across nfs/cifs/smb w/o
> running
> a server?
>
> Kewl. What do I have to do to run it?
>
> And if we don't, does the fact that this ONLY takes place if the user
> specifically adjusts the lock.conf file make it any better?
>
> It truly is passthru otherwise.
>
> Just my two cents. Not married to it, but it seemed like something
> that would
> come up repeatedly when subversion was being used in a strict
> environment w/
> lots of red tape.
No, we don't. We let you run a server. That's the way the software
was designed to work, and giving people a way to cripple it to work
around the fact that they're stuck with network nazis who won't let
them install a server is stupid. They should convince their network
nazis to let them run a server (since if you have to go through this
hellish procedure to install a server, you probably should have to do
so to switch a version control system anyway), or they can patch their
own copy before installing it.
I just don't feel comfortable including such a blatant hack in our
tree, since it implies that we think it's an acceptable workaround, and
personally I don't think it is. I'm sorry if that's inconvenient for
some people, but if you're in a situation where the biggest issue
keeping you from using Subversion is the fact that you have to run a
server, you likely have bigger issues you should be dealing with.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release candidate patch for adding external locking
filecode to svn_repos_open
Posted by Files <fi...@poetryunlimited.com>.
> 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,
We have a way to access a networked repository across nfs/cifs/smb w/o running
a server?
Kewl. What do I have to do to run it?
And if we don't, does the fact that this ONLY takes place if the user
specifically adjusts the lock.conf file make it any better?
It truly is passthru otherwise.
Just my two cents. Not married to it, but it seemed like something that would
come up repeatedly when subversion was being used in a strict environment w/
lots of red tape.
--
Shamim Islam
BA BS
>
> -garrett
>
>
> ---------------------------------------------------------------------
> 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
Re: [PATCH] Release candidate patch for adding external locking filecode to svn_repos_open
Posted by kf...@collab.net.
kfogel@collab.net writes:
> 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.
... at least not before 1.0, I should have added.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release candidate patch for adding external locking
filecode to svn_repos_open
Posted by Files <fi...@poetryunlimited.com>.
D.J. Heap said:
> Files wrote:
>> Ok. I'm a little confused here.
>>
>> 1. I can run an access database on a novell share, and have multiple people
>> access it and write to it..
>> 2. I can run an access database on a windows share and have multiple people
>> access it and write to it.
>> Anyway. I'm going to bed. I hope wiser heads than I can come up w/ a
>> solution
>> for local repositories across SMB.
>
> Do a google search on 'MS Access corruption' and look at the rather
> large number of hits (178k for me). There are even commercial third
> party tools for 'fixing' corrupt Access databases. Impressive. Access
> is not generally considered a reliable db.
I never claimed reliability as a big plus on MS-Access. Having had to fix
things from time to time myself at my work on a departmental database.
I would have to agree. Server based is more reliable.
But what do you do when you're a department that isn't allowed to run a server
or if you're a student and can't do it?
--
Shamim Islam
BA BS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release candidate patch for adding external locking
filecode to svn_repos_open
Posted by "D.J. Heap" <dj...@shadyvale.net>.
Files wrote:
> Ok. I'm a little confused here.
>
> 1. I can run an access database on a novell share, and have multiple people
> access it and write to it..
> 2. I can run an access database on a windows share and have multiple people
> access it and write to it.
> 3. How can I do the same w/ BDB w/o a server?
> 4. Does BDB mmap files?
> 5. Will this problem go away if we used something like SQLite instead of BDB?
>
> I'm sorry if I'm asking questions that should be obvious. I'm not that
> familiar with the internal architecture of BDB.
>
> Anyway. I'm going to bed. I hope wiser heads than I can come up w/ a solution
> for local repositories across SMB.
Do a google search on 'MS Access corruption' and look at the rather
large number of hits (178k for me). There are even commercial third
party tools for 'fixing' corrupt Access databases. Impressive. Access
is not generally considered a reliable db.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release candidate patch for adding external locking filecode
to svn_repos_open
Posted by Branko Čibej <br...@xbc.nu>.
Files wrote:
>Ok. I'm a little confused here.
>
>1. I can run an access database on a novell share, and have multiple people
>access it and write to it..ž
>
>
IIRC, Novell offers the same kind of strict locking that Win32 does.
>2. I can run an access database on a windows share and have multiple people
>access it and write to it.
>
>
* Are you sure that writes to different areas in the database are
concurrent?
* What happens to the database if the client process crashes (or the
network connection dies, for example) before writes are complete?
>3. How can I do the same w/ BDB w/o a server?
>
>
Very, very carefully. Concurrent access is not the only problem.
Crashes, network outages, etc. etc. can cause no end of grief with a
remote database that can be avoided or guarded against with a local
database.
>4. Does BDB mmap files?
>
>
Yes. So does every database engine that cares about performance, but
most databases don't even give you the option of running without a server.
>5. Will this problem go away if we used something like SQLite instead of BDB?
>
>
I have no idea.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release candidate patch for adding external locking
filecode to svn_repos_open
Posted by Files <fi...@poetryunlimited.com>.
Ok. I'm a little confused here.
1. I can run an access database on a novell share, and have multiple people
access it and write to it..
2. I can run an access database on a windows share and have multiple people
access it and write to it.
3. How can I do the same w/ BDB w/o a server?
4. Does BDB mmap files?
5. Will this problem go away if we used something like SQLite instead of BDB?
I'm sorry if I'm asking questions that should be obvious. I'm not that
familiar with the internal architecture of BDB.
Anyway. I'm going to bed. I hope wiser heads than I can come up w/ a solution
for local repositories across SMB.
--
Shamim Islam
BA BS
Branko ?ibej said:
> Files wrote:
>
>>I mean, we could always use a MS-Access backend - at least that would allow
>>
> Access is written specifically for Win32 and obviously uses its remote
> locking features. CIFS does provide safe, strict remote locks, but I'm
> still 99% certain that Access uses a single lock per database.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release candidate patch for adding external locking
filecode to svn_repos_open
Posted by Branko Čibej <br...@xbc.nu>.
Files wrote:
>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).
>
>
Access is written specifically for Win32 and obviously uses its remote
locking features. CIFS does provide safe, strict remote locks, but I'm
still 99% certain that Access uses a single lock per database.
It's quite possible that BDB would run just fine on a Windows shared
directory, except that you need exclusive access to any files you mmap.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release candidate patch for adding external locking
filecode to svn_repos_open
Posted by Files <fi...@poetryunlimited.com>.
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 <ro...@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
Re: [PATCH] Release candidate patch for adding external locking filecode to svn_repos_open
Posted by kf...@collab.net.
Garrett Rooney <ro...@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
Re: [PATCH] Release candidate patch for adding external locking
filecode to svn_repos_open
Posted by Sir Woody Hackswell <wo...@hackswell.com>.
On Tue, 4 Nov 2003, Garrett Rooney wrote:
> 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.
>
> -garrett
I would agree with you, Garrett, but I know the situation that poor David
Kopp is in.
There are SOME network installations in which you are not permitted a
server. The US Government is extremely anal about software getting
installed. Sometimes it takes 6-12 MONTHS to get approval for a new piece
of software.
If David actually got permission for Subversion, I congradulate him. I also
see that he's been working with the group to make the best patch available,
and taking many suggestions.
Even he admits it's a hack, but he has no other option short of NOT using
Subversion. I'm sure there ARE other paranoid installations like his in the
world. (SADLY).
Just my $0.03.
-Woody!
-----
Oh Oracle wise:
Why do Haikus make me sad?
I don't understand.
Sir.Woody@Hackswell.com http://sir.woody.hackswell.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release candidate patch for adding external locking filecode to svn_repos_open
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Nov 4, 2003, at 6:12 PM, David Kopp wrote:
> Hello again,
>
> I have made a few modifications to Shamim's patch and come up with the
> attached patch.
>
> I moved some of the functions to the top of the file in order to
> satisfy
> the compiler. I also removed lock_time from svn_repos_t and made it a
> static variable of create_external_lock_if_requested. (It doesn't work
> otherwise).
>
> So, what do the rest of you think? I would like to have this added,
> because then I would be able to use Subversion at work.
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.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release candidate patch for adding external
lockingfilecode to svn_repos_open
Posted by Files <fi...@poetryunlimited.com>.
David,
If the lock_time can't be in the repos_t, something else needs to be.
The real behavior that we're presenting is that the system only attempt to
lock once per repository.
Since you had originally had the lock_time set to 0 and then set it to a value
later, I used that.
It doesn't need to be lock_time. But there needs to be a sentinel. Otherwise,
you retry the lock each time.
I'm looking to try the lock only once. A singleton operation. per instance of
the repository.
It's a per-repository lock, so if there is more than one repository being
accessed via svn:externals or what not, you run into issues.
It's also a per-repository option.
What is the behavior when you have the lock_time located in the repos_t???
Am I making any sense?
Thanks.
--
Shamim Islam
BA BS
David Kopp said:
> Hello again,
>
> I have made a few modifications to Shamim's patch and come up with the
> attached patch.
>
> I moved some of the functions to the top of the file in order to satisfy
> the compiler. I also removed lock_time from svn_repos_t and made it a
> static variable of create_external_lock_if_requested. (It doesn't work
> otherwise).
>
> So, what do the rest of you think? I would like to have this added,
> because then I would be able to use Subversion at work.
>
> David Kopp
>
>
> ---------------------------------------------------------------------
> 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