On 08/10/13 01:24, Matt Welland wrote: > What (D)SCM's have that backup systems do not is a way to intelligently > update files in the managed area. I.e. backup systems do not have a > concept analogous to "fossil update" so they cannot gracefully patch in > changes from some other time or location. > > What backup systems have that SCM's generally do not is capacity. > Neither fossil nor git do well with 100's of thousands of files and > terabytes of data. Also most backup systems preserve special files, > named pipes, permissions and sometimes hard links.
FWIW, I think there's a lot of common logic that could be shared between backup systems, archival/document repository systems (a somewhat empty category outside of huge enterprise environments), and SCMs, with relatively minor differences in high-level organisation, user interface, and deployment architecture... The obvious place to start is in sharing the backend blob storage, and standardising the storage paradigm for files and directories into it; then, at least, you'll get de-duplication between the source files in your SCM repo and the checked-out copy of it in your home directory that gets backed up to a shared storage area... > For long term archiving I currently use bup. I'd rather use Alaric's > Ugarit but it doesn't work on my system right now and I haven't had time > to track down the problem. Recent bug hunting escapes in the Chicken Core may have fixed this, by the way - I need to retest a bunch of stuff myself to see if any of the problems I was seeing persist! > However most important of all is using fossil for almost everything of > value. Here I break the rules and use the tool for both revision > control, backup and sync between systems. The purists are recoiling in > horror but it works for me and I love it. I did the same thing with > Monotone for years with great success. The distributed SCM model is > heaven and fossil is a wonderful implementation of that model. I concur. I put everything that matters into fossil (or git or svn or whatever for projects controlled by others with different tastes), to get syncing between machines, sharing between people, and revision history for information and safety in case of user error. This also offers some protection against accidental zapping of the files themselves, but I still like my cron-jobbed daily snapshot backups, as they'll catch any uncommitted work I have! ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
