'Twas brillig, and Arun Raghavan at 04/09/11 18:07 did gyre and gimble:
What do you think the best route forward here is?
1. Convert on the fly only.
2. Convert on the fly and write to disk.
Vote now!
2.
++ for 2 from me as well.
Cool. That's 3 2's and 4 if you count me!
I won't
On Sun, 2011-09-04 at 17:59 +0200, Maarten Bosmans wrote:
What do you think the best route forward here is?
1. Convert on the fly only.
2. Convert on the fly and write to disk.
Vote now!
2.
I'm not too worried about preserving stored values either way
actually. It's just user
On Mon, 2011-09-05 at 14:35 +0100, Colin Guthrie wrote:
Not good. There's a not-so-uncommon scenario which is the NFS-mounted
$HOME shared between desktops with differing versions (for instance,
where I work we have a mix of RHEL4, RHEL5 RHEL6).
[...]
This scenario is not a problem.
We
On 05/09/11 12:47, Xavier Bestel wrote:
Not good. There's a not-so-uncommon scenario which is the NFS-mounted
$HOME shared between desktops with differing versions (for instance,
where I work we have a mix of RHEL4, RHEL5 RHEL6).
To correctly handle that situation, db formats should of
Hi,
Generally speaking we'll try and not write stuff to disk if the user
does not trigger a change.
Currently in git master, if we encounter a legacy database format, we
convert it on the fly and then *write it to disk*.
We could avoid the writing to disk without any operational issue (if the
Hi,
On 4 Sep 2011, at 11:34, Colin Guthrie wrote:
What do you think the best route forward here is?
1. Convert on the fly only.
2. Convert on the fly and write to disk.
Although not directly related, I used to work on a mail server (Scalix) that
periodically updated its database format
Maarten Bosmans mkbosm...@gmail.com wrote:
2011/9/4 Colin Guthrie gm...@colin.guthr.ie:
Hi,
Generally speaking we'll try and not write stuff to disk if the user
does not trigger a change.
Currently in git master, if we encounter a legacy database format, we
convert it on the fly and then
