13

I was overseeing branching and merging throughout the last release at my company, and a number of times had to modify our Subversion pre-commit hooks to enforce different requirements on check-in comments and such. I was a bit nervous every time I was editing those files, because (a) they're part of a live production system, albeit only used internally (and we're not a huge organization), and (b) they're not under version control themselves.

I'm curious what sort of fail-safes people have in place on their version control infrastructure. Daily backups? "Meta" version control? I suppose the former is in place here as part of the backup of the whole repository. And the latter would be useful as the complexity of check-in requirements grows...

Owen
  • 7,494
  • 10
  • 42
  • 52
  • 3
    What are you going to use to version control the version control for the version control? :-P – Jason Baker Jan 12 '09 at 22:28
  • You put the version control configuration in the bug tracking software under a bug called "How do I setup our version control?" See my answer below. – jmucchiello Jan 12 '09 at 22:31
  • @Jason: That's what brought me to asking the question here! The infinite recursion potential... – Owen Jan 12 '09 at 22:39

4 Answers4

7

Natch - the version-control and any other infrastructure code is also under version-control but I would use a separate project from any development project.

I prefer a searchable wiki or similar knowledge-base repository to clogging up your bug-tracking system with things like VCS config.

Most importantly, make sure that the documentation is kept up to date - in my experience, people are vastly better at keeping code docs up to date than admin docs. This may have been the individuals concerned . One thing that is often overlooked is, if systems are configured according to standard Unix Practices or similar philosophy, that implies a body of knowledge about locations that may not be familiar to an OS/X or Windows programmer, faced with suddenly fixing a broken script. Without being condescending, make sure basic assumptions about location and interdependency are documented.

Andy Dent
  • 17,578
  • 6
  • 88
  • 115
4

You should document all "setup" configuration for all your tools and these documents should be checked into version control. For tools with text file configurations which allow comments, you could just checkin the config file. But for tools that require using the interface, you should have a full document with images of the dialog boxes showing what choices are chosen.

Most importantly though, these documents should say WHY you have set the values chosen (when not taking the default).

Second, as backup, the same documents should be included in your bug tracking software under a "How do I setup the version control software?" bug. (The bug tracking database is located on a different physical server, right?)

Third, all of this should be backed-up off-site. I'm sure there question on SO about backup strategies.

jmucchiello
  • 18,754
  • 7
  • 41
  • 61
  • The obvious catch is that you need to make sure you update your documentation when the setup changes. What do you do to ensure that this happens? – Steve S Jan 12 '09 at 23:26
  • How do you know your backups can be restored? Short of opening the documents, following the instructions, and seeing you end up with the same environment you have now, nothing can ensure that you follow the process. Who makes sure bug fixes are documented? It simply IS someone's responsibility. – jmucchiello Jan 13 '09 at 00:03
4

What's wrong with using the same version control repository for the commit hooks and other configuration files? That's how I've handled it in the past when I've been responsible for a project's configuration management.

You should also back up your svn repository. That way if the repository itself becomes corrupted or the server catches fire or something, you can recover both your project and the svn control files.

Bill Karwin
  • 538,548
  • 86
  • 673
  • 828
  • Yeah, our repo gets regular backups, so I guess that's something. I just didn't see it being straightforward having the repository config files as part of the repo itself, but maybe it really is and I just didn't think it through entirely. – Owen Jan 12 '09 at 22:38
0

If you have build scripts that are doing this (such as Nant) then you could be checking in those.

Jeff Martin
  • 10,812
  • 7
  • 48
  • 74
  • Our build scripts are checked in. What is the "this" when you refer to "scripts that are doing this"? – Owen Jan 12 '09 at 22:41