On Sep 6, 2006, at 09:15, Timothy Madden wrote:
> I will try rsync. Still overwriting all my images/ and jpeg/ folders,
> even locally, might be a problem.
but the point of rsync is to pull only the files that have actually
changed... if all the images have changed, then surely you want all
the images to be updated, and if only a few images have changed, then
only those few images will be updated.
> Having my working copy accessible by the web server will solve the
> multiple developers problem,
> but otherwise is like turning the public folder into a wc. My problem
> is I have multiple aliases for
> the public folder, one for each client, and each of them has its own
> configuration. If I duplicate the
> public folder into a number of working copies, the number of aliases
> to maintain multiplies
> accordingly. However I think this is what I will have to do when I
> have some colleagues working
> with me on my project.
Again I don't understand why you would need to define an alias for
each working copy. We certainly didn't. But then again I know nothing
about IIS.
> My terrible web server is IIS on Windows 2000 Server. I know it is not
> an interesting web server
> but it is my client's choice and they also have custom script engines
> integrated that only work with
> IIS so they can not drop it. IIS can deny access to a particular
> folder (be it .svn or other) but
> there is no rule to deny access to any folder in the web site named
> .svn. I will have to manually
> deny access to all of them.
Well, on your development server I would think that you don't need to
worry about denying access to these directories since it's a
development server and all people who access it are trustworthy
developers. And on your production / live server you can check out a
working copy to somewhere that's not in the web space, then "svn
export" that to a place that is under the web space, which takes care
of the .svn directories.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 6 11:17:21 2006