I think you have the right balance. One single repo for everything might be
taking it too far, a small, finite number of repos that doesn't change very
often at all seems the right balance.
My mistake was that I did begin creating new repositories whenever I started
work on anything that could be called a new 'project', and then things started
to become a problem.
On Fri, Feb 27, 2009 at 01:55:16PM -0500, Joey Hess wrote:
> tchomby wrote:
> > * You are less likely to lose files. With many small repos, it becomes
> > almost
> > as easy to lose an entire repo as it was to lose a file before you started
> > versioning your homedir.
> I have worried about this too. If you're making new small repos on a
> daily basis, then it would be easy to forget to push one out of your
> laptop, and lose it in one of the disasters laptops seem to make so
> Also, old repos that are no longer used, and that you even stop
> checking out, become one server failure and backup oops away from being
> lost forever.
> > * With one big repo git log gives you a global history of all your files,
> > a
> > sort of log of what you've been doing on a day-to-day basis. This can be
> > really
> > handy. For example I have to meet with my supervisors every few weeks.
> > Instead
> > of using my memory I can just use git log to help me construct a progress
> > report.
> Yeah, I sometimes wish I could make mr construct an interleaved log of
> all the repos it runs on.
> > All in all I don't understand why many small repos is the recommended
> > approach,
> > sounds like making something simple into something complex. What
> > disadvantages
> > does one big repo have?
> I think that most of the disadvantages of using one big repo can be
> ignored until you have to share (part of) that repo with others.
> Note that wanting to check things out onto multiple machines
> eventually will tend toward the same set of problems that sharing
> the repo with others will present.
> So, some of the specific problems include:
> * Participating in typical free software development, which really
> demands one repo per project. Or working for an employer, who probably
> doesn't want their files in your personal repo.
> * Needing to keep some set of files private (not letting others see
> them), and some other set *very* private (only on one or two machines).
> * Wanting to check large data files into a repo, but not having space
> to put that repo on some machines.
> * Having automated commits to some files (of achived mail, for example),
> and not wanting to see that in your general history, or deal with
> the merging/up-to-dateness issues it can entail.
> * Wanting to host some files on one server (perhaps one that is
> well-connected to the world), and others on another (perhaps one
> at home, or at work).
> I use a mixed approach:
> * I have separate repos for files of well-defined types, like mail,
> sound files, personal docs, personal programs, and my web site.
> Basically, one for each top-level directory of my home directory.
> * I have separate repos for each free software (or work) project I am
> involved with, and if I start a new project, I start a new repo for it.
> For me, this means only a few new repos each year, hopefully.
> * I have a (over?)complicated set of several repos for my dotfiles, so
> that I can have one repo with a minimal set that doesn't take much
> space, another that adds in the larger stuff, and another that adds
> private dotfiles.
> Occasionally, something will start out in one place and have to move to
> another (ie, mr started out in my personal programs and moved to a
> standalone package). But most of the time, there's one obvious place to
> put any given file, with an existing repo that replicates it in a way
> that's appropriate for that type of file.
> see shy jo
> vcs-home mailing list
vcs-home mailing list