On Sun, Feb 19, 2012 at 4:34 PM, Brian Smith <br...@linuxfood.net> wrote:
> 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. > I have not looked at Brian's code. Nevertheless, I want to point out that Fossil repositories are very resistant to corruption. See http://www.fossil-scm.org/fossil/doc/trunk/www/selfcheck.wiki for a description of the steps taken to protect the integrity of individual artifacts. And if you do manage to add an artifact to the repository that is malformed, it will be silently ignored. I suppose it is possible to corrupt a Fossil repository, but I think you'd really have to work at it. > 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 > -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
