Re: [fossil-users] Anecdote regarding permissions tracking in Fossil
On 07/10/13 23:27, Joseph R. Justice wrote: On Mon, Sep 23, 2013 at 7:05 AM, Alaric Snell-Pym ala...@snell-pym.org.uk mailto:ala...@snell-pym.org.uk wrote: I've written a backup/archival tool based on content-addressible storage, and a common question people ask is So why don't I just put my home directory/entire filesystem in git, then?, and I have to raise this aspect of the quite different goals between backup and source control :-) I note that there are people who *do* put their home directories, .rc files, etc under source control. (IIRC, I've read stories in, like, Linux Journal, lwn.net http://lwn.net, blog stories, etc.) I have the distinct impression that, often, at least part of the reason for doing this is that the user has multiple systems they regularly use, and they wish to keep the personal configuration details and I suppose also the personal data stored on/for for each system as consistent between systems as is reasonably achievable to achieve. I do that with a fossil repo that I check out in ~/alaric, which .emacs, .bashrc and a few others symlink into. ~/alaric/bin goes on my PATH, etc. But it keeps it all locked away in one subdirectory, and doesn't mean I have a very cluttered fossil extras. ABS 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
Re: [fossil-users] Anecdote regarding permissions tracking in Fossil
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
Re: [fossil-users] Anecdote regarding permissions tracking in Fossil
On 8 October 2013 00:27, Joseph R. Justice jayare...@gmail.com wrote: I note that there are people who *do* put their home directories, .rc files, etc under source control. Indeed, see for example http://episodes.gitminutes.com/2013/06/gitminutes-13-richard-hartmann-on.html - Erlend ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Anecdote regarding permissions tracking in Fossil
On Tue, 08 Oct 2013 00:27:12 +0200, Joseph R. Justice jayare...@gmail.com wrote: On Mon, Sep 23, 2013 at 7:05 AM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote: I've written a backup/archival tool based on content-addressible storage, and a common question people ask is So why don't I just put my home directory/entire filesystem in git, then?, and I have to raise this aspect of the quite different goals between backup and source control :-) I note that there are people who *do* put their home directories, .rc files, etc under source control. (IIRC, I've read stories in, like, Linux Journal, lwn.net, blog stories, etc.) I have the distinct impression that, often, at least part of the reason for doing this is that the user has multiple systems they regularly use, and they wish to keep the personal configuration details and I suppose also the personal data stored on/for for each system as consistent between systems as is reasonably achievable to achieve. I have that demand (keeping ~ 100 GB home directories in sync across two machines) but never would dream of using a revision control system for doing that. what one needs here is a bidirectional synchronizer that keeps track of what has changed (and when) on both sides. I wholeheartedly can recommend unison for this task (http://www.cis.upenn.edu/~bcpierce/unison/) whose capabilities go way beyond basic rsync for this task. Joseph -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Anecdote regarding permissions tracking in Fossil
Joseph R. Justice jayare...@gmail.com writes: I note that there are people who *do* put their home directories, .rc files, etc under source control. (IIRC, I've read stories in, like, Linux Journal, lwn.net, blog stories, etc.) I have the distinct impression that, often, at least part of the reason for doing this is that the user has multiple systems they regularly use, and they wish to keep the personal configuration details and I suppose also the personal data stored on/for for each system as consistent between systems as is reasonably achievable to achieve. I don't go quite so far as to keep my entire home directory under source control, but I do my configuration files, and for more or less the reason you mention: I have multiple computers I use on a regular basis, and I'd like for at least my user experience to be consistent. For the data/files, I think there are better methods of keeping things in sync. But when I make a new change to ~/.emacs or whatever, it sure is nice to just sync the local repository and not to have to remember exactly what change I made on that other machine. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Anecdote regarding permissions tracking in Fossil
On Tue, Oct 8, 2013 at 10:48 AM, Carson Chittom car...@wistly.net wrote: But when I make a new change to ~/.emacs or whatever, it sure is nice to just sync the local repository and not to have to remember exactly what change I made on that other machine. FWIW, for that concrete case i symlink my emacs config to somewhere under my Dropbox, and let Dropbox do the synching for me. Granted, Dropbox isn't always a viable solution (and i don't recommend it for things which generate lots of temp files, e.g. source dirs (==object files) or sqlite databases (==journal files), but for relatively static content it's trivial to use and works well. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Anecdote regarding permissions tracking in Fossil
On Mon, Oct 7, 2013 at 6:27 PM, Joseph R. Justice jayare...@gmail.comwrote: I note that there are people who *do* put their home directories, .rc files, etc under source control. (IIRC, I've read stories in, like, Linux Journal, lwn.net, blog stories, etc.) I have the distinct impression that, often, at least part of the reason for doing this is that the user has multiple systems they regularly use, and they wish to keep the personal configuration details and I suppose also the personal data stored on/for for each system as consistent between systems as is reasonably achievable to achieve. I do want my config file revisioned. Makes it easier to debug problems. My project files (including personal projects) are also revisioned. The Fossil repossitories are both replicated on other PCs the normal Fossil way and backed up, along with my other files, with rsync, to off-site storage. I think purists would still gag at my arrangement. Best as I can tell, to them, it's not backed up until it's copied to removable media and physically transported to a remote storage facility. (An update to an old saying I've heard, Don't underestimate the bandwidth of an SUV filled with SD cards speeding down the highway.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Anecdote regarding permissions tracking in Fossil
On Mon, Sep 23, 2013 at 7:05 AM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote: I've written a backup/archival tool based on content-addressible storage, and a common question people ask is So why don't I just put my home directory/entire filesystem in git, then?, and I have to raise this aspect of the quite different goals between backup and source control :-) I note that there are people who *do* put their home directories, .rc files, etc under source control. (IIRC, I've read stories in, like, Linux Journal, lwn.net, blog stories, etc.) I have the distinct impression that, often, at least part of the reason for doing this is that the user has multiple systems they regularly use, and they wish to keep the personal configuration details and I suppose also the personal data stored on/for for each system as consistent between systems as is reasonably achievable to achieve. Joseph ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Anecdote regarding permissions tracking in Fossil
On Mon, Oct 7, 2013 at 3:27 PM, Joseph R. Justice jayare...@gmail.comwrote: On Mon, Sep 23, 2013 at 7:05 AM, Alaric Snell-Pym ala...@snell-pym.org.uk wrote: I've written a backup/archival tool based on content-addressible storage, and a common question people ask is So why don't I just put my home directory/entire filesystem in git, then?, and I have to raise this aspect of the quite different goals between backup and source control :-) I note that there are people who *do* put their home directories, .rc files, etc under source control. (IIRC, I've read stories in, like, Linux Journal, lwn.net, blog stories, etc.) I have the distinct impression that, often, at least part of the reason for doing this is that the user has multiple systems they regularly use, and they wish to keep the personal configuration details and I suppose also the personal data stored on/for for each system as consistent between systems as is reasonably achievable to achieve. I've tried it all. /etc and home dir in various revision control tools, rsync, unison, etc to sync home directories and or subsets thereof between machines. I even used coda (http://www.coda.cs.cmu.edu/) for a while. I've settled on a methodology of sorts and both agree and disagree with Alaric. The goals of backup and source control are different but the overlap in required behaviour is almost 100% so it is quite natural to think of using SCM tools for backup. 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. For safe data, minimum effort I start with MooseFS to keep my home directory, photos, music, videos etc. spread out over multiple disks and multiple machines. This seems to be a lot less work than using btrfs, zfs or other methods of doing raid whatever. I like that I can replicate my data over three machines in near real time with zero burden on my attention and decent performance. 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. 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. Sometimes the best tool for a job is a whole box of tools ... Joseph ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Anecdote regarding permissions tracking in Fossil
On 19/09/13 20:38, B Harder wrote: And that's why we 1) trust our good judgment, the judgment of our fellow fossil developers, and discuss these sorts of things rather than blindly doing what git does 2) don't conflate a version controlled repository with a release. I've written a backup/archival tool based on content-addressible storage, and a common question people ask is So why don't I just put my home directory/entire filesystem in git, then?, and I have to raise this aspect of the quite different goals between backup and source control :-) 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
[fossil-users] Anecdote regarding permissions tracking in Fossil
Hi, all, some people have bemoaned Fossil's lack of file permissions support over the years. Initially, Fossil did not track _any_ permissions, but the executable bit was eventually added because it is common practice to have an executable configure script in the source tree. What i didn't know, though, is that git doesn't, either. i always assumed git can do anything except except for making me a happy user. To quote the GIT Pocket Guide from O'Reilly[1]: Originally, Git saved and restored the full permissions on files (all the mode bits). Later, however, this was deemed to cause more trouble than it was worth, so the interpretation of the mode bits ... was changed ... the only valid values for the low 12 bits of the mode... are octal 755 and 644, and these simply indicate that the file should be executable or not... the actual mode value may be different depending on your umask setting... [1] http://shop.oreilly.com/product/0636920024972.do http://shop.oreilly.com/product/0636920024972.do-- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Anecdote regarding permissions tracking in Fossil
On Sep 19, 2013 1:38 AM, Stephan Beal sgb...@googlemail.com wrote: Hi, all, some people have bemoaned Fossil's lack of file permissions support over the years. Initially, Fossil did not track _any_ permissions, but the executable bit was eventually added because it is common practice to have an executable configure script in the source tree. What i didn't know, though, is that git doesn't, either. i always assumed git can do anything except except for making me a happy user. To quote the GIT Pocket Guide from O'Reilly[1]: Originally, Git saved and restored the full permissions on files (all the mode bits). Later, however, this was deemed to cause more trouble than it was worth, so the interpretation of the mode bits ... was changed ... the only valid values for the low 12 bits of the mode... are octal 755 and 644, and these simply indicate that the file should be executable or not... the actual mode value may be different depending on your umask setting... And that's why we 1) trust our good judgment, the judgment of our fellow fossil developers, and discuss these sorts of things rather than blindly doing what git does 2) don't conflate a version controlled repository with a release. [1] http://shop.oreilly.com/product/0636920024972.do -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
