Discussion:
Fossil update
(too old to reply)
Zoltán Kócsi
2018-11-07 09:48:11 UTC
Permalink
I encountered a problem with Fossil:

'fossil update' (autosync/push/pull enabled) updates the local tree but
not to the latest version.

I can see on the server's web interface that it has a several new
commits, all the files and diffs and everything are there, but on a
client machine (which is behind the server by several commits) the
update command simply updates to a version before the latest.

What's more, a fossil commit from that client machine restores files to
their older versions on the server, effectively undoing the commits
that it did not receive during the update.

On the same client if I fetch the repo file with 'fossil clone' and
check out the trunk from that it gives me the latest version, so the
server's SQLite file is indeed OK.

The Fossil I have both on the server and the various client machines is
rather old, version 1.29. So I thought that before sending a bug
report, it might be advantageous to update to the latest version.

It is probably silly question, but I ask it anyway, just to be sure:

Is the latest Fossil binary compatible with the 1.29 version on the
repo file level? That is, will it be able to read the old SQLite file
and modify/update its schema to the latest version without losing
anything?

We use Fossil for both open source and commercial projects and it would
be a major disaster if we lost 5 years worth of history an all of
them even if their current state could be restored from the actual
source trees.

There was a Fossil major version number change, which might mean
backward binary compatibility issues, hence the question.

Thanks,

Zoltan
Richard Hipp
2018-11-07 10:52:32 UTC
Permalink
Post by Zoltán Kócsi
Is the latest Fossil binary compatible with the 1.29 version on the
repo file level? That is, will it be able to read the old SQLite file
and modify/update its schema to the latest version without losing
anything?
Yes.

In fact, I don't recall any major schema changes going from 1.x to
2.x. The big change there, and the reason for the major version
number bump, was adding support for SHA3 hashes. 1.x supported only
SHA1 hashes. 2.x supports both SHA1 and SHA3. Thus 2.x will read and
understand 1.x repos, but 1.x cannot decode 2.x repos.

If I had to guess (with so little information) about why you are not
seeming to sync, I would suspect that somebody in your organization is
using a 2.x version of Fossil and has done one or more commits that
use a SHA3 hash. The older 1.x versions cannot understand that and
are pretending those checkins do not exist.
--
D. Richard Hipp
***@sqlite.org
Zoltán Kócsi
2018-11-07 13:18:47 UTC
Permalink
Richard,
Post by Zoltán Kócsi
Is the latest Fossil binary compatible with the 1.29 version on the
repo file level?
Yes.
Thanks! It worked fine.

However, a quick question:

For some projects we used colour-coding of the Timeline entries, for
example releases were coloured differently from developers-only commits
and so on. That all seems to have gone.

Also, the Timeline now seems to show only one branch at a time while the
old version has shown all changes and different branches were
represented by different colours and a graphically displayed line. That
made a side-by-side tracking of different branches a breeze without
needing to compare dates while switching between branches back and
forth.

Are those features really gone or in the new Fossil you need to
explicitly turn them on or it's just that my ancient browser (I update
browsers about as frequently as I update Fossil) can't cope with some
new HTML5 whizz-bang that Fossil now uses?

Thanks,

Best Regards,

Zoltan
Richard Hipp
2018-11-07 13:47:50 UTC
Permalink
Post by Zoltán Kócsi
For some projects we used colour-coding of the Timeline entries, for
example releases were coloured differently from developers-only commits
and so on. That all seems to have gone.
Also, the Timeline now seems to show only one branch at a time while the
old version has shown all changes and different branches were
represented by different colours and a graphically displayed line.
Those features should be unchanged. If you visit the canonical Fossil
self-hosting repo (https://fossil-scm.org/fossil/timeline) or the
SQLite Fossil repository (https://sqlite.org/src/timeline) you can see
that both of those show all branches using color codes. I do not know
what might be causing your problem. Can you provide an example?
--
D. Richard Hipp
***@sqlite.org
Warren Young
2018-11-07 22:02:33 UTC
Permalink
Post by Zoltán Kócsi
For some projects we used colour-coding of the Timeline entries, for
example releases were coloured differently from developers-only commits
and so on. That all seems to have gone.
If you upgraded your central repository server from 1.29 to 2.7 to fix the problem suggested by drh — someone’s been checking in SHA3-hashed artifacts — then you also have to update your skin.

If you were using the stock skin before, just go into Admin > Skins and select the Default skin again. You might have to switch to some other skin and back to get it to overwrite your outdated skin files.

If you made changes to your local skin, you’ll have to merge the changes made to the default version of the skin you started with into your local version.

In versions 2.5 and 2.7, there were a lot of changes to the default skin, some of which were done to track changes made to the HTML emitted by “fossil server” in support of newer features. Outdated skins won’t style the new HTML properly.
Loading...