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
