On 1/25/06, Dan White <dwhite@clubmom.com> wrote:
> We've been using svn and trac for a number of development projects.
> When it came time to build a content management system, we felt that
> with its webdav support and easily implement hooks, svn would be a
> good repository for all of our content. We created a new empty
> repository on the same redhat box that hosts our development
> repositories and trac. Unfortunately we didn't consider how repository
> level versioning (which has no benefit in this application) would
> inflate the db size. Some 6000 files, each only a few kb in size, and
> 62000 revisions later, our /db/revs dir is about 19gb in size and
> growing almost 1gb daily. We never have multiple file commits.
>
> Did we just pick the wrong version control app for our needs? Is there
> something we can do to compact the db or decrease the rate at which it
> grows? Does anyone have suggestions for another app that does file
> level versioning and supports webdav and hook scripts?
Could the CMS be implemented differently, such that you do have
multiple file commits? I'm thinking about some kind of "holding area"
where changes are saved, but not committed until the user explicitly
does so. Even if it wasn't a multiple commit, maybe just reduce the
number/frequency of saves into Subversion.
In the past, CMSs I have worked with have stored the data in an RDBMS,
with each change of the content writing a new record to the table. We
never considered using version control software like SVN, but then
again we only ever had Endevor for the mainframe and VSS for other
code (assuming the project used source control in the first place).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 27 04:53:06 2006