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...
>
> > 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
down.
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 ;)
> 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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Sep 30 15:50:08 2006