On 9/30/2006 9:49 AM, Marc wrote:
> Hi Tom,
> > > Instead of putting our repositor(ies) on the hosting
> > servers, and
> > > hosting the repositor(ies), the staging sites, and
> > the live sites, I
> > > am going to move ahead with putting a dedicated
> > repository server
> > > right here in our office. It will be a single
> > repository, with a
> > > trunk for EACH website for which we do the
> > development work, and we
> > > will stage the sites on our internal staging server.
> > The live sites
> > > will still be working copies of our local repository.
> > For ease of deployment, I'd definitely recommend the
> > repositories be hosted where they're available on a
> > public IP address!
> We do have a public IP, that's necessary of course.
> > Rather than working copies, I'd recommend exports, but
> > to each his own...
> I thought about that, too, but I seemed to be getting steered towards just
> working copies when I last brought this up. If EXPORTS can be automated
> using post-commit hooks, then I can do that too of course. What do you feel
> is better about exports... The lack of a .svn directory in the final site?
> Another reason why we chose Working Copies as the website publishing method
> was because we can simply do an "update", and grab only those files that
> have changed, making for a fast, well, UPDATE of the site. With exports,
> don't you get the whole codebase over again, each time? For some of our
> sites, that could be a difference between sending up 4 or 5 specific files,
> or sending up the entire web application at 300+mb...
I use working copies in a similar situation, but I imagine there are
ways to avoid copying the whole thing, using rsync, or a post-commit hook.
> > > My question to everyone is, does anyone see a problem with a
> > > repository "this large"? I mean, when we load up all
> > our sites into
> > > it, it's going to be HUGE. And it'll just grow
> > larger with the
> > > revisions. How large should it be allowed to grow?
> > (server has 300GB
> > > RAID 1 right now...)
> > Subversion repositories grow quite efficiently, as it
> > uses many methods to reduce storage space. There are a
> > lot of repositories in the world with a *lot* of code
> > in them (think Apache Software
> > Foundation) and no trouble.
> Gotcha. Very Very Cool.
> > > And at some point, I'm sure I'll need to reduce the
> > amount of history
> > > for each trunk... Is anyone else managing a single
> > large repo? At
> > > what point do you decide to remove some of the early
> > historical
> > > tags/trunk versions?
> > I don't even think there are ways of doing this. Disks
> > are cheap, but the ability to keep all history is priceless!
> Disks are cheap, but the space available to put those cheap disks in is,
> plainly, a PITA. We're repurposing a 2u rackmount server, and it holds a
> total of four drives, and the case is now full. Two mirrored OS drives
> (don't remember their size...), and two mirrored data drives, around 300GB I
> believe. I should think this would be enough for us, to last a long time,
> considering our current server data drive will all the sites, apps AND
> documentation is only around 5.6 GB! ;) We have additional sites on the
> live servers totaling at least another 20-30gb though, that we'll be pulling
> But adding more internal disks to this particular server is out of the
> question, obviously. It looks like we'll be okay.
> > > Lastly... The server I was going to dedicate to this
> > repository is
> > > currently an unused FreeBSD server. I'm still
> > cutting my teeth with
> > > FreeBSD, but know
> > > my way around okay. Setting up subversion on Windows
> > was a SNAP.
> > > Given the
> > > size of the repository being proposed, I assume
> > there's going to be a
> > > lot of files, and we all know how well Windows deals
> > with a lot of
> > > files... But I definitely know Windows Servers
> > better. Should I leave
> > > it as a FreeBSD server for the purpose of it being
> > great with large
> > > directories (and just great in general), or wipe it
> > and put Windows
> > > 2003 Server on it for the purpose of eliminating an area of
> > > inefficiency for myself? Will Windows pretty much choke on a
> > > repository with 70 websites in it?
> > Your call. I'd choose a *nix, and I'd suggest you'd be
> > wise to do so, but not everyone will see it that way.
> Can you still use TortoiseSVN from a client to use "Repo-Browser", to browse
> the repo that would be on the *nix server? (I think I already know the
> answer, but if I am going to be a newbie, I might as well act like one ;)
Yes, the client platform is independent of the server platform.
> > P.S. You haven't mentioned backup in your plans anywhere...
> Yes, we've already planned for backups of the repo server... They will be
> done over the LAN to a backup machine, and from there, out to a
> geographically separate storage area as well.
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Sep 30 16:10:28 2006