On Wed, 21 Dec 2011 19:44:50 -0000 "Eric" <e...@deptj.eu> wrote: > On Wed, December 21, 2011 7:31 pm, Mike Meyer wrote: > > On Wed, 21 Dec 2011 20:21:18 +0100 > > Ramon Ribó <ram...@compassis.com> wrote: > >> > Another issue is that an SCM system is _not_ a backup tool, but > >> > many people seem to think that it is. > >> Why not? Do you have the truth about what a SCM must and must not > >> do? > >> One of the nice things about a SCM system is that, in addition to > >> more important features, it IS ALSO a backup tool. > > A backup tool stores files for later retrieval. If your SCM doesn't > > do that, it's not much of a SCM. > Missing the point entirely.
Yes, you did. In your other message, you said "And backup is for all your files". That's true - you need to backup all your files. But files have different sources, uses and values, so may well be backed up with different strategies. Which may well call for different backup tools. Any tool that can store files for later retrieval could be part of such a system, and hence is a backup tool. On my desktop system, I use mirroring, snapshots, install media, the SCM, a LAN backup, a cloud server and fs duplicates as part of my backup strategy. I use Perforce to backup /etc and /usr/local/etc for a number of reasons. One is that I can put the server on a different system, so get non-local backups without further effort. Another is that it stores *everything* on the server, so there's no SCM cruft in /etc or /usr/local/etc, and I can recreate them *from scratch*" with a simple "p4 sync -f". Using a DSCM would be more complicated. <mike _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users