Subject: [sup-talk] Config in VCS

From: [email-masked] (Ethan Glasser-Camp)
Date: Fri, 27 Mar 2009 13:22:06 -0400

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

---

From: [email-masked] (Nicolas Pouillard)
Date: Sat, 28 Mar 2009 11:03:40 +0100

> 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

---

From: [email-masked] (Ethan Glasser-Camp)
Date: Tue, 31 Mar 2009 00:57:38 -0400

> darcs repository. Even if the data was split in two files I would prefer

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

---

From: [email-masked] (Nicolas Pouillard)
Date: Tue, 31 Mar 2009 13:39:16 +0200

> Aren't you uncomfortable with your working copy becoming dirty every

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

---

From: [email-masked] (Ben Walton)
Date: Tue, 31 Mar 2009 09:36:51 -0400

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:
> _______________________________________________
> 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
---------------------------------------------------------------------------------------------------------------------------

---

From: [email-masked] (David Guibert)
Date: Wed, 01 Apr 2009 10:41:00 +0200

Hi,

>From Nicolas Pouillard:

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