[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Recommendation for creating a repo of "docroot"

From: James <hosting_at_outofcontrol.ca>
Date: 2006-09-30 00:03:04 CEST

On Sep 29, 2006, at 3:56 PM, Bill Moseley wrote:

> On Fri, Sep 29, 2006 at 03:42:32PM -0400, James wrote:
>> On Sep 29, 2006, at 3:34 PM, Bill Moseley wrote:
>> We currently do all our sites using this method. Our largest site
>> currently is 41,770 files for a total of 250MB. We develope locally
>> on our Macs and check in changes as we need, using mod_dav_svn.
>> Albeit a bit slow when updating the entire try (roughly 1 minute) we
>> find this works quite well for us. Haven't tried this on anything
>> like 5GB yet.
>>
>> Our file mix is mostly small images and a lot of php scripts.
>
> So everything (or most) is in your repo? My client has these hundred
> megabyte webcasts (quicktime movies -- not a great thing to svn co.
>
> Do you make use of svn:ignore on the clients? Or does everyone have a
> full copy of the repository?
>

Our site is updated on a daily basis from a web-interface by our end
clients. Our developers work on the site locally on their macs, then
update the repos, which in turn updates the dev server automatically
via a post-commit, once every day or so. In order for the dev site
and the local sites to properly be tested we needed the images and
end client files to be present.

All that to say that we tried using svn:ignore on the end clients
files, but ran into problems properly testing our code before going
live. So no, we do not use svn:ignore on any files and everything is
in the repos, with the exception being our MySQL DB's.

We realize this is not the best setup, as having all those files and
images in the repo is a bit uncouth, but it does work well none the
less. We do not use BerkeleyDB and use mod_dav_svn instead of svn://.
We hope to try out our setup with the BerkeleyDB to get a speed
improvement on commits.

James

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Sep 30 00:03:54 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.