On Sat, Feb 18, 2012 at 6:42 AM, Leo Razoumov <slonik...@gmail.com> wrote: > On Thu, Feb 16, 2012 at 14:15, Brian Smith <br...@linuxfood.net> wrote: >> For what it's worth, I was working on limited branch syncing awhile back. >> >> I never got around to merging it back into the master fossil repo, but, I >> think at least your use case is functional.. >> >> http://code.linuxfood.net/pub/repo/fossil-limsync >> >> I really ought to finish that up and push it into the master fossil repo. >> > > Brian, > I cloned your repository and merge limsync into trunk > [6c835ea8c7c615]. The merge went very smoothly with no conflicts. I > would like to use limsync for my everyday work but am afraid that it > may cause data loss or repository corruption. What do you think? >
It certainly shouldn't cause corruption. But, I wouldn't yet trust it either. The nice thing is that if you encounter problems, you can just do a regular pull and fossil will do the right thing. Or at least, that's if it doesn't cause corruption. I've never seen it cause corruption. This is because the way limsync is implemented is via lying. Essentially, the client announces what it wants, and then the server hangs onto that and lies every time the client asks for an artifact that isn't on the right branch. This is because only the server really knows. This is one of the really nice things about fossil's sync protocol is that it's just a set exchange and then there's a resolution phase afterwards. And, if bits are missing, fossil is very tolerant of that. To anyone who is interested in the details of the limsync changes, you should search the mailing list. I detailed a number of caveats and "open questions" while I was initially working on it. Because of the way fossil works, there's a number of "strange" edge cases that other SCMs don't have to deal with. -B _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
