* [sup-talk] Config in VCS
@ 2009-03-27 17:22 Ethan Glasser-Camp
2009-03-28 10:03 ` Nicolas Pouillard
0 siblings, 1 reply; 6+ messages in thread
From: Ethan Glasser-Camp @ 2009-03-27 17:22 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [sup-talk] Config in VCS
2009-03-27 17:22 [sup-talk] Config in VCS Ethan Glasser-Camp
@ 2009-03-28 10:03 ` Nicolas Pouillard
2009-03-31 4:57 ` Ethan Glasser-Camp
2009-04-01 8:41 ` David Guibert
0 siblings, 2 replies; 6+ messages in thread
From: Nicolas Pouillard @ 2009-03-28 10:03 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [sup-talk] Config in VCS
2009-03-28 10:03 ` Nicolas Pouillard
@ 2009-03-31 4:57 ` Ethan Glasser-Camp
2009-03-31 11:39 ` Nicolas Pouillard
2009-04-01 8:41 ` David Guibert
1 sibling, 1 reply; 6+ messages in thread
From: Ethan Glasser-Camp @ 2009-03-31 4:57 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [sup-talk] Config in VCS
2009-03-31 4:57 ` Ethan Glasser-Camp
@ 2009-03-31 11:39 ` Nicolas Pouillard
2009-03-31 13:36 ` Ben Walton
0 siblings, 1 reply; 6+ messages in thread
From: Nicolas Pouillard @ 2009-03-31 11:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [sup-talk] Config in VCS
2009-03-31 11:39 ` Nicolas Pouillard
@ 2009-03-31 13:36 ` Ben Walton
0 siblings, 0 replies; 6+ messages in thread
From: Ben Walton @ 2009-03-31 13:36 UTC (permalink / raw)
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
---------------------------------------------------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread
* [sup-talk] Config in VCS
2009-03-28 10:03 ` Nicolas Pouillard
2009-03-31 4:57 ` Ethan Glasser-Camp
@ 2009-04-01 8:41 ` David Guibert
1 sibling, 0 replies; 6+ messages in thread
From: David Guibert @ 2009-04-01 8:41 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-04-01 8:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-27 17:22 [sup-talk] Config in VCS Ethan Glasser-Camp
2009-03-28 10:03 ` Nicolas Pouillard
2009-03-31 4:57 ` Ethan Glasser-Camp
2009-03-31 11:39 ` Nicolas Pouillard
2009-03-31 13:36 ` Ben Walton
2009-04-01 8:41 ` David Guibert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox