In the message dated: Wed, 21 May 2008 15:27:03 EDT,
The pithy ruminations from Paul Fox on
<Re: [Nmh-workers] sync'ing an mh mailstore between two machines? > were:
=> well, this thread is certainly becoming more interesting than i
=> expected it to be. certainly using git never would have occurred
=> to me.
Hmm...I'll need to look into git some more.
me too. this is clearly not your father's source code control system.
=> there's a very nice file tree syncing tool called "unison" that might
=> be useful as well -- i hadn't thought of it until peter mentioned rsync.
=> unfortunately it's no longer under active development, but in my
=> (limited) experience it works very well:
=> i'll have to think about whether it would be appropriate in this case.
IMHO, the problem with tools like unison & rsync for this task
is that they are oriented toward content differences between
files of the same name, and dealing with missing/added files.
This means that tools like rsync will work very hard to
resolve the internal differences between file
~/Mail/My-Lists/nmh/691 on my laptop and the completely
different message with the same name stored on my desktop.
so it seems like the way to make a file synchronizer's job easy
would be to try and avoid naming conflicts like that. there are
only so many ways that could happen -- and i think all involve
the choice that mh makes when it chooses a name for a file in a
folder. (i suspect i just stated the obvious.) i.e., it's when
one does an inc, rcvstore, or refile, on both the home and laptop
copies of mh, and they both choose the same new filename.
what if there were a hint that one could help the two
installations choose different starting values. at first i was
thinking of trying to leave a gap -- the home mh would work
normally (i.e., "last+1"), but the laptop would always create new
files at "last+1000". after every resync you'd want to do a
folder pack on both sides. or, could it be as trivial as telling
one side to choose odd filenames, the other even?
in either case, i think this would make a tool like unison's
trivial -- it already knows how to deal with files created or
removed on either.
is this too easy?
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 53.2 degrees)
Nmh-workers mailing list