The one other tidbit that I'd add is ... experiment! Don't let your first try at setting up a repository be your production setup. Try different repository layouts. The online subversion book walks you through the issues, but I'd caution against making a decision without trying stuff out. Create your repo (I use Subversion, but that's no knock against Git or Darcs or Mercurial or ...). Check out or clone a copy. Edit some files. Rearrange directories. Commit the changes. Rinse, lather, repeat -- several times. Ask yourself if the layout is good, if the repository workflow dovetails with the way you work, if the client-side tools work well with the various operating systems in your environment. If you'll rely on a central, official repository, figure out a backup strategy. It's good to figure out a template for commit messages: what information needs to be provided to document the "why" of changes. There are few things more annoying than an empty or meaningless commit message. Finally, if your repository goes hand-in-hand with a lot of meta-information like documentation, trouble tickets, milestones, or things like screenshots, think about associating your repository with a wiki like Trac: http://trac.edgewall.org/ -- Paul Heinlein <> heinlein@xxxxxxxxxx <> http://www.madboa.com/ _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos