backing up my repositories, anything special needed?

[Dustin Sallings]

On Aug 11, 2007, at 1:37, Ben Hood wrote:

> What strikes me generally is that versioning data and not losing data
> should be separate concerns, IMHO. What I find is that people tend to
> be using the SCM as a backup and so therefore commit incomplete
> changes to the repo for the sake of resilience. I find this annoying
> when I have to backtrack through items of work that are strewn accross
> many changesets. I was wondering if their was any scope to introduce a
> snapshotting extension that could can sent to a remote repo with
> creating a changeset, for the sake of resilience?

	mq does that, but it's a different issue.  I've had far more  
problems with the other side of this.  I knew a guy who wouldn't  
commit anything everything was ``done.''  This meant that his work  
wouldn't be seen by another human until it was time to ship.   
Integration is a *huge* pain when people do this as well.

	 I would much rather have too many commits in a project than too  
few.  I can always bisect or something to figure out when a problem  
was introduced, but if the changesets are large and far between, then  
they start looking more like backups.

	I think more people think of revision control as backups than  
anything else.  I find it easiest to just tell people to commit  
whenever they have anything that works at all.  Keeps integration  
simple and helps people work towards making small distinct changesets.

	Personally, I use mq at work and when I check in code, it's often  
multiple distinct changesets that I send in around the same time.  mq  
lets me get things working while still allowing me to integrate  
changes made by other people and be working on distinct concepts.  I  
can't tolerate having work I've not checked in for more than a couple  
of days, so I at least check in and replicate my mq patches when a  
feature is taking me too long, or the rest of the team isn't ready  
for it.

-- 
Dustin Sallings