I have a question here.... If you do a commit, the only thing that is
changing is the file that you changed for that particular revision. So
each commit is not necessarily adding another 30 GB of data. Unless you
have some wonderfully productive developers, or the individual file
sizes are monstrous, I doubt they could realistically change much more
than 100 MB of files in a single day (on good day). That's not to say
an occassional new file will be larger than that.....
But the key dispute I have is that the commit is only writing the
_CHANGED_ files and not the other 29+ GB of files that are not modified
by your developers on that day.
Food for thought.
Regards,
Frank
Martin A. Brooks wrote:
> Hi
>
> Eric Brown wrote:
>
>> I've read where it doesn't play nice with an NFS.
>>
>
> With the BDB backend that's true. Use FSFS instead.
>
>> We're going to have LOTS of data on here (our baseline is going to
>> be about 30-40Gig). Would like to have some sort of network access
>> to the repository,
>
>
> Subversion can provide that natively with svnserve or using Apache 2.
>
>> and I'd like to backup the repos after every commit. Thinking of
>> using RAID or a SAN. Is this possible?
>>
>
> Possible? Sure.
> Let's assume you're like me. The development team I work for commit 50
> to 60 times per day overall. Let's try some maths here.
>
> 50 times 30gb == 1500Gb of data _per day_. About 18 80gb DLT tapes
> each day, every day.
>
> Maybe you should rethink a little...
>
> Mart.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 7 01:25:58 2005