On 10/13/06, Phyrefly <phyrefly.phyre@gmail.com> wrote:
>
> > If you're using svnserve, and you should be, you probably want the repo
> on
> > the server's local drive.
>
> I am trying to use it, yes. But the server's data drives (although
> mapped) are not local to the server (on our actual dev environment,
> where I am at the moment (sandbox server) it's all one machine, but I
> can't even get it working here!)
I'm not quite following your setup. You do realize that mapped drives exist
only in the context of a logged in user? For svnserve, you'll need to
specify a UNC path and ensure the account that is running svnserve has
access permissions to the UNC path. I hope you're using gigabit ethernet.
I'd recommend you start with storing your repo local to the server to get
started. Get one thing working at a time.
> The hook script do run on the server when you access the repo using
> > svnservice but you're using file:// access so the server and client are
> the
> > same machine.
>
> I can use file:// successfully across the network too
> (file://IP.Address/folder). This runs the hook script on my pc, not
> my sandbox server. Will this not be a problem when I get svn:/// to
> work?
It depends where you want the hook script to run: on the server or the
client.
> Are you certain you want a shared dev environement? As a developer, I hate
> > to use shared environements because I'm never sure when a problem is due
> to
> > my change or something Bob changed. And I would never want my dev
> > environement, shared or not, to be automatically updated without knowing
> > when or what was updated.
>
> I have no choice, unfortunately. Because it's a web project (or more
> accurately collection of projects) - and management won't let us run
> IIS on our local machines, we need to put the changes on the dev
> server to see the result. So there will be people doing HTML/design
> work, then I'll pick it up and do the ASP bits, then give it back for
> them to neaten up the look and feel again. Conflicts and/or
> "who-broke-what" situations aren't a big problem, but the environment
> does need to be kept up to date. This is why we want Subversion, so
> at least I can say "no, you've deleted all my code" and roll-back,
> rather than having to do it all again.
Yeah, unfortuantely, I understand completely. This is precisely the
situation I was describing. Regardless, it's not clear if you have a
distinct working copy from the "dev server" or not. Please clarify your
working environment.
> In my experience, this error is caused a software firewall running on the
> > server.
>
> No good... there's no software firewall running (and I'm trying to
> connect from the local machine as well as from my PC, and neither
> works).
Did you follow the specific instructions in the svn book for svnserve? For
example, what do the following commands do, assuming the svn binaries are in
your path?
mkdir c:\tmp\svn
svnadmin create c:\tmp\svn
svnserve -d -r c:\tmp\svn
You should be able to use either the svn client or TortoiseSVN to connect to
svn://localhost and view the repo. You won't be able to make any changes
though until you either add yourself to C:\tmp\svn\conf\passwd or enable
anonymous changes in svnserve.conf.
Received on Fri Oct 13 16:17:32 2006