Re: [fossil-users] push fails with complaint about manifest syntax error
Stephan Beal wrote: FYI: i committed one on top of that. The advantage is that it's centralized, the disadvantage is that it hashes every manifest before parsing (to get the UUID, since parsing modifies it). Might be considered too expensive, considering how rare broken manifests are. Follow-up. The investigation led to the following patch: http://fossil-scm.org/index.html/vinfo/bf3db3d16e15ee98f5c72ebdc4ff2f2ed1609ff5?sbs=0 which, if I understand correctly, only makes corrections to the error reporting, and does not change any of the core program logic. After that change, Fossil now only reports errors out of the Tcl core that I am using to implement one of my Transfer hooks. My current suspicion is that something about the PKI stuff on my server box has changed, which causes Tcl to have trouble connecting to a remote HTTPS server from my TH1 hooks. I.e. Fossil itself is no longer implicated as a contributing cause. I'll keep pulling on that thread in private, since it now seems it is specific to my particular deployment. Many thanks to Richard and Stephen for looking into it and making the improvement to the error reporting. Eric -- Eric A. Rubin-Smith Aterlo Networks, Inc. http://aterlo.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Anyway to diagnose a malformed disk image ?
On Thu, Oct 23, 2014 at 10:20 AM, B Harder brad.har...@gmail.com wrote: kamloops$ fossil open ../fossils/netbsd_src.fsl SQLITE_CORRUPT: database corruption at line 53640 of [e4ab094f8a] SQLITE_CORRUPT: database corruption at line 53679 of [e4ab094f8a] SQLITE_CORRUPT: statement aborts at 3: [SELECT 1 FROM event WHERE type='ci'] fossil: SQL error: database disk image is malformed The first step is to run PRAGMA quick_check on the database file. -- 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
Re: [fossil-users] Anyway to diagnose a malformed disk image ?
Done: *** in database main *** Page 36044: btreeInitPage() returns error code 11 Page 36045: btreeInitPage() returns error code 11 Page 36046: btreeInitPage() returns error code 11 Page 36047: btreeInitPage() returns error code 11 Page 36048: btreeInitPage() returns error code 11 Page 36049: btreeInitPage() returns error code 11 Page 36050: btreeInitPage() returns error code 11 Page 36051: btreeInitPage() returns error code 11 Page 36052: btreeInitPage() returns error code 11 Page 36053: btreeInitPage() returns error code 11 Page 36054: btreeInitPage() returns error code 11 Page 36055: btreeInitPage() returns error code 11 Page 36056: btreeInitPage() returns error code 11 Page 36057: btreeInitPage() returns error code 11 Page 36058: btreeInitPage() returns error code 11 Page 36059: btreeInitPage() returns error code 11 Page 36060: btreeInitPage() returns error code 11 Page 36061: btreeInitPage() returns error code 11 Page 36062: btreeInitPage() returns error code 11 Page 36063: btreeInitPage() returns error code 11 Page 36064: btreeInitPage() returns error code 11 Page 36065: btreeInitPage() returns error code 11 Page 36066: btreeInitPage() returns error code 11 Page 36067: btreeInitPage() returns error code 11 Page 36068: btreeInitPage() returns error code 11 Page 36069: btreeInitPage() returns error code 11 Page 36070: btreeInitPage() returns error code 11 Page 36071: btreeInitPage() returns error code 11 Page 36072: btreeInitPage() returns error code 11 [...] On 10/23/14, Richard Hipp d...@sqlite.org wrote: On Thu, Oct 23, 2014 at 10:20 AM, B Harder brad.har...@gmail.com wrote: kamloops$ fossil open ../fossils/netbsd_src.fsl SQLITE_CORRUPT: database corruption at line 53640 of [e4ab094f8a] SQLITE_CORRUPT: database corruption at line 53679 of [e4ab094f8a] SQLITE_CORRUPT: statement aborts at 3: [SELECT 1 FROM event WHERE type='ci'] fossil: SQL error: database disk image is malformed The first step is to run PRAGMA quick_check on the database file. -- 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
Re: [fossil-users] push fails with complaint about manifest syntax error
Stephan Beal wrote: We'd be interested in hearing back if you discover how an error on your end (if indeed it is) is confusing fossil into trying to read non-manifest files as manifests. Actually, your question sort of confuses me. From my (very tenuous) understanding of the code, it tries to read *every* incoming file during a sync as a manifest. It only takes further action if the file is successfully parsed as a manifest. This sort of thing leads to other kinds of confusion. For example, I took a snapshot of a 3rdparty repository. That 3rdparty repository itself includes a snapshot of the SQLite source tree, which had a manifest file in it. When I committed my snapshot, I suddenly saw an SQLite commit, complete with 'drh' as the committer, show up in own my project timeline! It corresponded to the data that was found in the manifest file. This supports my read of the code, I think. So the parse error is generated regardless -- the only question is whether it gets reported back to the pushing remote 'client'. That I guess is stimulated by my failing TH1 script. So Richard's change caused the true underlying cause of the error to propagate back to the client, not a 'harmless' parse error on a file that is not a manifest. But that is just my vague understanding: obviously Richard can comment more intelligently on that than I can. -- Eric A. Rubin-Smith Aterlo Networks, Inc. http://aterlo.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] push fails with complaint about manifest syntax error
On Thu, Oct 23, 2014 at 5:06 PM, Eric Rubin-Smith eas@gmail.com wrote: Stephan Beal wrote: We'd be interested in hearing back if you discover how an error on your end (if indeed it is) is confusing fossil into trying to read non-manifest files as manifests. Actually, your question sort of confuses me. From my (very tenuous) understanding of the code, it tries to read *every* incoming file during a sync as a manifest. It only takes further action if the file is successfully parsed as a manifest. That might be (i'm not yet familiar with how sync works), in which case ignore what i said. i'm curious as to why that was triggering a fatal error (manifest parse) in your case, though. manifest file in it. When I committed my snapshot, I suddenly saw an SQLite commit, complete with 'drh' as the committer, show up in own my project timeline! It corresponded to the data that was found in the manifest file. This supports my read of the code, I think. i remember that coming up a couple weeks back. Similarly, the name drh shows up in the libfossil repo because i accidentally imported a manifest or two from the fossil repo while testing libfossil's manifest parsing/saving. So the parse error is generated regardless -- the only question is whether it gets reported back to the pushing remote 'client'. That I guess is stimulated by my failing TH1 script. So Richard's change caused the true underlying cause of the error to propagate back to the client, not a 'harmless' parse error on a file that is not a manifest. But that is just my vague understanding: obviously Richard can comment more intelligently on that than I can. Your explanation makes sense to me. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] branch ID as well as branch name
In a discussion between a Git user and a user of both Mercurial and Git, there was a debate of the relative merits of named branches vs bookmark branches. Mercurial (and Fossil) supports named branches (Mercurial recently added support for bookmark branches). Git supports bookmark branches. With named branches, metadata is maintained to easily allow the branch membership of any commit to be determined. With bookmark branches, only the branch head is tracked, so determining branch membership is hard. The Git user's arguments against named branches are (1) name collisions resulting from different people using the same names.* And (2) branch names be immutable. Ignoring #2, I can see where #1 could be become a problem when the number of contributors gets large enough. I am thinking maybe use an UUID to identify and keep the branch name in a separate control artifact. Fossil already supports moving commits between branches via control artifacts, so moving naming out to a branchname tag should not be a huge tear up. ( * Most of the suggested Git workflows I've seen say to merge (usually after rebasing) the branch back to (an updated) master (aka trunk), then send either a patch or a pull request.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] branch ID as well as branch name
On Thu, Oct 23, 2014 at 12:56 PM, Ron W ronw.m...@gmail.com wrote: In a discussion between a Git user and a user of both Mercurial and Git, there was a debate of the relative merits of named branches vs bookmark branches. Mercurial (and Fossil) supports named branches (Mercurial recently added support for bookmark branches). Git supports bookmark branches. With named branches, metadata is maintained to easily allow the branch membership of any commit to be determined. With bookmark branches, only the branch head is tracked, so determining branch membership is hard. The Git user's arguments against named branches are (1) name collisions resulting from different people using the same names.* And (2) branch names be immutable. Fossil allows two or more branches with the same name, so name collisions are not a technical problem. You might argue that having multiple branches with the same name is confusing to users. And there is a point to that. But, you can rename one or more of the branches to resolve the collision if desired. And, I will argue, have an occasional branch name collision is less confusing that the gyrations you have to go through to keep track of branch names in Git. That said, Git and Fossil are designed for different development strategies. Git is geared toward having thousands of contributors, many of whom have never met each other, all contributed to the same project. Fossil, on the other hand, is designed for a close-knit development community that stays in constant communication. In the Fossil environment, branch names collisions just don't come up that often. To look at the difference another way, Git is designed for GPL projects where there are many writers. Git encourages drive-by patching. Fossil, o the other hand, is designed more for MIT/BSD/Public-Domain projects where there are many fewer writers but more readers. Drive-by patches are discouraged. -- 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
Re: [fossil-users] SVN -- Fossil Chiselapp hosting
On Thu, Oct 23, 2014 at 7:26 PM, Ron W ronw.m...@gmail.com wrote: Also, another reason in favor of a direct importer: Git only tracks the heads of branches. No history is being lost, just that determining what branch a given commit belongs to is difficult. Therefor, git-fast-import doesn't provide branch name information (though the way some SVN-to-Git conversions are done, the branch name can be inferred from the path.) I am only slightly familiar with git, and not at all with svn-to-git, so I am not sure if this answers your request, but I am currently working on an option to parse the de-fcto svn trunk/tags/branches repo layout into actual fossil branches and tags. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SVN -- Fossil Chiselapp hosting
On 23 October 2014 12:26, Ron W ronw.m...@gmail.com wrote: Having read post from many places, one of the big complaints SVN users have about Git is directory tracking. Fossil lack this, too. I had a weird related issue the other day (I would argue it's a bug, but YMMV). I was moving an existing directory hierarchy into a new fossil. I had a sub-directory TeX that had lots of TeX-related files in it. I said fossil add and it added all the files from the TeX directory. Seeing that I realized that I had TeX directories under many projects that had often essentially been a copy of each other, so I decided to move TeX elsewhere and replaced it by a symlink to the other location. I then said fossil addremove . and expected it to remove all those files (I hadn't yet committed) and add the symlink (I have allow-symlink set globally). Instead it said it had nothing to do. I worked-around, but it was surprising. I expected it to discover the symlink in the path to the files and consider everything below to no longer be there. I also found another (I think bug) with addremove. I did an addremove . but it added things in .. directories. : ~/fs/Admin/bin ; touch bar : ~/fs/Admin/bin ; fs extra bar ../homedir/Emacs/Startup.el-original : ~/fs/Admin/bin ; fossil addremove . ADDED bin/bar ADDED homedir/Emacs/Startup.el-original added 2 files, deleted 0 files One other surprise, while I'm at it: : ~ ; ls Fossils/Admin.fossil Fossils/Admin.fossil : ~ ; cd fs : ~/fs ; mkdir blah : ~/fs ; cd blah : ~/fs/blah ; fs open ../../Fossils/Admin.fossil bin/update-fossils ... project-name: Admin repository: /Users/dmason/fs/blah/../../Fossils/Admin.fossil local-root: /Users/dmason/fs/blah/ config-db:/Users/dmason/.fossil project-code: 70274e3df807d403e5d292f7c84e26eebf6f7119 checkout: 2f095fe0993a5aa584398b392d03d0e7ce304c6c 2014-10-20 19:36:40 UTC parent: d2b6e3978227013ca3ec6bff0aece4fad6522093 2014-10-08 11:30:58 UTC leaf: open tags: trunk comment: update-fossils (user: dmason) checkins: 4 : ~/fs/blah ; fs open ../../Fossils/Admin.fossil already within an open tree rooted at /Users/dmason/fs/blah/ If I'm doing the open in the root of the tree, and it's the same fossil, I don't see why it needs to say anything, or at most say, Already open in this directory or something like that. The error scares me and (if I wasn't thinking) I might try it again with --nested, to which you get: : ~/fs/blah ; fs open --nested ../../Fossils/Admin.fossil SQLITE_ERROR: table vvar already exists fs: table vvar already exists If you have recently updated your fossil executable, you might need to run fossil all rebuild to bring the repository schemas up to date. which could be very scary! Already open would be much more calming. ../Dave (loving fossil, but surprised more than I like) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] diff --tk features and to-dos. Was: Diff against working copy
Please save me the trouble of search - Do I have a Contributors Agreement for you in the firesafe? May I suggest this great SQLite3 tool to help you (1) keep track of your documents, and (2) quickly search for membership without even going to the safe? (Sorry, I couldn’t resist! )___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] diff --tk features and to-dos. Was: Diff against working copy
Fossil currently does not have FTS on content, be it code, wiki pages, or tickets. Unfortunately :( On Thu, Oct 23, 2014 at 11:06 AM, to...@acm.org wrote: Please save me the trouble of search - Do I have a Contributors Agreement for you in the firesafe? May I suggest this great SQLite3 tool to help you (1) keep track of your documents, and (2) quickly search for membership without even going to the safe? (Sorry, I couldn’t resist! [image: Smile]) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil timeline behaviour change from 1.24 to 1.29 to 1.30
On Sun, 19 Oct, Stefan Bellon wrote:
If not introducing a new flag but re-using the verbose flag, then the
patch would be almost trivial and look like this:
--- src/timeline.c
+++ src/timeline.c
@@ -1602,11 +1602,15 @@
}
if( fossil_strcmp(zCurrentUuid,zId)==0 ){
sqlite3_snprintf(sizeof(zPrefix)-n, zPrefix[n], *CURRENT* );
n += strlen(zPrefix);
}
-zFree = mprintf([%S] %s%s, zId, zPrefix, zCom);
+if (verboseFlag){
+ zFree = mprintf([%s] %s%s, zId, zPrefix, zCom);
+}else{
+ zFree = mprintf([%S] %s%s, zId, zPrefix, zCom);
+}
/* record another X lines */
nLine += comment_print(zFree, zCom, 9, width, g.comFmtFlags);
fossil_free(zFree);
if(verboseFlag){
*bump*
Does anybody of the fossil maintainers have any comment regarding this?
I'd very much like to see a %s (i.e. full UUID output) in the timeline
in addition to the shortened %S format. I'd be fine with using
-v/-verbose for that, but I wouldn't mind another option.
Comments?
Greetings,
Stefan
--
Stefan Bellon
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil timeline behaviour change from 1.24 to 1.29 to 1.30
2014-10-23 21:55 GMT+02:00 Stefan Bellon sbel...@sbellon.de:
On Sun, 19 Oct, Stefan Bellon wrote:
-zFree = mprintf([%S] %s%s, zId, zPrefix, zCom);
+if (verboseFlag){
+ zFree = mprintf([%s] %s%s, zId, zPrefix, zCom);
+}else{
+ zFree = mprintf([%S] %s%s, zId, zPrefix, zCom);
+}
*bump*
Does anybody of the fossil maintainers have any comment regarding this?
I'd very much like to see a %s (i.e. full UUID output) in the timeline
in addition to the shortened %S format. I'd be fine with using
-v/-verbose for that, but I wouldn't mind another option.
Comments?
Because of consistance I would prefer every Displayed UUID to have
a short format (%S), while every hyperlink containing an UUID
would use the full length. That means, I would prefer to keep
this part as it is now by default. Sorry ;-(
Re-using the -v/--verbose option wouldn't be a good idea either,
as this options is used for displaying the modified files in addition.
That leaves implementing an additional option as the only
viable one, IMHO. I don't see an important use for that, but
don't let that stop you from implementing this!
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil timeline behaviour change from 1.24 to 1.29 to 1.30
On Thu, 23 Oct, Andy Bradford wrote: I could be wrong, but is it possible that what he's asking for is a consistency in a fixed output width when %S is being used in the timeline? Or an option to have fixed width UUIDs in the timeline? Consider the timeline output here where you have a nicely fixed width column of UUIDs and then suddenly to break the flow there is [84871722547960b] in the middle. I can imaging it getting pretty messy if there are a lot of varying widths of UUIDs in the output. Yes, almost. ;-) I'm not interested in interactive usage of fossil. We are using fossil in a completely automated scenario to track and retrieve generated files over time. So, my concern is compatibility and consistency of command line switches and their output. When we have to store the commit UUIDs of files (timeline -showfiles/-v) it just feels weird to store different length UUIDs. But now, calculating the longest UUID in a specific timeline output and then adjusting the length of the shorter UUIDs to be the same length would be even worse in my scenario as then the same commit may show up with different length UUIDs depending on the timeline itself. So, please don't do that. :-) What I propose is a consistent and reliable output which doesn't change when using the same switches specified. I can live with the current state, however it does not feel right for automated usage. -- Stefan Bellon ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil timeline behaviour change from 1.24 to 1.29 to 1.30
Thus said Stefan Bellon on Thu, 23 Oct 2014 23:49:47 +0200: What I propose is a consistent and reliable output which doesn't change when using the same switches specified. I can live with the current state, however it does not feel right for automated usage. And that would be the full UUID as you suggested. :-) Andy -- TAI64 timestamp: 400054498aa5 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
