Does the server fossil know the version number of the client fossil on a clone? Or could it ask? If so, it could do what Andy suggests.
../Dave On 16 March 2015 at 14:24, Richard Hipp <d...@sqlite.org> wrote: > On 3/16/15, Andy Bradford <amb-fos...@bradfords.org> wrote: > > Thus said Stephan Beal on Mon, 16 Mar 2015 18:41:34 +0100: > > > >> wiki-/ticket-only repos might not have a manifest at all. > > > > Then these types of repositories would have to be unclonable by older > > versions of Fossil. The server would have to refuse the clone request > > (similar to how it refuses to accept content from clients with an out of > > date schema). The clone protocol could be modified to include an > > identifier that allows the server to know if such a repository is > > incompatible with the client making the request before allowing the > > clone to proceed. > > > > Not sure if this is even possible, but in theory it seems to work. :-) > > > > Keep in mind that if everyone is using Fossil 1.30 or later, we never > need to have any check-ins in the repository and the first check-in > (if one exists) need not be artifact 1. The code already takes care > of all of that. > > The problem comes up when people try to use Fossil 1.27. And we > cannot go reach into peoples machines and "fix" 1.27. We have to work > around whatever it is that 1.27 does. > -- > 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 >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
