Hi Joey, 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 > common. > > 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 > [email protected] > http://lists.madduck.net/listinfo/vcs-home _______________________________________________ vcs-home mailing list [email protected] http://lists.madduck.net/listinfo/vcs-home
