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
On Sun, Mar 15, 2015 at 11:37 AM, Andy Bradford amb-fos...@bradfords.org
wrote:
The requirement, specifically, is that the first artifact that the
server sends during a clone, must be a checkin, or older Fossil clients
will end up in this state.
Could the server side be modified to
On Sat, Mar 14, 2015 at 10:24:05PM -0400, Richard Hipp wrote:
On 3/14/15, James Turner ja...@calminferno.net wrote:
It appears the actual tarballs were also removed. While I understand the
reasoning behind this, this will break automated build systems like
ports in OpenBSD for stable
wiki-/ticket-only repos might not have a manifest at all.
- sent from a mobile device. Please excuse brevity, auto-correction,
typos, and top-posting.
On Mar 16, 2015 5:21 PM, Ron W ronw.m...@gmail.com wrote:
On Sun, Mar 15, 2015 at 11:37 AM, 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
Thus said David Mason on Mon, 16 Mar 2015 21:35:51 -0400:
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.
Not currently. The client version is not currently exchanged during
cloning. The only piece of
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
Thus said bch on Sun, 15 Mar 2015 01:05:42 -0700:
Has the Ryerson Bug be characterised?
Yes.
Basically, versions of Fossil 1.27 and older, assumed that the first rid
in the blob table would always be a checkin. This was true because the
first thing fossil new did was to create a bogus
Has the Ryerson Bug be characterised?
Obviously it was confusing, annoying and unintended, but did it turn out to
be data losing and/or uncorrectable?
Regards
-bch
On Mar 14, 2015 7:24 PM, Richard Hipp d...@sqlite.org wrote:
On 3/14/15, James Turner ja...@calminferno.net wrote:
It appears
On Sat, Mar 14, 2015 at 4:30 PM, Richard Hipp d...@sqlite.org wrote:
Fossil version 1.32 is now available on the download page:
https://www.fossil-scm.org/download.html
The new builds all use version numbers in their names instead of dates.
All previous builds have been removed from the
Am 15.03.2015 um 09:46 schrieb Baruch Burstein:
Can we still have the changelog of the older versions on the download
page, even without the links?
And/or a link to older versions like on
http://www.sqlite.org/releaselog/3_8_8_3.html
___
On 3/14/15, James Turner ja...@calminferno.net wrote:
It appears the actual tarballs were also removed. While I understand the
reasoning behind this, this will break automated build systems like
ports in OpenBSD for stable releases that may reference older versions
of fossil.
Is there a
It appears the actual tarballs were also removed. While I understand the
reasoning behind this, this will break automated build systems like
ports in OpenBSD for stable releases that may reference older versions
of fossil.
Is there a reason why the tarballs had to be removed?
--
James Turner
13 matches
Mail list logo
