Also, any PC with any life in it is jeliously guarded for use in
running tests. Then, when one does die, any usable parts are
immediately scavenged and the rest put out for recycling.
In theory, I could install Apache and svnserver on one of these PCs,
but any PC not running a test is fair game to anyone who wants it for
a test. If we were to hide it, some one would miss it and start
looking for it. Not a good option for running a server.
On 8/31/07, Andy Levy <andy.levy@gmail.com> wrote:
> On 8/31/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> > Ron Wilson wrote:
> > > On 8/31/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> > >> Strip, David R wrote:
> > >>> I was not aware of the vulnerability under FILE://, but now that you
> > >>> mention it, I'm guessing the problem arises when two (or more) people
> > >>> try to commit (or otherwise modify) the repository at the same time.
> > >>> Since FILE:// provides no directory level locking, you can get seriously
> > >>> hosed. Is that the issue?
> > >> Whether directory level locking is available or not depends fully on the
> > >> network protocol and the filesystem on the server. If both support it,
> > >> Subversion can use it and you will be fine even if multiple accesses
> > >> happen at the same time. But lets face it: there simply isn't a network
> > >> that stable to never have problems. And one cut connection is enough to
> > >> leave a lock in the repository - you will have to execute an 'svnadmin
> > >> recover' on the repository before any other access will be possible.
> > >> And of course, if you run that command over the network and someone
> > >> tries to access the repo that very moment, your repository could get
> > >> screwed beyond repair. (svnadmin recover can't lock - it has to *remove*
> > >> left over locks, that's why an access at that time is fatal).
> > >
> > > Unfortunately, there are some environments where the file:/// method
> > > is the only option. I am working in such an environment. It is very
> > > hard to get the IT people to grant us a DB on the MS SQL server or
> > > even a MS extension to IIS, let alone get them to set up any other
> > > kind of server. We were able to get a server folder under which we put
> > > all our group's shared resources, including the SVN repositories.
> > > (Fortunately, they long ago gave up on trying to support the "arcane"
> > > needs of embedded software development and give us admin rights to our
> > > PCs.)
> >
> > Believe me, I know what you're going through. But there's a better
> > solution: use one of your 'old' PC's (you *do* get a new computer once
> > in a while? I doubt that you're still using a 200MHz PentiumII with
> > Win3.1 on it), put a basic Linux on there (no KDE or Gnome or other
> > heavy stuff), add Apache and SVN. Then write a two line script which
> > dumps all the repositories and copies them to the 'big' server (you have
> > already shared folders there which get backed up), then call that script
> > from a cron job every day at midnight.
> > Put that old PC then somewhere in a dark corner in your office where
> > your IT guys can't find it and they'll never know...
> > (in case you're wondering: that's what we did at my former company)
>
> They can still find it - or not allow it to grab an IP address in the
> first place. In some environments, putting an unauthorized machine on
> the network is serious trouble.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
> For additional commands, e-mail: users-help@tortoisesvn.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Sat Sep 1 00:37:44 2007