On Mon, Mar 7, 2011 at 7:49 AM, Stephen De Gabrielle < stephen.degabrie...@acm.org> wrote:
> Is it worth making clone/rebuild/new 'version stamp' the database, so > fossil can check it is attempting to action the right one? > Fossil does this. If you attempt to use a repository that has the wrong schema, it should tell you. If it doesn't (as it didn't with Mr. Dalton) then that is a bug of some kind. > > Cheers, > > Stephen > > On Mon, Mar 7, 2011 at 12:42 PM, Richard Hipp <d...@sqlite.org> wrote: > >> On Mon, Mar 7, 2011 at 7:30 AM, Steve Dalton <st...@refactor.com.au>wrote: >> >>> Ok - I realised what it was - I went on the server and did a fossil >>> rebuild -R /path/to/fossil and it rebuilt and I could then sync. >>> >>> I didn't realise you had to do this on all the serverside repos to on >>> upgrade. Is this right? Naively thought that the client would perform >>> the upgrade. >>> >> >> You have to do "fossil rebuild" on the machine where you upgrade Fossil. >> The client and server do not necessarily need to be at the same version >> (though there have been a few historical bugs where different versions on >> client and server caused problems - ignore that inconvenient fact for the >> moment). But the schema of the repository on each client and server need to >> match the expectations of the fossil executable that lives there. >> >> So when I'm working on Fossil and I make a change to the schema (which, >> btw, I try to avoid because I recognize that running "fossil rebuild" is >> inconvenient, but sometimes it is necessary in the name of progress) then >> I'll install the new fossil on my local machine and run "fossil all rebuild" >> locally. Then I push to the http://www.fossil-scm.org/ site, which is >> still running with the previous version of Fossil. After a while, once I'm >> convinced that everything is working, I'll recompile fossil on the server >> and run "fossil all rebuild" there. Two independent steps that happen at >> different points in time. >> >> >> >> >> >>> >>> Steve >>> >>> On Mon, Mar 7, 2011 at 10:27 PM, Steve Dalton <st...@refactor.com.au> >>> wrote: >>> > Yep - one of the first things I did. I've tried going back to an old >>> > repo and starting again - but seems to happen again on the first >>> > commit. >>> > >>> > I took a look at the database with sqlite3 and my mlink table is >>> > >>> > sqlite> .schema mlink >>> > CREATE TABLE mlink( >>> > mid INTEGER REFERENCES blob, >>> > pid INTEGER REFERENCES blob, >>> > fid INTEGER REFERENCES blob, >>> > fnid INTEGER REFERENCES filename, >>> > pfnid INTEGER REFERENCES filename, >>> > mperm INTEGER >>> > ); >>> > CREATE INDEX mlink_i1 ON mlink(mid); >>> > CREATE INDEX mlink_i2 ON mlink(fnid); >>> > CREATE INDEX mlink_i3 ON mlink(fid); >>> > CREATE INDEX mlink_i4 ON mlink(pid); >>> > >>> > Looks like the mperm column is there ok and from looking at some older >>> > repos it looks like it's a recent addition. >>> > >>> > Steve >>> > >>> > On Mon, Mar 7, 2011 at 9:45 PM, Stephen De Gabrielle >>> > <stephen.degabrie...@acm.org> wrote: >>> >> did you try recreate the datebase with >>> >> fossil rebuild >>> >> >>> >> Cheers, >>> >> >>> >> Stephen >>> >> >>> >> >>> >> On Mon, Mar 7, 2011 at 10:24 AM, Steve Dalton <st...@refactor.com.au> >>> wrote: >>> >>> I just tried to push to my repository and I got >>> >>> >>> >>> Bytes Cards Artifacts Deltas >>> >>> Sent: 3546 75 0 0 >>> >>> Received: 4067 88 0 0 >>> >>> Sent: 6259 75 0 1 >>> >>> Error: Database error: table mlink has no column named mperm >>> >>> INSERT INTO >>> >>> mlink(mid,pid,fid,fnid,pfnid,mperm)VALUES(:m,:p,:f,:n,:pfn,:mp) >>> >>> Received: 147 1 0 0 >>> >>> Total network traffic: 5010 bytes sent, 1444 bytes received >>> >>> >>> >>> Any ideas? >>> >>> >>> >>> Upgraded to the latest and it still happens. >>> >>> >>> >>> Steve >>> >>> >>> >>> >>> >>> -- >>> >>> Refactor >>> >>> Engage. Succeed. Repeat. >>> >>> PO Box 802, Labrador, Q 4215, Australia >>> >>> tel: <%2B61%20%280%297%205668%203424>+61 (0)7 5668 3424 web: >>> refactor.com.au >>> >>> _______________________________________________ >>> >>> 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 >>> >> >>> >> >>> > >>> > >>> > >>> > -- >>> > Refactor >>> > Engage. Succeed. Repeat. >>> > PO Box 802, Labrador, Q 4215, Australia >>> > tel: <%2B61%20%280%297%205668%203424>+61 (0)7 5668 3424 web: >>> refactor.com.au >>> > >>> >>> >>> >>> -- >>> Refactor >>> Engage. Succeed. Repeat. >>> PO Box 802, Labrador, Q 4215, Australia >>> tel: <%2B61%20%280%297%205668%203424>+61 (0)7 5668 3424 web: >>> refactor.com.au >>> _______________________________________________ >>> 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 >> >> > > > -- > > -- > > Stephen De Gabrielle > stephen.degabrie...@acm.org > Telephone +44 (0)20 85670911 > Mobile +44 (0)79 85189045 > http://www.degabrielle.name/stephen > > > _______________________________________________ > 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
