You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andrew R Feller <af...@lsu.edu> on 2007/04/05 18:52:22 UTC
Pros and cons of significantly large repositories
Hi,
My company is currently trying to use Subversion not only to store code
for new projects but also dumping of binary builds and internal
documentation (processes, meetings, etc). The question most often asked
is "Are you going to use a single repository or multiple repositories?"
I know a Subversion repository can hold any amount of data, but I want
to know is:
What are the pros and cons for having really large repositories versus
multiple, smaller repositories?
What experiences have people had with repository administration and
general usage that have made a particular choice good or bad?
I appreciate your feedback and insight!
Regards,
Andrew
Re: Pros and cons of significantly large repositories
Posted by Sheryl <gu...@his.com>.
Brian Besterman wrote:
> We use a single Subversion repository to manage both source code and
> other types of documents. We have subtrees within the repository
> devoted to different projects and uses. For example, in addition to
> code we create a lot of Excel documents which reside in a general
> document subtree. It is very convenient to be able to retrieve older
> versions of these documents.
I'm in the process of upgrading my subversion servers to handle files >
2GB because we want to see if it can handle versioning of desktop image
files. The idea is to give techs a central place to pick up the current
version and a way to comment on the reason for changes, pick up a previous
release to see if it solves a problem, etc. To some extent this could be
done with a web page, but more control would be possible with subversion.
Sheryl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Pros and cons of significantly large repositories
Posted by "Johnson, Deron" <DL...@firstcommand.com>.
We have a repository with about 12,000 revisions (about 5 GB total
space) and it is still pretty speedy. However we have a pdf folder with
quite a bit of space and files in it and it does take around 20-30
seconds to open this folder. Anyone have suggestions or experience
speeding something like this up?
________________________________
From: Brian Besterman [mailto:bbesterman@walkerdigital.com]
Sent: Tuesday, April 10, 2007 8:57 AM
To: users@subversion.tigris.org
Subject: Re: Pros and cons of significantly large repositories
We use a single Subversion repository to manage both source code and
other types of documents. We have subtrees within the repository
devoted to different projects and uses. For example, in addition to
code we create a lot of Excel documents which reside in a general
document subtree. It is very convenient to be able to retrieve older
versions of these documents.
The reason we have a single repository is due to our use of the Trac
wiki system, which as far as I know can only reference one repository.
I would also think that the maintenance of a single repository might be
easier than multiple ones. Our repository is about 6 GB, with ~7500
revisions over the last 4 years, and we haven't had any major issues.
Brian Besterman
Walker Digital Gaming, LLC
On Apr 10, 2007, at 8:35 AM, Andrew R Feller wrote:
Matt,
Quoting the Subversion website (http://subversion.tigris.org
<http://subversion.tigris.org/> ), "The goal of the Subversion project
is to build a version control system that is a compelling replacement
for CVS in the open source community."
Quoting the CVS website (http://www.nongnu.org/cvs/
<http://www.nongnu.org/cvs/> ), "CVS is a version control system, an
important component of Source Configuration Management (SCM). Using it,
you can record the history of sources files, and documents."
I agree that most people use version control for application code bases,
however, I think you will find that many people use it for its intended
purpose: to track changes in whatever documents/files you deem important
to review and maintain over a length of time by multiple people. If you
don't care about history and being able to revert mistakes, then by all
means use rsync and keep the files on your filesystem outside of
Subversion. I don't see how Subversion or any version control system is
a "code only" tool and I believe most people would agree with that.
Andrew R Feller, Analyst
University Information Systems
Louisiana State University
afelle1@lsu.edu <ma...@lsu.edu>
(office) 225.578.3737
________________________________
From: Matt Sickler [mailto:crazyfordynamite@gmail.com]
Sent: Monday, April 09, 2007 12:57 PM
To: Andrew R Feller
Cc: users@subversion.tigris.org
Subject: Re: Pros and cons of significantly large repositories
subversion was meant to version source code, not distribute notes and
binaries
another tool such as rsync would be better at the latter
On 4/5/07, Andrew R Feller <afelle1@lsu.edu <ma...@lsu.edu> >
wrote:
Hi,
My company is currently trying to use Subversion not only to store code
for new projects but also dumping of binary builds and internal
documentation (processes, meetings, etc). The question most often asked
is "Are you going to use a single repository or multiple repositories?"
I know a Subversion repository can hold any amount of data, but I want
to know is:
What are the pros and cons for having really large repositories versus
multiple, smaller repositories?
What experiences have people had with repository administration and
general usage that have made a particular choice good or bad?
I appreciate your feedback and insight!
Regards,
Andrew
______________________________________________________________________
This email has been scanned by MessageLabs Email Security System for
spam, virus, and inappropriate content.
______________________________________________________________________
STATEMENT OF CONFIDENTIALITY: The information contained in this message or any attachments to this message are intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material as well as being protected from disclosure. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is strictly prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer.
Re: Pros and cons of significantly large repositories
Posted by Brian Besterman <bb...@walkerdigital.com>.
We use a single Subversion repository to manage both source code and
other types of documents. We have subtrees within the repository
devoted to different projects and uses. For example, in addition to
code we create a lot of Excel documents which reside in a general
document subtree. It is very convenient to be able to retrieve older
versions of these documents.
The reason we have a single repository is due to our use of the Trac
wiki system, which as far as I know can only reference one
repository. I would also think that the maintenance of a single
repository might be easier than multiple ones. Our repository is
about 6 GB, with ~7500 revisions over the last 4 years, and we
haven't had any major issues.
Brian Besterman
Walker Digital Gaming, LLC
On Apr 10, 2007, at 8:35 AM, Andrew R Feller wrote:
> Matt,
>
>
>
> Quoting the Subversion website (http://subversion.tigris.org), “The
> goal of the Subversion project is to build a version control system
> that is a compelling replacement for CVS in the open source
> community.”
>
> Quoting the CVS website (http://www.nongnu.org/cvs/), “CVS is a
> version control system, an important component of Source
> Configuration Management (SCM). Using it, you can record the
> history of sources files, and documents.”
>
>
>
> I agree that most people use version control for application code
> bases, however, I think you will find that many people use it for
> its intended purpose: to track changes in whatever documents/files
> you deem important to review and maintain over a length of time by
> multiple people. If you don’t care about history and being able to
> revert mistakes, then by all means use rsync and keep the files on
> your filesystem outside of Subversion. I don’t see how Subversion
> or any version control system is a “code only” tool and I believe
> most people would agree with that.
>
>
>
> Andrew R Feller, Analyst
>
> University Information Systems
>
> Louisiana State University
>
> afelle1@lsu.edu
>
> (office) 225.578.3737
>
> From: Matt Sickler [mailto:crazyfordynamite@gmail.com]
> Sent: Monday, April 09, 2007 12:57 PM
> To: Andrew R Feller
> Cc: users@subversion.tigris.org
> Subject: Re: Pros and cons of significantly large repositories
>
>
>
> subversion was meant to version source code, not distribute notes
> and binaries
> another tool such as rsync would be better at the latter
>
> On 4/5/07, Andrew R Feller <af...@lsu.edu> wrote:
>
> Hi,
>
>
>
> My company is currently trying to use Subversion not only to store
> code for new projects but also dumping of binary builds and
> internal documentation (processes, meetings, etc). The question
> most often asked is "Are you going to use a single repository or
> multiple repositories?" I know a Subversion repository can hold
> any amount of data, but I want to know is:
>
>
>
> What are the pros and cons for having really large repositories
> versus multiple, smaller repositories?
>
> What experiences have people had with repository administration and
> general usage that have made a particular choice good or bad?
>
>
>
> I appreciate your feedback and insight!
>
>
>
> Regards,
>
> Andrew
>
>
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by MessageLabs Email Security System
> for spam, virus, and inappropriate content.
> ______________________________________________________________________
Re: Pros and cons of significantly large repositories
Posted by Les Mikesell <le...@gmail.com>.
Andrew R Feller wrote:
> I agree that most people use version control for application code bases,
> however, I think you will find that many people use it for its intended
> purpose: to track changes in whatever documents/files you deem important
> to review and maintain over a length of time by multiple people. If you
> don’t care about history and being able to revert mistakes, then by all
> means use rsync and keep the files on your filesystem outside of
> Subversion. I don’t see how Subversion or any version control system is
> a “code only” tool and I believe most people would agree with that.
Not necessarily code-only, but there are certain features (like readable
diffs) that only work with text files, and there are certain issues
(like never being able to delete anything) that may be more problematic
if you allow many large and obsolete binaries to accumulate. If you do
want use svn as a convenient mechanism for storing and accessing files
when you know that older versions will never be wanted, you might want
to put them in separate repositories that can be restarted periodically
to clean them up instead of having to dump/filter a huge repository
later to sort out what you want to keep. If you access via http(s),
this can be almost transparent.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Pros and cons of significantly large repositories
Posted by Andrew R Feller <af...@lsu.edu>.
Matt,
Quoting the Subversion website (http://subversion.tigris.org
<http://subversion.tigris.org/> ), "The goal of the Subversion project
is to build a version control system that is a compelling replacement
for CVS in the open source community."
Quoting the CVS website (http://www.nongnu.org/cvs/), "CVS is a version
control system, an important component of Source Configuration
Management (SCM). Using it, you can record the history of sources files,
and documents."
I agree that most people use version control for application code bases,
however, I think you will find that many people use it for its intended
purpose: to track changes in whatever documents/files you deem important
to review and maintain over a length of time by multiple people. If you
don't care about history and being able to revert mistakes, then by all
means use rsync and keep the files on your filesystem outside of
Subversion. I don't see how Subversion or any version control system is
a "code only" tool and I believe most people would agree with that.
Andrew R Feller, Analyst
University Information Systems
Louisiana State University
afelle1@lsu.edu
(office) 225.578.3737
________________________________
From: Matt Sickler [mailto:crazyfordynamite@gmail.com]
Sent: Monday, April 09, 2007 12:57 PM
To: Andrew R Feller
Cc: users@subversion.tigris.org
Subject: Re: Pros and cons of significantly large repositories
subversion was meant to version source code, not distribute notes and
binaries
another tool such as rsync would be better at the latter
On 4/5/07, Andrew R Feller <af...@lsu.edu> wrote:
Hi,
My company is currently trying to use Subversion not only to store code
for new projects but also dumping of binary builds and internal
documentation (processes, meetings, etc). The question most often asked
is "Are you going to use a single repository or multiple repositories?"
I know a Subversion repository can hold any amount of data, but I want
to know is:
What are the pros and cons for having really large repositories versus
multiple, smaller repositories?
What experiences have people had with repository administration and
general usage that have made a particular choice good or bad?
I appreciate your feedback and insight!
Regards,
Andrew
Re: Pros and cons of significantly large repositories
Posted by Jared Hardy <ja...@gmail.com>.
On 4/9/07, Matt Sickler <cr...@gmail.com> wrote:
> subversion was meant to version source code, not distribute notes and
> binaries another tool such as rsync would be better at the latter
This statement is almost completely wrong. Subversion was made to
handle binaries internally exactly the same as text files, so its very
good at tracking binary files. To take advantage of any concurrent
edit capability, you need a merge tool for any given binary type. For
example, TortoiseSVN now comes with diff/merge tools and scripts that
work with several common binary file types, like bmp, xls, ods, odt,
doc, etc. Otherwise, you should set the "svn:needs-lock" property on
any binary type that doesn't have an existing merge tool, so you don't
get multiple editors stomping on each other's work. That is pretty
easy to do using auto-props.
The file types that Subversion (and any system that uses delta
compression in the repository) doesn't track very efficiently are
compressed files. You should leave any compression as a step done
after compiling from repo sources. Certain forms of compiled binaries
are thus better to track outside of the repository. If an executable,
for example, compiles consistently and quickly on everyone's
workstations, there's no point to tracking it on a repository. Setting
up a post-update tool, to create compressed binary types from other
source types upon update, might be a better long term solution. For
example, you could write a batch script that creates jpegs from
updated bmp sources, mpeg3s from aif, xvid movies from raw tiff
frames, etc. In other cases, non-version-tracking tools like rsync
might be more appropriate for distributing built files.
Source files, in whatever form, should always be handled by your
version control system. There is no reason to compress source files --
good version control software should handle that for you, like
Subversion does via xdelta. Built files are the only area worth
debating.
:) Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pros and cons of significantly large repositories
Posted by Matt Sickler <cr...@gmail.com>.
subversion was meant to version source code, not distribute notes and
binaries
another tool such as rsync would be better at the latter
On 4/5/07, Andrew R Feller <af...@lsu.edu> wrote:
>
> Hi,
>
>
>
> My company is currently trying to use Subversion not only to store code
> for new projects but also dumping of binary builds and internal
> documentation (processes, meetings, etc). The question most often asked is
> "Are you going to use a single repository or multiple repositories?" I know
> a Subversion repository can hold any amount of data, but I want to know is:
>
>
>
> What are the pros and cons for having really large repositories versus
> multiple, smaller repositories?
>
> What experiences have people had with repository administration and
> general usage that have made a particular choice good or bad?
>
>
>
> I appreciate your feedback and insight!
>
>
>
> Regards,
>
> Andrew
>
>
>