On 2/21/19, Domingo Alvarez Duarte <mingo...@gmail.com> 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