Hi, long time reader, first time caller. Many years ago I used fetchmail+Mutt to handle my mail, but all my configuration was lost in a hard drive crash and I didn''t have the energy to recreate it. So as I look at sup, I am judging how difficult it is to keep its configuration in a git repo (for easier replication and backup). One problem I see is that sources.yaml contains both all the information about how to access a source, and its current state. I would like to keep the first in version control, and the second not. So I would like sources.yaml split into a sources.yaml and a sources-state.yaml; the first one would be the information about how to access the sources, and the second one would map source ID to its cur_offset. What do you think? Ethan
Excerpts from Ethan Glasser-Camp''s message of Fri Mar 27 18:22:06 +0100 2009:> Hi, long time reader, first time caller. > > Many years ago I used fetchmail+Mutt to handle my mail, but all my > configuration was lost in a hard drive crash and I didn''t have the > energy to recreate it. So as I look at sup, I am judging how difficult > it is to keep its configuration in a git repo (for easier replication > and backup). > > One problem I see is that sources.yaml contains both all the information > about how to access a source, and its current state. I would like to > keep the first in version control, and the second not. So I would like > sources.yaml split into a sources.yaml and a sources-state.yaml; the > first one would be the information about how to access the sources, and > the second one would map source ID to its cur_offset.I keep my sup configuration including the whole sources.yaml file in a darcs repository. Even if the data was split in two files I would prefer to also save it. About backups, I recommend sup users to make regular sup-dump''s, not only because sup still have bugs but also because it''s the only (meta)data needed to reconstruct your index. **NOTE to sup developers** Moreover I think that sup should write a log file being some kind of sup-dump delta: messageid (oldlabel1 oldlabel2 -> oldlabel2 newlabel3) ... I think I will try to implement this feature soon. -- Nicolas Pouillard
Nicolas Pouillard wrote:> I keep my sup configuration including the whole sources.yaml file in a > darcs repository. Even if the data was split in two files I would prefer > to also save it.Really? How often do you commit? Certainly not every mail message.. Aren''t you uncomfortable with your working copy becoming dirty every time you receive mail? Ethan
Excerpts from Ethan Glasser-Camp''s message of Tue Mar 31 06:57:38 +0200 2009:> Nicolas Pouillard wrote: > > I keep my sup configuration including the whole sources.yaml file in a > > darcs repository. Even if the data was split in two files I would prefer > > to also save it. > > Really? How often do you commit? Certainly not every mail message.. > Aren''t you uncomfortable with your working copy becoming dirty every > time you receive mail?I commit when I make a change to the configuration, add a contact, change a hook, or add a label. So yes essentially my working copy always have unrecorded changes, and I do not consider this harmful. -- Nicolas Pouillard
I keep my .sup on local storage and rsync it to nfs nightly (so it gets included in the backups). I auto-commit the .sup.bak (nfs copy) nightly into git. I also do manual commits any time I make a config change. -Ben On Tue, Mar 31, 2009 at 7:39 AM, Nicolas Pouillard <nicolas.pouillard at gmail.com> wrote:> Excerpts from Ethan Glasser-Camp''s message of Tue Mar 31 06:57:38 +0200 2009: >> Nicolas Pouillard wrote: >> > I keep my sup configuration including the whole sources.yaml file in a >> > darcs repository. Even if the data was split in two files I would prefer >> > to also save it. >> >> Really? How often do you commit? Certainly not every mail message.. >> Aren''t you uncomfortable with your working copy becoming dirty every >> time you receive mail? > > I commit when I make a change to the configuration, add a contact, change > a hook, or add a label. So yes essentially my working copy always have > unrecorded changes, and I do not consider this harmful. > > -- > Nicolas Pouillard > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk >-- --------------------------------------------------------------------------------------------------------------------------- Ben Walton <bdwalton at gmail.com> "With or without religion, good people can behave well and bad people can do evil; but for good people to do evil?that takes religion. " -Steven Weinberg ---------------------------------------------------------------------------------------------------------------------------
Hi,>From Nicolas Pouillard: > Excerpts from Ethan Glasser-Camp''s message of Fri Mar 27 18:22:06 +0100 2009: > > Hi, long time reader, first time caller. > > > > Many years ago I used fetchmail+Mutt to handle my mail, but all my > > configuration was lost in a hard drive crash and I didn''t have the > > energy to recreate it. So as I look at sup, I am judging how difficult > > it is to keep its configuration in a git repo (for easier replication > > and backup). > > About backups, I recommend sup users to make regular sup-dump''s, not only > because sup still have bugs but also because it''s the only (meta)data > needed to reconstruct your index.For backup, I keep my configuration files into a git repository. I create the following pre-commit hook to create automatically sup-dump''s on each commit. $ cat > .git/hooks/pre-commit <<EOF #/bin/sh sup-dump > sup.dump git add -f sup.dump EOF For replication, you can also define the post-update hook as $ cat > .git/hooks/post-update <<EOF #!/bin/sh sup-sync --restored --restore sup.dump EOF which reconstruct your index when you pull new commits. -- David