On Mar 1, 2017, at 3:21 PM, Tony Papadimitriou <[email protected]> wrote: > > if I keep my own repos in SHA3 (which I'm for BTW), but I also have to > interact with 3rd party sites (like chiselapp) some of which may choose to > remain with SHA1 compatible, I would have to keep two different fossils to > cope with each case.
That should only be the case if you’re committing to a repo that must remain SHA1 based. If you’re only checking files out of other people’s repositories, you can use any Fossil 2.x to do that, as I understand it, even if they’re still on Fossil 1.x. So yes, for any project you’re actively committing to which is refusing to upgrade, you’ll have to either learn an exception or lean on them to upgrade. But again, this is not like the Python situation, since in this case, there is a simple upgrade path: upgrade the server to Fossil 2.1+ once all clients are on Fossil 2.0 or newer. The Python divide happened because there is no easy migration *either direction*. > I am not a fossil developer and do not plan to become one. That’s fine, but it is also the case that we, the beneficiaries of the Fossil project, are not obligated to receive *anything*. If you’re framing your requests in terms of what *you* need instead of what those who do the work need, you’re going to run into goal and priority mismatches. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
