On 2/21/19, Domingo Alvarez Duarte wrote:
> Hello !
>
> I follow the fossil and sqlite3 repository frequently and times to times
> this thing happen again:
>
> Suddenly the my repositories stop following trunk with no clear reason,
> like now the sqlite3 repository stopped following trunk for some days
> and I've tried several times merge the trunk in hope it'll be up to date
> and continue following trunk but no way to achieve it.
I don't know exactly what is happening in your case, but I can guess.
The check-in at https://www.sqlite.org/src/timeline?c=b5f90bfe6295ab3a
was originally on trunk. I checked it in late Tuesday night. Then
after reviewing the change on Wednesday morning, I decided that a
completely different approach was better. So I moved the b5f90bfe6
check-in off into a branch, and added a new trunk check-in off it its
parent with the revised fixed.
If you did a "fossil update" while b5f90bfe6 was still on trunk, you
would have your local checkout at that check-in. Then, after that
check-in was diverted onto a branch, if you were to do "fossil update"
again, nothing would happen, because there were no additional changes
to that branch. (Indeed, that branch was "closed" meaning it will not
accept new check-ins.)
The way to stay up with the latest trunk check-in, regardless of
diversions like this, is to use the command "fossil update trunk"
where you specify the name of the branch that you want to update to.
Additional Background Information:
Fossil allows check-ins to be diverted onto a new branch by setting
special tags on that check-in. You can see the changes on the
https://www.sqlite.org/src/ci_tags/b5f90bfe6295ab3a page. The
original check-in was at 2019-02-20 03:38. The check-in was moved to
the "tkt-df46dfb631" branch on 2019-02-20 12:40, and the branch was
marked as "closed" on 2019-02-20 12:53. (All times are UTC.)
You can see those change on the timeline if you change the "type"
setting on the timeline page from "Checkins" to "Any Type". Here is
the link: https://www.sqlite.org/src/timeline?n=25&y=all&c=b5f90bfe6295ab3a
Fossil allows other properties to be changed using tags, in addition
to the branch that the check-in belongs to. For example, a tag can
add a replacement check-in comment, which is useful for fixing typos
in check-in comments. The original check-in comment is retained as
part of the check-in artifact, but the tag causes the corrected
comment to be displayed in most cases. Here is an example of where I
misspelled "PRAGMA" on the original check-in comment, then corrected
it with a tag:
https://www.sqlite.org/src/timeline?c=718ead555b09892f
https://www.sqlite.org/src/info/718ead555b09892f
https://www.sqlite.org/src/ci_tags/718ead555b09892f
The key observation here is that Fossil does allow corrections to be
entered to check-ins, but the original content is preserved as part of
the audit trail. The default displays show the corrected information,
but the fact that a correction was applied is easily discerned, and
the original uncorrected content is easily accessible.
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
