[SLUG] 1337 file systems
* The problem is that you'll have some files that you'll want to work on and access both on your desktop and notebook * computer, how do you ensure that they both have current versions and how do you deal with the situation where the same * files have been modified on both computers when synchronisation is attempted? I don't know about synchronisation, but perhaps this may contribute to your eventual solution? In looking at non-deselectable packages under Mdk 8.1, I found "diffutils" pkg which contains: diff, cmp, diff3, sdiff "... diff3 shows the differences between 3 files, and can be used where two people have made independant changes to a common original, and can produce a merged file with both persons changes and warnings about conflicts." (see also: man diff3) hth peter bj -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] 1337 file systems
On Sun, 2002-08-04 at 12:29, James Gregory wrote: > So I've finally been introduced to the fun of portable computing and > also to the bliss that is file synchronisation. I was thinking of using cvs to do this for me. After all it will merge and track teh changes as well. Some things probably wont work particularly well. overkill for a lot of situations. KenF -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: Mail syncing (Re: [SLUG] 1337 file systems)
> Are there any relatively high level libraries that have APIs wrapping > operations on several types of mailboxes. I think the UW c-client library does, but it's supposedly fairly arse. > Because, if implementing a solution for mail syncing, a first step would > be having a set of "list all the items that are new since date X", "does > Message-ID Y exist in this mailbox", "delete Z from this mailbox" > functions implemented for Maildir/mobox/IMAP mailboxs so that you could > sync regardless of mailbox type. Check offlineimap, the author thinks the algorithm he uses is pretty sweet, and it's written in python. - Jeff -- It makes perfect sense. If you're a narcissistic arsehole spawned from a curdled gene pool. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: Mail syncing (Re: [SLUG] 1337 file systems)
On Sun, Aug 04, 2002, Jeff Waugh wrote: > Unison is a general file-syncing program, so doesn't handle the application > level issues with mail. Are there any relatively high level libraries that have APIs wrapping operations on several types of mailboxes. Because, if implementing a solution for mail syncing, a first step would be having a set of "list all the items that are new since date X", "does Message-ID Y exist in this mailbox", "delete Z from this mailbox" functions implemented for Maildir/mobox/IMAP mailboxs so that you could sync regardless of mailbox type. Alternatively, I suppose one could extract an existing projects mailbox code. -Mary -- Sure I have assessments, but I can camp and learn to drive and run naked everywhere if I wanna. -- Stephanie Gardiner -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: Mail syncing (Re: [SLUG] 1337 file systems)
> * One IMAP server which is the 'primary' mail repository. Most IMAP >clients don't sync both ways though. isync syncs a single local >Maildir folder with a remote IMAP repository in both directions, but >that's not very useful if you have 70-odd folders like I do, or if >you don't like Maildir. (There was also the mailsync and offlineimap programs - these are package names in Debian too.) - Jeff -- Wars end, love lasts. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: Mail syncing (Re: [SLUG] 1337 file systems)
> for this purpose in the office we are trialing Unison which seems to do > something similar and handle it all through an easy to use GUI. > http://www.cis.upenn.edu/~bcpierce/unison/ Unison is a general file-syncing program, so doesn't handle the application level issues with mail. - Jeff -- "Laughter is a force for democracy." - John Cleese -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: Mail syncing (Re: [SLUG] 1337 file systems)
> There are problems with bi-directional syncing in general. If intermezzo > or coda turn out not to be the answer, rsync-ing your mailboxes might > be... for this purpose in the office we are trialing Unison which seems to do something similar and handle it all through an easy to use GUI. http://www.cis.upenn.edu/~bcpierce/unison/ dave -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Mail syncing (Re: [SLUG] 1337 file systems)
On Sun, Aug 04, 2002, James Gregory wrote: > Keeping a local copy of my mail archives is another problem. This one was one that Jeff and I were discussing a while ago, there don't seem to be many good solutions. It's especially difficult if you want to sync both ways. The ones Jeff and I canvassed were: * One IMAP server which is the 'primary' mail repository. Most IMAP clients don't sync both ways though. isync syncs a single local Maildir folder with a remote IMAP repository in both directions, but that's not very useful if you have 70-odd folders like I do, or if you don't like Maildir. * You could, if you can sync your procmailrc, or your mail client's filtering rules, download mail using fetchmail from a central server - this doesn't cope well with post-procmail filtering (ie if you save mail to a different folder after the auto-filtering). There are problems with bi-directional syncing in general. If intermezzo or coda turn out not to be the answer, rsync-ing your mailboxes might be... -Mary. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
[SLUG] 1337 file systems
So I've finally been introduced to the fun of portable computing and also to the bliss that is file synchronisation. The problem is that you'll have some files that you'll want to work on and access both on your desktop and notebook computer, how do you ensure that they both have current versions and how do you deal with the situation where the same files have been modified on both computers when synchronisation is attempted? What are people doing about this? there's a few application specific solutions that might be worth trying. Using CVS for my code and uni work et al would work well, but I would like to get a slightly more general solution. Keeping a local copy of my mail archives is another problem. And I'd also like updates in my key bindings and stuff to go between machines (I guess that could also be CVSed, but that's starting to sound like too much work). So I heard about Intermezzo and Coda. They're both in my kernel. Does anyone have any experience with them? Do they work as advertised? will they do what I need them to? Which one is better? James. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
