[fossil-users] Infinite loop on merge
"f merge branch-name -baseline root:branch-name" is an infinite loop for me since Fossil change 41c2220934, as determined by bisection. Version 4d1f2d302b (latest trunk) is bad too. Execution hangs up inside SQLite. The check-in comment for 41c2220934 is "Improve the merge command's ability to handle various scenarios involving renames." Here is the backtrace: #0 0x08127109 in sqlite3VdbeExec (p=0x85c9410) at ./src/sqlite3.c:81008 #1 0x0811f64c in sqlite3Step (p=0x85c9410) at ./src/sqlite3.c:74987 #2 0x0811f7c6 in sqlite3_step (pStmt=0x85c9410) at ./src/sqlite3.c:75048 #3 0x080694ad in db_step (pStmt=0xbfffef10) at ./src/db.c:345 #4 0x08069cac in db_exists ( zSql=0x8248abc "WITH RECURSIVE ancestor(id) AS ( VALUES(%d) UNION ALL SELECT pid FROM plink, ancestor WHERE cid=ancestor.id AND pid!=%d AND cid!=%d)SELECT 1 FROM ancestor WHERE id=%d LIMIT 1") at ./src/db.c:622 #5 0x080a8551 in merge_cmd () at ./src/merge.c:397 #6 0x0809785b in main (argc=5, argv=0xb364) at ./src/main.c:804 sqlite3VdbeExec() never returns. The repository is private, sorry, but I should be able to help with debugging. I apologize for my several months of absence. I've been very busy working on this and a few other projects. Today I upgraded from Fossil 1.34, and it looks like I'm going to have to switch back. http://fossil-scm.org/index.html/info/41c2220934de8cb8 -- Andy Goth | ___ 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] Infinite loop on merge
The latest trunk is broken (w.r.t. the merge in question), as is apparently everything starting with 41c2220934. Version 1.34 is good, as is the version immediately before 41c2220934. I see no reason to downgrade to anything before 1.34, since that's what I've been using successfully since its release. On Tue, Sep 6, 2016 at 2:11 PM, Richard Hipp wrote: > On 9/6/16, Andy Goth wrote: > > > > Today I upgraded from Fossil 1.34, and it > > looks like I'm going to have to switch back. > > > > Try using trunk before you downgrade to 1.33 or 1.32. > -- > 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 > -- Andy Goth | ___ 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] Infinite loop on merge
That seems to fix it. Thank you very much for the astonishingly fast
turnaround. There may be unintended consequences since we haven't done much
analysis yet, so I checked your change in on the merge-rename-lockup
branch pending further testing.
On Tue, Sep 6, 2016 at 2:20 PM, Richard Hipp wrote:
> On 9/6/16, Andy Goth wrote:
> >
> > The repository is private, sorry, but I should be able to help with
> > debugging.
> >
>
> Just a guess:
>
> Index: src/merge.c
> ==
> --- src/merge.c
> +++ src/merge.c
> @@ -395,11 +395,11 @@
>}
>if( zPivot ){
> vAncestor = db_exists(
>"WITH RECURSIVE ancestor(id) AS ("
>" VALUES(%d)"
> - " UNION ALL"
> + " UNION"
>" SELECT pid FROM plink, ancestor"
>" WHERE cid=ancestor.id AND pid!=%d AND cid!=%d)"
>"SELECT 1 FROM ancestor WHERE id=%d LIMIT 1",
>vid, nid, pid, pid
> ) ? 'p' : 'n';
>
> --
> 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
>
--
Andy Goth |
___
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] change sync URL
Let me add that the -once option for sync is useful to inhibit automatically changing the remote-url. I need this on occasion when I'm manually sync'ing between several (more than two) systems in the temporary absence of a central server. On Wed, Aug 10, 2016 at 3:37 PM, Warren Young wrote: > On Aug 10, 2016, at 12:55 PM, Ross Berteig wrote: > > > > On 8/10/2016 11:43 AM, jungle Boogie wrote: > >> If I have a repo syncing to example.com and I want to change it to > >> sync locally on my network, what's the best method to update the sync > >> url? > > > > Set the url:fossil remote-url http://new-url-here.local/ > > You can also say “fossil sync http://new-url-here.local/“ The command is > shorter and you get a free sync that way. :) > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- Andy Goth | ___ 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] Compilation error with latest trunk
On 9/19/2016 4:12 PM, jungle Boogie wrote: > On 19 September 2016 at 13:16, Tony Papadimitriou wrote: >> Usually do just FOSSIL UPDATE and then run make. > > Best to do fossil up trunk as you may inadvertently follow a branch. Indeed, this happens when your checkout version, or a predecessor, gets retroactively moved to a branch, e.g. because it was determined that it doesn't yet belong on trunk. fossil info will tell you which branch you're on without making any changes to your checkout area. I think it's been discussed before whether or not to do more to proactively alert the user when branch changes happen, though I don't know how that discussion concluded. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] andygoth-circa
I recently created a branch called andygoth-circa which adds a "circa" link to the info web page. This link shows timeline events near the selected check-in even if they're not ancestors or descendents. It's just for showing context of what was happening around the same time. Does anyone have any thoughts on this? I'd like to merge it to trunk but prefer a little discussion first. Sorry I haven't been involved in email much lately. Work has been incredibly busy. I'm using Fossil every day, and it's been very helpful. People on my team tell me it's a massive timesaver compared to what we would have been stuck doing. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Rebase solved
Forget all about that "isolate" merge stuff I proposed a few months ago. I could not get comfortable with the heuristics. The overall system would have been complicated, difficult to understand, and unreliable. After some experimentation I found another approach that works perfectly for our needs without any changes to Fossil. So, what are those needs? Two things. One, we need "f diff branch-name -baseline root:branch-name" to include only the changes that were made to address the requirement, discrepancy, feature, etc. for which branch-name was created. Two, we need to occasionally refresh a branch to include work that was done elsewhere. If not for the first requirement, we'd meet the second by merging trunk into the branch, but we can't. Hence, rebase. My solution is this sequence of commands: f up trunk f merge branch-name # (resolve any conflicts) f commit -branch branch-name -m Rebase This creates a new branch named the same as the old but with an updated baseline. The collection of changes in the new branch's commit is exactly the collection of changes that previously existed on the branch. Thus, our requirements are met. Fossil usually, but not always, displays the old branch as the primary predecessor, even though the manifest shows trunk as the primary predecessor. This "bug" is convenient because it matches our user desire of presenting the new branch as a continuation of the old. Let's compare to git. The rebase commit rolls up all the changes into one, albeit relative to the new baseline, so this is like git. But its manifest does identify the prior like-named branch which shows all the individual changes, as is of course how we want Fossil to work. Comments? Questions? This method does everything my team needs. Perhaps Fossil might consider adopting it, or a streamlined variant, so we'll have an answer to the perennial question about how to do rebase. ___ 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] andygoth-circa
No, I was unaware. That's great! Thanks for the tip, thanks for the welcome, thanks for the encouragement, and thanks for Fossil! On Oct 12, 2016 2:05 PM, "Richard Hipp" wrote: > On 10/12/16, Andy Goth wrote: > > I recently created a branch called andygoth-circa which adds a "circa" > link > > to the info web page. This link shows timeline events near the selected > > check-in even if they're not ancestors or descendents. It's just for > > showing context of what was happening around the same time. > > Did you know you can already get that on trunk by clicking on the Date: > value? > > > Sorry I haven't been involved in email much lately. Work has been > > incredibly busy. I'm using Fossil every day, and it's been very helpful. > > People on my team tell me it's a massive timesaver compared to what we > > would have been stuck doing. > > > > Glad to you have you around. And glad Fossil is working well for you! > > -- > 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 > ___ 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] Rebase solved
The full history is there. Nothing is destroyed. The goal is to re-baseline the branch, which i accomplish by creating a new branch with the same name which is merged from the original. Thus there is both one check-in containing all past changes made on the branch, and also the branch from which it was derived containing the full history. So you have it both ways, although that fact is secondary to my goal. Bundles make sense for a totally different use case than I'm dealing with here. Every engineer has developer capabilities, and they directly check in their work onto branches. Because of other company processes with which I must interoperate, I must keep each "activity" on its own branch and reserve trunk for integration consisting of only merges. (Plus I keep several other integration branches for maintaining sync with ClearCase and Subversion which I am also required to support.) And so, I cannot implement updating a branch's effective baseline by merging in outside changes which are not related to the branch's activity. Hence my rebase method. Here's an untested example. I'm using my phone to write this, sorry. # Create repository f new food.fossil mkdir food cd food f open ../food.fossil # Create main dish echo eggs > breakfast f add breakfast f commit -branch breakfast -m Breakfast echo "scrambled eggs" > breakfast f commit -m "Specify how breakfast cooked" # Create side dish f up trunk echo spam > side f add side f commit -branch side -m "Side dish" echo "fried spam" > side f commit -m "Specify how eggs cooked" # Side is ready for consumption f up trunk f merge side f commit -m "Merge side" # Rebase breakfast to include side f up trunk # (Redundant in this case) f merge breakfast f commit -branch breakfast -m Rebase # Finish making breakfast echo "scrambled green eggs" > breakfast f commit -m "Specify color" # Review all breakfast changes f diff -from root:breakfast -to breakfast # Shows only breakfast, not side # Pull it all together f up trunk f merge breakfast f commit -m "Merge breakfast" On Oct 12, 2016 19:38, "Warren Young" wrote: > On Oct 12, 2016, at 6:12 PM, Andy Bradford > wrote: > > > > Thus said Andy Goth on Wed, 12 Oct 2016 16:25:43 -0500: > > > >> Comments? Questions? This method does everything my team needs. > >> Perhaps Fossil might consider adopting it, or a streamlined variant, > >> so we'll have an answer to the perennial question about how to do > >> rebase. > > > > I honestly have not yet found the need for ``rebase'' so I'm not really > > sure what I get out of using it. Maybe you can put up a demo Fossil > > repository that shows just what your rebase looks like, and then what it > > would look like without rebase? > > That, or just a command sequence whereby one could construct such a > repository locally. > > I *think* I see what you’re trying to accomplish here, Mr. Goth, but I’m > not quite sure it’s the same thing as Git rebase. For one thing, doesn’t > it leave a branch and all of its checkin history behind? I thought its > most famous use was to collapse a branch’s entire change sequence down to a > single patch. > > Incidentally, as one who ran an active open source project, I always hated > receiving big-ball-of-hackage patches that changed several essentially > unrelated things. I really don’t understand the charm in receiving a > single flattened patch. Fossil bundles are a much better idea. I *want* > to see the full checkin history. > ___ > 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
[fossil-users] SQLite abort?
First off, sorry I haven't been active on the mailing list. I just kind of disappeared, I know. Work's been very busy with constant travel, and I only have my phone for personal email. Next, why the flurry of activity the last few days? I finally got a few days off work, and I wanted to make the most of them. I don't know when I'll get time like this again. Down to business. My last check-in on andygoth-changes (9d5de8d7) seems to trigger a very strange failure in SQLite. Sorry, I can't copy-and-paste (phone), so I'll just describe. It dies due to ROLLBACK, but I'm in the middle of a SELECT so I don't know why. If I precede my SELECT with a single step of the same SELECT except minus the ORDER BY, then it works. See the check-in code and comment for more information, including a workaround and a repeatable test case. ___ 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] SQLite abort?
The very last thing SQLite does before the abort is an OP_OpenRead, but p->expired which triggers SQLITE_ABORT_ROLLBACK. Using the sqlite3.c included with the Fossil version at issue, I put a breakpoint at line 78001 with an ignore count of 69. The 70th time that line hits is immediately before the opcode dispatch to OP_OpenRead. I'll continue to look into this, but I don't expect to figure it out on my own. On Nov 6, 2016 02:17, "Andy Goth" wrote: > First off, sorry I haven't been active on the mailing list. I just kind of > disappeared, I know. Work's been very busy with constant travel, and I only > have my phone for personal email. > > Next, why the flurry of activity the last few days? I finally got a few > days off work, and I wanted to make the most of them. I don't know when > I'll get time like this again. > > Down to business. My last check-in on andygoth-changes (9d5de8d7) seems to > trigger a very strange failure in SQLite. Sorry, I can't copy-and-paste > (phone), so I'll just describe. It dies due to ROLLBACK, but I'm in the > middle of a SELECT so I don't know why. If I precede my SELECT with a > single step of the same SELECT except minus the ORDER BY, then it works. > > See the check-in code and comment for more information, including a > workaround and a repeatable test case. > ___ 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] SQLite abort?
The issue seems to be resolved for now. Phone typing is hard, so just have a look at check-in 5258a43d78. I'll quickly summarize: the schema was getting changed right in the middle of running a prepared statement. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Follow-up to reverting missing files
With my enhanced changes command, the way to revert all missing files is: fossil revert $(fossil changes -missing) If your shell doesn't have $(...) command substitution, use `...` backticks instead. If you're unlucky enough to have files with spaces in their names, you'll need: fossil changes -missing | xargs -r -d'\n' fossil revert You can limit the scope by giving one or more directory name arguments to changes, e.g. "." for the current directory. Short of being clever with grep, you cannot inhibit recursion, so subdirectories are always processed too. I hope to change this eventually. If you don't have my enhanced changes command, in place of "fossil changes -missing" you can write: fossil changes | sed -rn '/^MISSING */s///p' This fails if a filename happens to start with spaces. Sorry, I can't properly reply to the email since I can see it only in the web archive and not my mailer (actually my phone), so it must have arrived during the time my account was deactivated due to bogus bounces. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] UNIQUE constraint fail on sync -private
Not a lot of time to write. I'm on my way to the airport but need to
prepare by sync'ing some Fossil repositories onto a laptop. I did a
"fossil sync -once -private http://..."; to push private branches to
another laptop, only to be hit with:
Error: Database error: UNIQUE constraint failed: private.rid: {INSERT
INTO private VALUES(148260)}
When I checked the private table of the recipient, indeed that RID was
already marked private, along with all the others from the private
branches I'm pushing.
Looks like something is getting done twice, perhaps...?
Yet the new artifacts do not show in /rcvfromlist nor /timeline.
My quick fix was to change "INSERT INTO private" to "INSERT OR IGNORE
INTO private" in content_put_ex() in content.c. Making the same change
in content_new() didn't help, though maybe it would have avoided the
original problem. I don't have time to check.
--
Andy Goth |
signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Timeline bug: horizontal merge arrow without vertical
http://core.tcl.tk/tcl/timeline?a=b40778af44&m=7054e2f2eb The marked check-in merges from trunk, but trunk is not visible on the timeline. In similar situations in the past I believe there were merge arrows coming from the bottom of the timeline, but in this instance only the horizontal line is shown. Fossil version 6f3ec1bef6. Also, yeah, I've gone back to being too busy to do Fossil development. Sorry about that. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] toc.tcl
First off, I'm sorry I've been so incredibly busy with work and business travel, no time for Fossil development or even reading the mailing list. The only issues I've been able to dink on lately are those that were stopping me from getting my work done. I'm trying to change jobs so I might have a shot at working fewer than one hundred hours a week (no joke). I have, however, been continuing to add to my Fossil TODO list, taking notes of bugs and features I'd like to look at someday. If I ever get some free time, I have a lot planned. With that out of the way, onward to the subject of this email. Here's a short Tcl script I wrote the other day to put a table of contents in a Markdown document. https://chiselapp.com/user/andy/repository/brush/file/doc/toc.tcl Here's example output: https://chiselapp.com/user/andy/repository/brush/doc/trunk/doc/concepts.md To use, put and lines in your Markdown file, then run toc.tcl with your filename as an argument. By design, it only works with #- and ##-style headings, not underlines. If the file already contains a table of contents, it will be replaced. Rerun the script after adding, removing, or renaming any first- or second-level headings. ___ 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 version 2.3 - 10th anniversary edition
On 07/12/17 13:50, Richard Hipp wrote: The current plan is to release the 10th anniversary edition of Fossil, version 2.3, on 2017-07-21. I've been more-or-less keeping SlackBuilds up-to-date on Fossil releases, even though it's been a long time since I announced that I'm doing this. Earlier this year I expanded my build script README to do a better job of explaining what's so cool about Fossil. Have a look: https://slackbuilds.org/repository/14.2/development/fossil/ If anyone has any suggestions or corrections, please let me know so I can incorporate them into the README for the SlackBuild for the next Fossil release. ___ 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] Initial empty checkin?
On 07/17/17 03:50, Jan Nijtmans wrote: The patch below modifies Fossil not to create the initial empty commit. (I always build Fossil with this patch). Everything works fine without initial empty commit, the reason this was in Fossil is just historical. Nowadays, there - indeed - is no reason any more to create an empty initial commit, in my opinion is confuses more than that it helps anything. Your mail tells me enough What of this old thread? Are the issues it discusses still pertinent, or have they been resolved? http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19845.html ___ 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] Rectangle around leaf in web interface
On 07/23/17 15:44, Thomas wrote: I've noticed very early that sometimes there's a rectangle around the leaf in the web interface and sometimes there isn't. Leaves are shown by a black dot inside the circle in the graph. (You can also configure Fossil to use squares rather than circles.) Leaves are also shown by the boldface word "Leaf:" right before the check-in comment. Since I believe the rectangle looks quite nice Thank you, I styled it. :^) http://fossil-scm.org/index.html/info/e5b53f15cb6c32d7 http://fossil-scm.org/index.html/info/f23ccc89cecaf2e1 -- Andy Goth | ___ 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] toc.tcl
On 08/16/17 10:54, dewey.hyl...@gmail.com wrote: I've been wishing for something similar to the TOC macro available in moinmoin, and this is fairly close. The only thing missing from my perspective is a link at each heading which points back to the top. I don't know jack about TCL, but perhaps it's time for me to look into it! Worth it. I appreciate your work on this! Try this new version: https://chiselapp.com/user/andy/repository/brush/file/doc/toc.tcl -- Andy Goth | ___ 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] toc.tcl
On 08/18/17 07:38, Dewey Hylton wrote: I predict this to be the best email I receive today. My first thought was "This is like paid support!" My second thought was "Wait ... paid support has *never* been this good ..." Thanks for your work! Since you seem to be really interested, have one more improvement. Now there's no need for an marker. The table of contents extends from to the first blank line. Aside from looking cleaner overall, this works around a Markdown rendering oddity which required me to put a blank line between the last line of the TOC list and the line. https://chiselapp.com/user/andy/repository/brush/file/doc/toc.tcl -- Andy Goth | ___ 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] toc.tcl
It's online now. Also, here's the code:
#!/usr/bin/env tclsh
package require Tcl 8.6
# Link back to table of contents.
set top {[top]}
# Process each named file.
foreach file $argv {
# Read Markdown file.
set chan [open $file]
set data [chan read $chan]
chan close $chan
# Check if the Markdown file contains a TOC.
if {[string first $data] >= 0} {
# If so, build the TOC to contain all first- and second-level
headings.
# Consider only headings using "#" and "##" marks, not underlines.
set start 0
set toc
append toc "\n"
append toc " Table of Contents\n" [string repeat = 50]
while {[regexp -indices -line -start $start {^##?[^#].*} $data
match]} {
# Get line from input.
set line [string range $data {*}$match]
# Get heading level.
regexp {^(#*)(.*)} $line _ heading line
# Strip the anchor tag if present.
regsub {^ } $line {} line
# Strip the link to the TOC if present.
regsub { "
# Build table of contents.
append toc \n
if {$heading eq "##"} {
append toc " "
}
append toc "* \[$title\](#$name)"
# Replace the section header line.
set line "$heading $anchor $title $top"
set data [string replace $data {*}$match $line]
# Update the start index.
set start [expr {[lindex $match 0] + [string length $line]}]
}
append toc \n
# Write Markdown file with the table of contents inserted.
set chan [open $file w]
chan puts -nonewline $chan [regsub -line
{^$(?:\n.+$)*\n$}\
$data [string map {& \& \\ } $toc]]
chan close $chan
}
}
# vim: set sts=4 sw=4 tw=80 et ft=tcl:
On Aug 21, 2017 09:47, "jungle Boogie" wrote:
> On 20 August 2017 at 10:24, Andy Goth wrote:
> > On 08/18/17 07:38, Dewey Hylton wrote:
> >>
> >> I predict this to be the best email I receive today.
> >>
> >> My first thought was "This is like paid support!"
> >> My second thought was "Wait ... paid support has *never* been this good
> >> ..."
> >>
> >> Thanks for your work!
> >
> >
> > Since you seem to be really interested, have one more improvement. Now
> > there's no need for an marker. The table of contents extends
> > from to the first blank line. Aside from looking cleaner
> > overall, this works around a Markdown rendering oddity which required me
> to
> > put a blank line between the last line of the TOC list and the
> > line.
> >
> >
> > https://chiselapp.com/user/andy/repository/brush/file/doc/toc.tcl
> >
>
>
> Any chance of using something like https://www.pastiebin.com to show the
> code?
> chiselapp.com is offline, and it looks like that's been the case of a
> few days now.
> ___
> 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
Re: [fossil-users] strange problem with graphical diff
I would also suggest finding an old version of Fossil that doesn't exhibit the problem and using bisect to pinpoint when the behavior changed. On Wed, Aug 23, 2017 at 8:21 AM, Richard Hipp wrote: > On 8/23/17, j. van den hoff wrote: > > unable to create directory /var > > > > It is trying to create a temporary file in which to store the one of > the two sides of the diff. Can you trace the problem by running in a > debugger? > > -- > 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 > -- Andy Goth | ___ 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] Minor typos in fossil documentation
On 08/24/17 04:48, rosscann...@fastmail.com wrote: The fossil documentation is so good, it's a shame to allow even the tiniest imperfection! Thanks, fixed. Please review: http://fossil-scm.org/index.html/info/f98852a0df35ef2a -- Andy Goth | ___ 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] toc.tcl
On 08/27/17 21:14, dewey.hyl...@gmail.com wrote: my static site generator leverages blackfriday for markdown parsing, and pygment-colored code blocks are framed with "```" ... these blocks do not get ignored by your script, and the commented lines inside the code blocks get meddled with. "```" is not special to Fossil, so it's not recognized by my script. But that's easily remedied. Please try: https://chiselapp.com/user/andy/repository/brush/file/doc/toc.tcl To keep this email relevant to Fossil, let me ask if there is any interest in adding "```" which appears to be intended to mark a code block without having to indent each line. I vote no because what we have works for me, but others may disagree. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] New release?
At work I'm having some difficulty due to the most recent released version of Fossil not including my correction for /doc on read-only repository files. Would it be possible to make another release to include this and other recent changes? The branch titled branch-2.3 seems to collect high-priority bug fixes slated for inclusion in future version 2.3.1. However, it doesn't have [95edba65] nor [da23bec7] which are most important to me, nor does it have my most recent Markdown documentation update which also matters for my project because it is referenced by deliverable documentation. -- Andy Goth | ___ 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] toc.tcl
On 08/29/17 21:18, Offray Vladimir Luna Cárdenas wrote:
On 29/08/17 20:11, Andy Goth wrote:
To keep this email relevant to Fossil, let me ask if there is any
interest in adding "```" which appears to be intended to mark a code
block without having to indent each line. I vote no because what we
have works for me, but others may disagree.
I would vote yes. It's used in Pandoc's markdown and others and is
becoming a standard practices for documentation made with this popular
Markdown families.
dewey.hylton says "```" imbues syntax highlighting whereas indented
lines are left plain. Fossil doesn't do any kind of syntax highlighting
at this point. Is there any interest in having this feature? I feel
syntax highlighting is both expected and bloat. We would have to decide
which we prefer: being simple or having me-too features.
I'm curious how the Markdown formatter would know what language rules to
use for syntax highlighting, so surely there's more to the syntax than
bracketing ("fencing") the code with lines consisting entirely of "```".
I searched online and found the answer to be: put the name of the syntax
highlight mode (i.e. the language) right after the first "```" on the
same line, for instance "```ruby".
I have updated my toc.tcl to allow for extra text to follow "```". The
change is committed to chiselapp. dewey.hylton, please review.
--
Andy Goth |
___
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] New release?
On 08/30/17 06:05, Richard Hipp wrote: On 8/29/17, Andy Goth wrote: At work I'm having some difficulty due to the most recent released version of Fossil not including my correction for /doc on read-only repository files. Would it be possible to make another release to include this and other recent changes? Can you not just download and compile the latest trunk? I tried that once, had trouble with my self-compiled Windows binary having the right icon and other such frou-frou. But yeah, that's probably the best solution regardless because I can do it immediately without having to wait for someone else's release schedule. Is there a compilation guide that says how exactly the official Windows binaries are produced? I'd like to get that part right if I can. On Linux I build Fossil myself all the time. It's just Windows that's a headache for me. -- Andy Goth | ___ 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] Strange IP address on repository sync report.
Do you have gdb installed? First, ensure you're using a recent version of Fossil, 2.2 or newer. Run: gdb --args fossil sync [any extra arguments go here] b http_ssl.c:394 r The sync will begin, then will be interrupted immediately before running the requested line of code. Type "p ip" to print the ip array, though it might be formatted kind of funny due to being a character array. Then type "n" to execute the line of code, then type "p g.zIpAddr" to print the properly formatted IP address. With that done, you can continue the sync by typing "c". Or you can abandon it by typing "q". Report back with what you find. On Fri, Sep 15, 2017 at 3:22 PM, Dewey Hylton wrote: > Sadly, I do not know how to do such a thing as I am not a developer. The > concept is not foreign to me as I have a bit of experience with python, so > I'll give it a shot starting with Google. Pointers to get me on the right > track would be welcomed. > > > On Sep 15, 2017, at 3:58 PM, Richard Hipp wrote: > > > >> On 9/15/17, Dewey Hylton wrote: > >> just for completeness ... i verified that i am seeing the same address > >> during a commit: > >> > >> Autosync: https://redacted > >> Round-trips: 1 Artifacts sent: 0 received: 0 > >> Pull done, sent: 390 received: 994 ip: 2.0.1.187 > >> New_Version: 906246b7cd7e5fec91c69502981582bdbfc0a89e > >> Autosync: https://redacted > >> Round-trips: 1 Artifacts sent: 2 received: 0 > >> Sync done, sent: 1344 received: 1045 ip: 2.0.1.187 > > > > Please rerun in a debugger with a breakpoint on this line: > > > >https://www.fossil-scm.org/fossil/artifact/91aa0e52?ln=394 > > > > And let me know if that is where g.zIpAddr is getting set and why it > > is being set to the wrong IP address. > > > >> > >> > >> i suppose the environment variables don't matter at this point, but > this is > >> what i see: > >> > >> uid=10080, gid=10080 > >> g.zBaseURL = https://redacted > >> g.zHttpsURL = > >> g.zTop = /fossil/ansible-ceph > >> g.zPath = test_env > >> g.userUid = 6 > >> g.zLogin = redacted > >> g.isHuman = 1 > >> capabilities = abcefghijklmnopqrstwz > >> g.zRepositoryName = /data/fossil/ansible-ceph.fossil > >> load_average() = 0.01 > >> -- > >> GATEWAY_INTERFACE = CGI/1.0 > >> HTTP_ACCEPT_ENCODING = gzip, deflate, br > >> HTTP_HOST = redacted > >> HTTP_USER_AGENT = Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) > >> Gecko/20100101 Firefox/55.0 > >> PATH_INFO = test_env > >> QUERY_STRING = > >> REMOTE_ADDR = 127.0.0.1 > >> REQUEST_METHOD = GET > >> REQUEST_URI = /ansible-ceph/test_env > >> SCRIPT_NAME = /ansible-ceph > >> > >>> On Fri, Sep 15, 2017 at 3:32 PM Richard Hipp wrote: > >>> > >>>> On 9/15/17, Richard Hipp wrote: > >>>> > >>>> Perhaps Apache is setting the REMOTE_ADDR environment variable. What > >>>> does https://asm32.info/fossil/repo/asmbb/test_env show for the > >>>> administrator? (You have that page turned off for anonymous, so I > >>>> cannot see it.) > >>> > >>> Nevermind - the problem is on the client side, not on the server. So > >>> it is not an Apache problem Not sure what might be causing > >>> that > >>> > >>> -- > >>> 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 > >>> > >> > > > > > > -- > > 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 > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- Andy Goth | ___ 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] Strange IP address on repository sync report.
I'm not seeing the original problem, by the way. $ uname -a Linux blind 4.9.45 #1 SMP Fri Aug 25 01:04:38 CDT 2017 x86_64 Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz GenuineIntel GNU/Linux $ f clone https://asm32.info/fossil/repo/asmbb asmbb.fossil Round-trips: 6 Artifacts sent: 0 received: 1586 Clone done, sent: 1636 received: 26647661 ip: 164.138.218.50 Rebuilding repository meta-data... 100.0% complete... Extra delta compression... Vacuuming the database... project-id: eb5e52e8846e13a14061ee7131c951c0e03e7539 server-id: c5e2f4730d9532837e6952d5435d0a7d50067bd2 admin-user: andy (password is "d2c435") $ ping asm32.info PING asm32.info (164.138.218.50) 56(84) bytes of data. ^C --- asm32.info ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms $ f sync -R asmbb.fossil Sync with https://asm32.info/fossil/repo/asmbb Round-trips: 1 Artifacts sent: 0 received: 0 Sync done, sent: 1862 received: 1876 ip: 164.138.218.50 On Fri, Sep 15, 2017 at 2:16 PM, John Found wrote: > I am not sure the problem is in fossil itself, but don't know from where > to search it. > Anyway, after sync command on one of my repositories, I get the following: > > Sync with https://asm32.info/fossil/repo/asmbb > Round-trips: 1 Artifacts sent: 0 received: 0 > Sync done, sent: 1930 received: 1817 ip: 2.0.1.187 > > But the IP address of the server is totally different: 164.138.218.50 > > I recompiled fossil from the latest trunk version, but without change. > The other my repositories report the correct IP address of the web server. > > What can be the problem? > > Regards > John Found > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- Andy Goth | ___ 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] Strange IP address on repository sync report.
The value of *ip will be 2. Instead try "p *ip@4" which will print four bytes, which will be 2, 0, 1, and 187. The issue appears to be somewhere within BIO_ptr_ctrl(). On Sat, Sep 16, 2017 at 12:10 PM, Andy Bradford wrote: > Thus said Andy Bradford on Sat, 16 Sep 2017 11:09:18 -0600: > > > It might be useful here to also: > > > > print *p > > Of course, I meant *ip > > Andy > -- > TAI64 timestamp: 400059bd5b14 > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- Andy Goth | ___ 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] Strange IP address on repository sync report.
Do you have the same problem when you run a freshly compiled-from-scratch Fossil binary? We want to confirm you don't somehow have old object files linked in. On Sat, Sep 16, 2017 at 1:04 PM, John Found wrote: > On Sat, 16 Sep 2017 12:16:54 -0500 > Andy Goth wrote: > > > The value of *ip will be 2. Instead try "p *ip@4" which will print four > > bytes, which will be 2, 0, 1, and 187. > > (gdb) p *ip@4 > $5 = "\002\000\001\273" > (gdb) continue > Sync done, sent: 1929 received: 0 ip: 2.0.1.187 > > > > > The issue appears to be somewhere within BIO_ptr_ctrl(). > > > > On Sat, Sep 16, 2017 at 12:10 PM, Andy Bradford < > amb-fos...@bradfords.org> > > wrote: > > > > > Thus said Andy Bradford on Sat, 16 Sep 2017 11:09:18 -0600: > > > > > > > It might be useful here to also: > > > > > > > > print *p > > > > > > Of course, I meant *ip > > > > > > Andy > > > -- > > > TAI64 timestamp: 400059bd5b14 > > > > > > > > > ___ > > > fossil-users mailing list > > > fossil-users@lists.fossil-scm.org > > > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > > > > > > > > > > -- > > Andy Goth | > > > -- > http://fresh.flatassembler.net > http://asm32.info > John Found > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- Andy Goth | ___ 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] Strange IP address on repository sync report.
Please type "openssl version" and let us know what it prints.
I have version 1.0.2l, which has this in include/openssl/bio.h:
#define BIO_get_conn_ip(b) BIO_ptr_ctrl(b,BIO_C_GET_CONNECT,2)
Contrast with the latest OpenSSL which has:
typedef union bio_addr_st BIO_ADDR;
#define BIO_get_conn_address(b) ((const BIO_ADDR
*)BIO_ptr_ctrl(b,BIO_C_GET_CONNECT,2))
And in openssl/crypto/bio/bio_lcl.h:
union bio_addr_st {
struct sockaddr sa;
#ifdef AF_INET6
struct sockaddr_in6 s_in6;
#endif
struct sockaddr_in s_in;
#ifdef AF_UNIX
struct sockaddr_un s_un;
#endif
};
For more information on this change, see:
https://github.com/openssl/openssl/commit/28a0841bf58e3813b2e07ad22f19484308e2f70a
My suspicion is you're getting an IPv6 address in a sockaddr_in6 whereas
Fossil is hardwired for IPv4.
On Sat, Sep 16, 2017 at 1:26 PM, John Found wrote:
> On Sat, 16 Sep 2017 13:16:20 -0500
> Andy Goth wrote:
>
> > Do you have the same problem when you run a freshly compiled-from-scratch
> > Fossil binary? We want to confirm you don't somehow have old object files
> > linked in.
> >
>
> Yes. Checked twice. The fossil repository updated. "make clean", "fossil
> clean",
> "./configure", "make".
>
> $fossil version
> This is fossil version 2.4 [e6f64f5eeb] 2017-09-08 04:05:39 UTC
>
>
> Notice that the problem is only with *one* of my repositories.
>
>
> > On Sat, Sep 16, 2017 at 1:04 PM, John Found
> wrote:
> >
> > > On Sat, 16 Sep 2017 12:16:54 -0500
> > > Andy Goth wrote:
> > >
> > > > The value of *ip will be 2. Instead try "p *ip@4" which will print
> four
> > > > bytes, which will be 2, 0, 1, and 187.
> > >
> > > (gdb) p *ip@4
> > > $5 = "\002\000\001\273"
> > > (gdb) continue
> > > Sync done, sent: 1929 received: 0 ip: 2.0.1.187
> > >
> > > >
> > > > The issue appears to be somewhere within BIO_ptr_ctrl().
> > > >
> > > > On Sat, Sep 16, 2017 at 12:10 PM, Andy Bradford <
> > > amb-fos...@bradfords.org>
> > > > wrote:
> > > >
> > > > > Thus said Andy Bradford on Sat, 16 Sep 2017 11:09:18 -0600:
> > > > >
> > > > > > It might be useful here to also:
> > > > > >
> > > > > > print *p
> > > > >
> > > > > Of course, I meant *ip
> > > > >
> > > > > Andy
> > > > > --
> > > > > TAI64 timestamp: 400059bd5b14
> > > > >
> > > > >
> > > > > ___
> > > > > fossil-users mailing list
> > > > > fossil-users@lists.fossil-scm.org
> > > > > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/
> fossil-users
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Andy Goth |
> > >
> > >
> > > --
> > > http://fresh.flatassembler.net
> > > http://asm32.info
> > > John Found
> > > ___
> > > fossil-users mailing list
> > > fossil-users@lists.fossil-scm.org
> > > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> > >
> >
> >
> >
> > --
> > Andy Goth |
>
>
> --
> http://fresh.flatassembler.net
> http://asm32.info
> John Found
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
--
Andy Goth |
___
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] Strange IP address on repository sync report.
Indeed, 1.1.0f is a version which includes the BIO_ADDR type, which is a union containing struct sockaddr_in6 among others. I don't think there's any question Fossil is trying to read an IPv6 address structure as if it were IPv4. Try typing "ping asm32.info" and "ping6 asm32.info" (or whatever else is giving you trouble) and let us know what they say. Hit Ctrl+C to interrupt the ping. On Sat, Sep 16, 2017 at 1:57 PM, John Found wrote: > On Sat, 16 Sep 2017 13:44:51 -0500 > Andy Goth wrote: > > > Please type "openssl version" and let us know what it prints. > > > > OpenSSL 1.1.0f 25 May 2017 > > -- > http://fresh.flatassembler.net > http://asm32.info > John Found > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] uv add dir/filename
Currently the "fossil uv add" command rejects filenames containing directory components. I suggest instead applying this restriction only to the value of the "-as" switch, with "-as" defaulting to the filename sans directory components. -- Andy Goth | ___ 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] uv add dir/filename
On 09/19/17 06:45, Roy Keene wrote: On Tue, 19 Sep 2017, Andy Goth wrote: Currently the "fossil uv add" command rejects filenames containing directory components. I suggest instead applying this restriction only to the value of the "-as" switch, with "-as" defaulting to the filename sans directory components. Why add this restriction to the "--as" switch ? I currently use "fossil uv add --as release-/" http://fossil-scm.org/index.html/artifact?ln=291-297&name=af5f3c4e852989bd After actually looking at this code, I see that there's not a blanket restriction on directory components. It's quite a bit more relaxed. My problem was that everything I was trying to add had an absolute path, and I drew the wrong conclusion that no directories could be specified. Okay, I suggest refining the error message to not just say the filename is unacceptable, but rather to explain the restriction, like is done with whitespace. -- Andy Goth | ___ 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] Ignoring files/directories in automated zip files?
On 9/19/2017 4:22 PM, BohwaZ wrote: > The only way to avoid that is having Composer use your dist zip and have > that zip file only contain what should be required. Put the ex= query parameters directly in the download links on your web pages. When the user clicks Download, the zip or tar.gz file will contain the appropriate subset of files. > In Fossil anyone could just create a make recipe to generate a proper > ZIP file and sync it in the unversioned files instead. Also good. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] Ignoring files/directories in automated zip files?
On 9/19/2017 5:57 PM, Richard Hipp wrote: > If having a default ex= value really is needed, perhaps it could be > provided using alternative URLs - perhaps /abridgedtarball and > /abridgedzip instead of /tarball and /zip. Or maybe some other prefix > that is more succinct than "abridged". Maybe /exporttarball and > /exportzip? Maybe instead consider URL rewriting so the administrator defines custom pages (URIs) which are handled by redirecting to the standard pages. This general facility might be more useful than adding special cases to zip/tar.gz generation. Apache already provides this feature, so if Fossil is the CGI backend for part of your Apache site, then you have everything you need. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] New release?
On 8/30/2017 10:51 AM, Richard Hipp wrote: > On 8/30/17, Andy Goth wrote: >> Is there a compilation guide that says how exactly the official Windows >> binaries are produced? I'd like to get that part right if I can. > > I use this TCL script: > > cd c:/users/drh/fossil/m1 > exec make -f win/makefile.mingw FOSSIL_ENABLE_SSL=1 > OPENSSLDIR=../../openssl-1.0.1t >@stdout 2>@stdout > exec ls -l c:/users/drh/fossil/m1/fossil.exe >@stdout Thanks. This comes very close to working for me. I was able to produce a fossil.exe that runs, but only when it's in the same directory as msys-crypto-1.0.0.dll and msys-ssl-1.0.0.dll. Clearly your OpenSSL is different than mine. How did you get it? -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] New release?
On 9/20/2017 5:54 PM, Richard Hipp wrote: > On 9/20/17, Andy Goth wrote: >> Clearly your OpenSSL is different than mine. How did you get it? > > Sorry - I don't recall OpenSSL-1.1.0f doesn't easily work because it requires a newer version of Perl than is bundled with MinGW/MSYS, so I grabbed OpenSSL-1.0.2l: https://www.openssl.org/source/openssl-1.0.2l.tar.gz I used "tar xzf" to unpack, then cd'ed to the directory and typed: "perl Configure mingw no-shared no-asm --prefix=/usr/local/openssl" Next came "make" and "make install". Actually pretty sure I could have just done "make install" since it seemed to go back and run "make" again only to find that it's all built. It wasted so much time installing man pages that I think it might be worth figuring out how to skip that step. With that done, I was able to build Fossil using your instructions, adapted a little bit: make -f win/Makefile.mingw FOSSIL_ENABLE_SSL=1 OPENSSLDIR=/usr/local/openssl OPENSSLLIBDIR=/usr/local/openssl/lib -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Continued issues with read-only repository
I'm fine in Linux working from a loopback-mounted ISO9660 disc image, but in Windows 8.1 doing the same nets me the following: SQLITE_NOTE: delayed 1375ms for lock/sharing conflict at line 43312 SQLITE_CANTOPEN: os_win.c:43319:(5) winOpen(E:\repo.fossil) - Access is denied. Followed by what appears to be normal operation. I get my web pages, and it seems good, except for three problems. One, page generation is a lot slower since I'm guessing it's having to wait a few seconds each request for some timeout. Two, the errors themselves appear at the top of every page. Three, the errors also appear in HTML format at the start of style.css, corrupting the first definition and messing up the page style. What can be done about this? -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] Continued issues with read-only repository
Okay cool, I'll tell the Air Force that's what they need to do. On Thu, Sep 21, 2017 at 7:13 AM, Roy Keene wrote: > Quit using Windows ? > > > On Wed, 20 Sep 2017, Andy Goth wrote: > > I'm fine in Linux working from a loopback-mounted ISO9660 disc image, >> but in Windows 8.1 doing the same nets me the following: >> >> SQLITE_NOTE: delayed 1375ms for lock/sharing conflict at line 43312 >> SQLITE_CANTOPEN: os_win.c:43319:(5) winOpen(E:\repo.fossil) - Access is >> denied. >> >> Followed by what appears to be normal operation. I get my web pages, >> and it seems good, except for three problems. >> >> One, page generation is a lot slower since I'm guessing it's having to >> wait a few seconds each request for some timeout. >> >> Two, the errors themselves appear at the top of every page. >> >> Three, the errors also appear in HTML format at the start of style.css, >> corrupting the first definition and messing up the page style. >> >> What can be done about this? >> >> -- >> Andy Goth | >> >> >> _______ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- Andy Goth | ___ 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] Continued issues with read-only repository
I added "set FOSSIL_VFS=win32-none" to my documentation viewer batch file. This had no apparent effect. Is there another value I can give it that will have a more dramatic effect to confirm it's being seen by Fossil? On Sep 21, 2017 8:08 AM, "Richard Hipp" wrote: > On 9/20/17, Andy Goth wrote: > > I'm fine in Linux working from a loopback-mounted ISO9660 disc image, > > but in Windows 8.1 doing the same nets me the following: > > > > SQLITE_NOTE: delayed 1375ms for lock/sharing conflict at line 43312 > > SQLITE_CANTOPEN: os_win.c:43319:(5) winOpen(E:\repo.fossil) - Access is > > denied. > > > > Try setting the FOSSIL_VFS environment variable to "win32-none". That > will disable all file locking on the repository (on windows), which > should be harmless in that the filesystem is readonly so that another > process cannot change the file out from under Fossil. > > The equivalent for Unix would be "unix-none", of course. > -- > 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 > ___ 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] Continued issues with read-only repository
Nothing happens. By which I mean Fossil refuses to start, saying it sees no xyzzy here. So, twice as much happens. Therefore it is honoring my VFS change, and picking win32-none is not the solution to my problem. To reproduce, all that's needed is to set the repository file read-only in Windows, then run "fossil ui". On Sep 21, 2017 9:29 AM, "Richard Hipp" wrote: On 9/21/17, Andy Goth wrote: > I added "set FOSSIL_VFS=win32-none" to my documentation viewer batch file. > This had no apparent effect. Is there another value I can give it that will > have a more dramatic effect to confirm it's being seen by Fossil? set FOSSIL_VFS=xyzzy Then run: fossil status You should see: no such VFS: "xyzzy" -- 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 ___ 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] Continued issues with read-only repository
On 9/21/2017 1:18 PM, Richard Hipp wrote: > The problem is that the Windows VFS has logic that retries failed I/O > operations repeatedly before giving up. This is a work-around to the > common issue of anti-virus software holding files hostage while they > are being scanned. It was a mistake to ever let the humans use computers. > As an interim fix, can you recompile with -DSQLITE_WIN32_IOERR_RETRY=0 > and let me know if that clears the problem for you? This improves matters but doesn't totally fix everything. Fossil starts far faster and no longer has the lock/sharing conflict warning. However, it still has the access denied error: SQLITE_CANTOPEN: os_win.c:43319: (5) winOpen(c:\Users\andy\repos\fossil.fossil) - Access is denied. This time I'm running it on a different computer with a different database, just Fossil itself, so I don't have to bother deploying the new fossil.exe. The major consequence of having the error message is that it breaks CSS due to appearing right at the start of style.css, which is not HTML. Here's what gdb has to say: #0 winOpen (pVfs=0x77e360 , zName=0x16c1ef8 "C:\\Users\\andy\\repos\\fossil.fossil", id=0x16c1e20, flags=262, pOutFlags=0x28ed8c) at src/sqlite3.c:43319 #1 0x00518533 in sqlite3OsOpen (pVfs=0x77e360 , zPath=0x16c1ef8 "C:\\Users\\andy\\repos\\fossil.fossil", pFile=0x16c1e20, flags=262, pFlagsOut=0x28ed8c) at src/sqlite3.c:20884 #2 0x00529aa2 in sqlite3PagerOpen (pVfs=0x77e360 , ppPager=0x16c1cb0, zFilename=0x16c1970 "C:/Users/andy/devel/fossil/../../repos/fossil.fossil",nExtra=84, flags=0, vfsFlags=262, xReinit=0x5322fe ) at src/sqlite3.c:52249 #3 0x005324b8 in sqlite3BtreeOpen (pVfs=0x77e360 , zFilename=0x16c1970 "C:/Users/andy/devel/fossil/../../repos/fossil.fossil", db=0x17c1c28, ppBtree=0x16835cc, flags=0, vfsFlags=262) at src/sqlite3.c:61991 #4 0x00561da7 in attachFunc (context=0x1687298, NotUsed=3, argv=0x16872b4) at src/sqlite3.c:99901 #5 0x0055027d in sqlite3VdbeExec (p=0x1686de8) at src/sqlite3.c:86102 #6 0x0054619f in sqlite3Step (p=0x1686de8) at src/sqlite3.c:77478 #7 0x005463b2 in sqlite3_step (pStmt=0x1686de8) at src/sqlite3.c:77541 #8 0x00420cda in db_multi_exec ( zSql=0x16c1ac8 "ATTACH DATABASE 'C:/Users/andy/devel/fossil/../../repos/fossil.fossil' AS 'repository' KEY ''") at src/db.c:572 #9 0x00421a13 in db_attach (zDbName=0x16c19f8 "C:/Users/andy/devel/fossil/../../repos/fossil.fossil", zLabel=0x7dc395 "repository") at src/db.c:1139 #10 0x00421b8f in db_open_or_attach (zDbName=0x16c19f8 "C:/Users/andy/devel/fossil/../../repos/fossil.fossil", zLabel=0x7dc395 "repository") at src/db.c:1205 #11 0x0042248a in db_open_repository (zDbName=0x16c1920 "C:/Users/andy/devel/fossil/../../repos/fossil.fossil") at src/db.c:1518 #12 0x00422240 in db_open_local (zDbName=0x0) at src/db.c:1433 #13 0x0042257c in db_find_and_open_repository (bFlags=0, nArgUsed=0) at src/db.c:1560 #14 0x00446473 in info_cmd () at src/info.c:216 #15 0x00452844 in main (argc=3, argv=0x17c1b58) at src/main.c:760 The flags=262 argument decodes to: SQLITE_OPEN_MAIN_DB|SQLITE_OPEN_CREATE|SQLITE_OPEN_READWRITE The winOpen() function then successfully retries with flags altered to contain SQLITE_OPEN_READONLY instead of SQLITE_OPEN_READWRITE, and this succeeds. Trouble is, winLog() was already called, and the error message propagated back to Fossil and eventually the web server as garbage at the beginning of the CSS file. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] Continued issues with read-only repository
On 9/21/2017 3:17 PM, Andy Goth wrote: > The winOpen() function then successfully retries with flags altered to > contain SQLITE_OPEN_READONLY instead of SQLITE_OPEN_READWRITE, and this > succeeds. Trouble is, winLog() was already called, and the error > message propagated back to Fossil and eventually the web server as > garbage at the beginning of the CSS file. I tried the change you just checked into the SQLite repository (thanks for the same-minute turnaround time on that), and it solves my problem. Now is there anything to be done about the file locking issue? I just recompiled without -DSQLITE_WIN32_IOERR_RETRY=0 in case it was magically fixed, but of course not. So more thought is needed. For now I can just ship with -DSQLITE_WIN32_IOERR_RETRY=0, but I'd like to be able to use the next Fossil release binary out of the box. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] Continued issues with read-only repository
On 9/21/2017 3:48 PM, Richard Hipp wrote: > The latest check-in > (https://www.fossil-scm.org/fossil/info/e97d4443d5628702) loads a new > version of SQLite which should address the issues of trying to open a > read-only database file. Please try it and let me know. Looks good to me, provided I compile Fossil thus: make -f win/Makefile.mingw FOSSIL_ENABLE_SSL=1 OPENSSLDIR=/usr/local/openssl OPENSSLLIBDIR=/usr/local/openssl/lib CFLAGS=-DSQLITE_WIN32_IOERR_RETRY=0 Having previously built OpenSSL as described in my email: https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg25885.html Any thoughts on IOERR_RETRY? I'm hoping I don't run into problems on my normal development system since it's infected with Symantec, which in the recent past has quarantined the programs I wrote right as they are written by the compiler. Look buddy I know my code has bugs but at least give me a chance to run it through gdb! -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] Continued issues with read-only repository
On 9/21/2017 3:51 PM, Richard Hipp wrote: > Your fix to the /doc webpage was also helpful, Andy. I had seen that > error before but then it went away mysteriously and I was wondering > what happened. Apparently I pulled in your fix while testing my > changes, without realizing it. :-) When testing my previous change addressing this issue (http://fossil-scm.org/index.html/info/95edba6534dafc1f), I did so on a scrubbed repository which didn't have a vcache table, so i didn't realize it could get in trouble if vcache already existed but needed to be updated with the new vid. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] Continued issues with read-only repository
On 9/21/2017 4:13 PM, Richard Hipp wrote: > I think you can omit the IOERR_RETRY now. I believe I have fixed that > problem in the Windows VFS of SQLite. At least, it works for me on my > Win10 laptop when I set the repository file to read-only. Please try > it and let me know either way. Oh good, I didn't realize you changed that as well. This fix works for me too, no need for CFLAGS=-DSQLITE_WIN32_IOERR_RETRY=0. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Amended check-in time
I'm having trouble changing the time of a check-in using the Web interface or the amend command. Either way I get a good result in the repository I amended, but it doesn't seem to sync right. When viewing on other sync'ed repositories, the amended time isn't always there. With the test I just did, the corrected time showed up in the repository I edited and the one to which I directly sync'ed, but it did not show up in the repository to which the second repository sync'ed. Many months ago I also had trouble with the reparent tag being unreliable in the same way, to the point where I was forced to laboriously reconstruct my history without the use of reparent. I wonder if any of the other amendment tags have the same issue. In case you're wondering, my topology is a patchwork of always-available network connections, intermittent VPN connections, temporary network cables, and disgustingly manual sneakernet. I'm immensely grateful that Fossil is able to negotiate this environment at all; that's one of the features that makes it a necessity I continue to fight for even despite significant pushback. No alternative exists, so I'll keep using it. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] uv add dir/filename
On 9/19/2017 9:20 AM, Andy Goth wrote: > Okay, I suggest refining the error message to not just say the filename > is unacceptable, but rather to explain the restriction, like is done > with whitespace. Done. http://fossil-scm.org/index.html/info/493e3bade9ae8dc6 -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] Amended check-in time
On 9/21/2017 4:36 PM, Andy Goth wrote: > I'm having trouble changing the time of a check-in using the Web > interface or the amend command. Either way I get a good result in the > repository I amended, but it doesn't seem to sync right. When viewing > on other sync'ed repositories, the amended time isn't always there. The corrected time is lost when I rebuild the repository. > Many months ago I also had trouble with the reparent tag being > unreliable in the same way I remember the reparent tags also not surviving a rebuild. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] Amended check-in time
On 09/21/17 19:51, Richard Hipp wrote: I don't have any idea [why] the tags are not working for you. Try this sequence: f new repo.fossil mkdir ckout cd ckout f open ../repo.fossil touch xxx f add xxx f commit -date-override 2018-01-01 -m 'add xxx' sleep 5 TIME=$(date +%FT%T) sleep 5 f rm -hard xxx f commit -allow-older -m 'remove xxx' f timeline f amend -date "$TIME" prev f timeline f rebuild f timeline The first timeline has a time warp, as expected: === 2018-01-01 === 00:00:00 [447719afb0] add xxx (user: andy tags: trunk) === 2017-09-22 === 01:47:20 [7196e2f3c2] *CURRENT* remove xxx (user: andy tags: trunk) 01:47:10 [602cd20f89] initial empty check-in (user: andy tags: trunk) +++ no more data (3) +++ The second timeline has the corrected time: === 2017-09-22 === 01:47:20 [03d8e85285] Edit [447719afb096a7d3|447719afb0]: Timestamp 2017-09-21T20:47:15. (user: andy) 01:47:20 [7196e2f3c2] *CURRENT* remove xxx (user: andy tags: trunk) 01:47:10 [602cd20f89] initial empty check-in (user: andy tags: trunk) === 2017-09-21 === 20:47:15 [447719afb0] add xxx (user: andy tags: trunk) +++ no more data (4) +++ The third timeline, after the rebuild, has the original time warp again despite also showing the correction tag: === 2018-01-01 === 00:00:00 [447719afb0] add xxx (user: andy tags: trunk) === 2017-09-22 === 01:47:20 [03d8e85285] Edit [447719afb096a7d3|447719afb0]: Timestamp 2017-09-21T20:47:15. (user: andy) 01:47:20 [7196e2f3c2] *CURRENT* remove xxx (user: andy tags: trunk) 01:47:10 [602cd20f89] initial empty check-in (user: andy tags: trunk) +++ no more data (4) +++ This is fossil version 2.4 [493e3bade9] 2017-09-21 21:49:02 UTC -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Timeline tag format
On 09/21/17 20:48, Andy Goth wrote: 01:47:20 [03d8e85285] Edit [447719afb096a7d3|447719afb0]: Timestamp 2017-09-21T20:47:15. (user: andy) A digression. What is the purpose of showing the edited artifact ID twice with two different lengths? This output was produced by the timeline command. -- Andy Goth | ___ 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] Amended check-in time
On 09/21/17 20:48, Andy Goth wrote: The second timeline has the corrected time: === 2017-09-22 === 01:47:20 [03d8e85285] Edit [447719afb096a7d3|447719afb0]: Timestamp 2017-09-21T20:47:15. (user: andy) 01:47:20 [7196e2f3c2] *CURRENT* remove xxx (user: andy tags: trunk) 01:47:10 [602cd20f89] initial empty check-in (user: andy tags: trunk) === 2017-09-21 === 20:47:15 [447719afb0] add xxx (user: andy tags: trunk) +++ no more data (4) +++ Oops, I didn't look very closely at this. Time zone issues, ugh. Did you know that Narnia doesn't have time zones? A round earth was not a very good idea. -- Andy Goth | ___ 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] How to find out when a line was removed
On 09/23/17 10:18, John P. Rouillard wrote: I am trying to find out when a line dissapeared from a file. I've long wanted a reverse annotate command. Rather than show when each line was most recently modified or added, it would show when each line is next modified or removed. I haven't taken any steps toward implementation because this will be harder to use (certainly harder to implement) than normal annotation. Annotate works as well as it does because each revision has only one primary predecessor, so there's no ambiguity. Reverse annotate won't magically know the intended "next" version with which to compare. My best guess at how to handle this is to ask for a target version, and the path from the current version to the target version is the one along which changes are examined. I am managing a configuration file and one of the config options lines is no longer there. I initially thought of trying to bisect the file if I can identify when the system was properly configured. If I guess wrong I could end up having to run multiple bisects to find the last removal of the option line. Does fossil have something like "perforce annotate -a" or "git log -S" or "hg grep"? perforce annotate -a sounds interesting. "All lines, including deleted lines and lines no longer present at the head revision, are included. Each line includes a starting and ending revision." https://www.perforce.com/perforce/r14.2/manuals/cmdref/p4_annotate.html Though I suspect it could result in an extremely messy report should the lines be reorganized multiple times. Not exactly what you're asking, but you can search across many files and many revisions of many files using the fusefs command. fossil fusefs will make all revisions available in the filesystem so you can use standard programs like grep to examine them. However... If there is no equivalent in fossil, I am considering running: fossil finfo _filename_ ... You'll still need a list of versions to examine, though the above command will provide. to get a list of all the revisions where the file was changed then for each revision: fossil --checkin _revision_ _filename_ | grep "option name" Assuming you meant to have a "cat" in there somewhere. Also I was unaware the -r option could be spelled out as -checkin. Anybody have any answers, thoughts, comments or quips? I think your cat approach is solid. Bisect could work too, though it'll make many changes to your checkout directory. This process can be scripted. Pay attention to what you end up doing because your experience may end up contributing to the requirements for a reverse annotate feature. -- Andy Goth | ___ 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] How to find out when a line was removed
On 09/23/17 11:48, John P. Rouillard wrote: In message , Andy Goth writes: On 09/23/17 10:18, John P. Rouillard wrote: I am trying to find out when a line disappeared from a file. I've long wanted a reverse annotate command. Rather than show when each line was most recently modified or added, it would show when each line is next modified or removed. I haven't taken any steps toward implementation because this will be harder to use (certainly harder to implement) than normal annotation. Annotate works as well as it does because each revision has only one primary predecessor, so there's no ambiguity. Reverse annotate won't magically know the intended "next" version with which to compare. My best guess at how to handle this is to ask for a target version, and the path from the current version to the target version is the one along which changes are examined. That sounds workable. Similar to diff between two revisions. Good observation. The diff page could be used as a springboard to request a reverse annotation. I wanted to avoid requiring the user to type or paste in check-in IDs. Is "Reverse Annotate" the right name? On the diff page, this would go in the list of command links alongside "Invert", "Patch", "Path", "Side-by-Side Diff", and "Unified Diff". Like traditional annotation, reverse annotation would show the selected version of the file, with a check-in identifier on each line. Unlike traditional annotation, the check-in identifiers would all be future revisions, showing the *next* time the line is touched in any way. In this case, the "selected version" would be the diff "from" version, typically the oldest version. I guess this would make a double-reverse annotation possible too, should the user pick the diff versions backwards, from new to old. Going this direction, a line would be regarded as being deleted because the new revision has it and the old revision does not. The difference between this and traditional annotation is it gives finer control over which predecessor to examine, if the "to" version is on an old branch which wound up being merged into a branch that contributed to the "from" version. perforce annotate -a sounds interesting. "All lines, including deleted lines and lines no longer present at the head revision, are included. Each line includes a starting and ending revision." https://www.perforce.com/perforce/r14.2/manuals/cmdref/p4_annotate.html Though I suspect it could result in an extremely messy report should the lines be reorganized multiple times. It looks like it figures out for each line in the file what line was at that location in a prior revision. You can specify a range of revisions as well (not just a -N count). So: p4 annotate -a myfile@23,40 would just show the lines between the two revisions (@ is a way of specifying a revision range for a file). You can also do: myfile@>2017/09/03 to get all lines in revisions created since Sept 3 2017 (@> means the value is a starting point). At least in the web interface, Fossil directory listings have the option of showing the union of all check-ins, i.e. the name of every file that ever existed, on any branch whatsoever. This the closest analogy I can think of. If the directory listing could instead be made to show all filenames that exist either in a current version or any direct predecessor, up to some optional limit, would that be like what Perforce annotate -a does? Also this brings up an interesting point. None of annotate, blame or praise support specifying the revision of the file. I would think being able to annotate a previous version of the file would be useful. You're right, and that does seem useful. Not only that, but the functionality is available in the web interface, so why not the command line interface? annotate_cmd() in diff.c is hard-coded to only work with the current checkout version. Also, it can't be used outside of a checkout the same way cat and other commands can when given the -R option. As far as I can tell, here's the main part that has to change: https://fossil-scm.org/index.html/artifact?ln=2541-2548&name=d7dd6b9c57ceff7a Here's the analogous code in the web interface: https://fossil-scm.org/index.html/artifact?ln=2545&name=d7dd6b9c57ceff7a Quite a bit simpler, huh? The command line and web interfaces take totally different approaches to identifying which version to work with. The web interface simply asks the user, whereas the command line interface seems to take the long way around. If I'm reading this code correctly, it finds both the current check-in and the check-in that most recently modified the file, then uses these two values separately. Why not make the command line interface code more closely match the web interface code? Le
Re: [fossil-users] How to find out when a line was removed
On 09/23/17 12:29, Andy Goth wrote: The [annotate] command line and web interfaces take totally different approaches to identifying which version to work with. The web interface simply asks the user, whereas the command line interface seems to take the long way around. If I'm reading this code correctly, it finds both the current check-in and the check-in that most recently modified the file, then uses these two values separately. Why not make the command line interface code more closely match the web interface code? Let the annotate command accept a -r option to override the current check in for the value of mid, then proceed the same as the web interface code. I tried this, only to find that annotate only works when given a manifest in which a file actually changed. Otherwise I get this error: file #631 is unchanged in manifest #37365 So I had more work ahead of me. It's all done now though: http://fossil-scm.org/index.html/info/5a6b194bc900eb00 Please give this a try and let us know how it works for you. I don't think it's worth adding a -R option to annotate since there isn't one for diff. -- Andy Goth | ___ 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] How to find out when a line was removed
On 09/23/17 14:40, Richard Hipp wrote: On 9/23/17, Andy Goth wrote: I tried this, only to find that annotate only works when given a manifest in which a file actually changed. Otherwise I get this error: file #631 is unchanged in manifest #37365 Proposed changes: (1) Move the fix for the error above inside of the annotate_file() routine. In other words, have annotate_file() automatically seek out the checkin containing the most recent change to the file. (2) Move the call to compute_direct_ancestors() inside of annotate_file(). Agree to both. Would you like me to take a crack at this? I don't want to duplicate your effort. (3) Add a new parameter to annotate_file() which is the "destination" of the search. If "destination" is 0, then it does an ordinary annotation for all direct ancestors of "mid". But if "destination" is non-zero then it does an annotation of changes along the shortest [path] from "mid" to "destination". Speaking of path, I noticed an issue with the "Path" command link on the diff page. (Well, I should say that first I noticed the *existence* of the "Path" command link, since I never knew it was there before.) http://fossil-scm.org/index.html/timeline?me=c550402982cc9755&you=4c17ab60b9665e56 Here, the path goes backwards from "me" to its branch root then to "you". http://fossil-scm.org/index.html/timeline?me=7f29e2640ab5d1dc&you=4c17ab60b9665e56 Yet here, the path goes forwards from "me" to the tip of the branch, then to where that tip is integrated, then to "you". What's the difference between the two cases? Is this the same path logic that would be employed by annotate_file() when given a destination? (4) Given the changes above, it should be relatively simple to add switches to the "annotate" command, and new query parameters to the /annotate webpage, to do a reverse annotation. Sounds delightful! I hope this works. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Tech note search
I implemented tech note search capability on the search-technote branch. Please have a look and let me know if it's good. Maybe the way I named things isn't so great, I dunno, so feel free to fix style or other conventions. If it's good, go ahead and integrate it to trunk. I opted to keep tech note searching largely separate from wiki searching because I feel tech notes serve a significantly different purpose. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Merge question
In response to Chris Rydalch saying that search-technote works for him, in combination with it passing all my tests, I'd like to merge it to trunk. What is the correct procedure for doing so? If I do: $ f up trunk $ f merge search-technote -baseline root:search-technote -integrate Then any future merge of annotation-enhancements will omit all changes made 2017-09-23 because the merge record will show that they were already merged due to being in the baseline of search-technote. To correct, said future merge would have to explicitly use the -baseline root:annotation-enhancements option. Instead I could cherrypick each of the five check-ins comprising the search-technote branch. This would avoid the aforementioned problem but, in addition to being a pain in the butt to do, would also not put a merge arrow in the graph. Of course, while said merge arrow is nice to see, its existence is responsible for said problem. A third approach would be to construct an alternative annotation-enhancements branch made by cherrypicking each of the search-technote check-ins, but this new branch would be rooted on trunk. Then merge that branch and be done. What's the best way to handle this situation? While on this subject, there are also a number of other changes on the annotation-enhancements branch that are unrelated to annotations. What do we do with them? At this point I'm inclined to just be patient and let annotation-enhancements be merged first. That would solve everything. Yet, my question remains. What is the best way to handle merging a branch-to-a-branch back to trunk without immediately incorporating unrelated branch changes while still allowing said changes to be incorporated when the branch is later merged? -- Andy Goth | ___ 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] Merge question
On 09/25/17 10:18, Richard Hipp wrote: On 9/25/17, Andy Goth wrote: In response to Chris Rydalch saying that search-technote works for him, in combination with it passing all my tests, I'd like to merge it to trunk. What is the correct procedure for doing so? At this point I'm inclined to just be patient and let annotation-enhancements be merged first. That would solve everything. Merged now. Thank you for your testing and your corrections. I don't have access to any Ubuntu systems, so I didn't spot the original problem you came across. (No clue why Ubuntu has -Werror on by default, or whatever was going on. Might want to explicitly turn on more warnings like -Wunused or -Wall or even -Wextra to help spot these types of issues.) As far as I can tell, in the general case I described in my previous email, assuming waiting was not an option, the best to do would have been to explicitly specify the -baseline option when merging the child branch and later when merging its parent branch. But this MUST be done in combination with additional testing to confirm that the child branch wasn't actually dependent on anything in its parent branch. And of course the final merge also must be tested to confirm it didn't leave anything out due to -baseline being forgotten or mistyped. Thoughts? -- Andy Goth | ___ 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] Tech note search
On 09/25/17 09:35, Chris Rydalch wrote: Thanks so much Andy, this is great! So far so good on my end... Merged to trunk, along with all the other recent developments. Please update and test some more, if you don't mind. -- Andy Goth | ___ 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] Merge question
On 09/25/17 10:39, Richard Hipp wrote: On 9/25/17, Andy Goth wrote: As far as I can tell, in the general case I described in my previous email, assuming waiting was not an option, the best to do would have been to explicitly specify the -baseline option when merging the child branch and later when merging its parent branch. But this MUST be done in combination with additional testing to confirm that the child branch wasn't actually dependent on anything in its parent branch. And of course the final merge also must be tested to confirm it didn't leave anything out due to -baseline being forgotten or mistyped. Thoughts? I was thinking of changing --baseline so that it records the merge baseline using a Q card instead of a P card, as if the merge were a cherrypick. Not a bad idea at all. This avoids the second part of the problem quite nicely. If I recall correctly, the Q card supports listing a range of merged check-ins even though this feature is never actually used in practice. As for the user desire that a merge arrow be shown, I feel this would best be addressed by showing cherrypick and backout merges. I wrote up this wishlist item eons ago but never got around to working on it. Does anyone have any new ideas about this? How should such alternative merge arrows be rendered? Colors? Can dashed lines be shown? Can the arrowhead be a symbol such as a tiny circle or an X? -- Andy Goth | ___ 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] Amended check-in time
On 09/21/17 20:48, Andy Goth wrote: On 09/21/17 19:51, Richard Hipp wrote: I don't have any idea [why] the tags are not working for you. Try this sequence: f new repo.fossil mkdir ckout cd ckout f open ../repo.fossil touch xxx f add xxx f commit -date-override 2018-01-01 -m 'add xxx' sleep 5 TIME=$(date +%FT%T) sleep 5 f rm -hard xxx f commit -allow-older -m 'remove xxx' f timeline f amend -date "$TIME" prev f timeline f rebuild f timeline Has anyone tried running these commands yet? I want to see if anyone else can replicate my problem. Correction: Replace "date +%FT%T" with "date -u +%FT%T" to avoid timezone problems. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Built-in documents
Should /sitemap be added to the list of built-in documents in the new permutedindex.html? The built-in documents that were just added are already in the permuted index, which is fine, but when I asked myself if there are any other built-in documents, I thought of /sitemap. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] manifest setting "l" flag
http://fossil-scm.org/index.html/info/8d6bdd1e00cf2cf8 I added support for a new "l" flag to the "manifest" setting. With this flag present, a new file "manifest.symlinks" is automatically created and maintained. This file lists all symlinks (not their targets). I need this feature for a project that makes extensive use of symlinks and has to work on Windows even though the OS doesn't really have symlinks (at least not symlinks to files). On this project, I currently have a symlink list file which I maintain by running a script on Linux and checking in the result. When I run on Windows, everything in the project that actually needs to use symlinks looks at the symlinks file to see if it should read the file to get its target before proceeding. This works pretty well for me but is kind of awkward. I'd rather have the symlinks file be kept up to date, no fooling, without being a separately checked-in file. However, it's not 100% what I need. When working on Windows, I'd like to also be able to edit manifest.symlinks to change which files are and are not considered to be symlinks. I believe the current Fossil logic for handling symlinks on Windows is to create them as ordinary files containing their targets (no trailing newline), then leave them as symlinks in the manifest until they are changed. I'm thinking that when the "l" flag is set, the logic would instead be to reread the manifest.symlinks file when doing a commit and use it to decide what to mark as symlinks in the manifest. Said logic would only apply in Windows. -- Andy Goth | ___ 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] manifest setting "l" flag
On 09/29/17 04:20, Richard Hipp wrote: On 9/28/17, Andy Goth wrote: http://fossil-scm.org/index.html/info/8d6bdd1e00cf2cf8 Moved onto a branch: enhanced-symlink I thought about branching when I checked in, but I decided to stick with trunk because this can't affect any existing repositories. No one is using "l" for a different purpose. Why the branch now? Because there is more work to do before it meets my own needs? That would make sense. Any thoughts or discussion, anyone? -- Andy Goth | ___ 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] manifest setting "l" flag
On 09/28/17 21:34, Scott Robison wrote: There is a winsymlink branch I created some time ago. Hasn't been kept up to date (I didn't need it, just thought it might be useful for feature parity) but I could take a look at it if you were interested. Or you could. I had a peek. I know Windows NT derivatives allow symlinks to directories but was not aware any version of Windows allowed symlinks to files. What is the status of that? Having symlinks in Windows may seem cool at first, but it would actually be counterproductive without a good way to edit them. If Fossil is the only program on hand that can create, change, or unlink them, it might as well not even try. With the design I'm working toward, symlinks could be created, changed, or unlinked by editing the link file to contain its target and/or by editing manifest.symlinks to contain or not contain the link file name. Plus, the project I'm doing has to work all the way back to Windows 2000 and (maybe, possibly, unconfirmed) Windows 98. While it's not the end of the world if there are some platforms which can't be used as a build or development platform, right now I have it so that any supported system is fully capable of developing for all supported systems: Linux for Windows, Windows for Linux, etc. Therefore I do not want to rely on features that aren't bog standard throughout every version of Windows, 95 onward because long filenames. -- Andy Goth | ___ 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] web UI for a working checkout?
On 9/29/2017 3:15 PM, Steve Schow wrote: > Is anyone aware of any Web based ui for working with a working > checkout? I’m looking for the ability to have a web app that can > basically execute things like commit, branch, update and other > checkout related fossil commands, operating on a checkout directory > tree located on the webserver of course… http://chiselapp.com/ comes closest in that it provides a web interface for working on repositories as a whole. It does not provide what you ask, nor do I know of any other web platforms that do. The trouble is that in order for a checkout user interface to be meaningful, it needs to be bundled with tools to actually edit the checkout files. Otherwise there's little point. From the perspective of most programmers, web browsers can't compete with dedicated text editors, so what you describe will likely not be successful in targeting programmers. One thing that could happen is for "fossil ui" itself to get more checkout functionality, since it does indeed get used in combination with checkout editing. Since it's used in conjunction with the command line, it does not make any effort to replace the command line. But that doesn't mean it can't be an alternative interface, just like how it provides an alternative to diffing historical files from the command line. Personally I'm not interested in "fossil ui" performing the checkout manipulations you describe, but nevertheless I would like it to be a bit more aware of checkouts, e.g. to diff the current checkout with its baseline check-in or other versions, to show the list of changes, or to show and manage stashes. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] web UI for a working checkout?
On 9/29/2017 4:43 PM, Steve Schow wrote: > On Sep 29, 2017, at 2:46 PM, Andy Goth wrote: >> http://chiselapp.com/ > > Hey thats pretty cool, I was not even aware of that site! I am going > to check that out, I guess that’s a decent way to keep a repo public, > then I can clone it here locally for working on stuff. Spread the word! > But that webui just looks pretty much like the same one built into the > fossil binary, yes? When you're viewing any particular repository, yes. Chisel provides everything else surrounding the repositories. > Who is hosting that and what is the longevity compared to github and > others? Roy Keene can answer these questions. > Primary interest right now is in using a headless machine that will be > hosting a repo. And often users will not have command line access > either. In the simplest case, I could set it up, with web ui access > to the repo itself, but then always require them to clone the repo on > another machine and do all their edits there and push their changes > back to remote master repo. That is the basic arrangement Fossil was designed for. > But it turns out there is also a use case for them being able to add > files and commits to the repo directly on the headless linux box > without having to clone the repo to another client machine. I supposed one could call this a hosted development environment. Though let me add to what I said earlier (needing an editor, etc.) to point out that development is meaningless without testing. Unless the product being developed is documentation and testing is accomplished by reading the document as formatted by a browser, your users are going to want to be able to compile and run whatever they are making. Will your web platform provide that too? It's not totally out of the question, and I've seen submit-your-code-and-we'll-run-it stuff before. I'm just saying that there's a lot to consider before you reach the point that what you've put together is actually useful. > I hear what you’re saying about no way to edit without command line, > but actually it would be perfectly fine to have the check out dir tree > accessible via SMB share.. Then they can edit the files over SMB. > But without command line access there is no way for them to commit the > changes into fossil. That’s where a Web UI for some of those commands > would be useful. I would strongly advise against SMB over the public Internet. VPN may work, also you can use SMB within the firewalls of your organization. Basically you're sidestepping the requirement to provide a web interface to file management and editing, which is fine. Just, like I said above, remember that not only do you have to have file management/editing and access to Fossil commands, but you also need to be able to build and test whatever is being developed. The requirements snowball the more you think about them. > But this could also be useful even when running fossil alone on a > local desktop machine. Kind of like when you run “fossil ui” and up > pops a web interface to the fossil repo on the local machine. Still > edit the files with vi, etc, but the fossil UI basically accesses the > DB right now…it doesn’t touch any checked out dir trees or provide any > way to use the UI to do stuff on them…. Okay, now we're agreeing on something. The web interface has limited cognizance of the checkout in which it is being run. It can highlight whichever check-in is currently checked out, and (quite important to me right now) /doc can serve the "ckout" version for instant feedback on my markup, etc. More checkout-sensitive capability would be nice. The examples I gave before are diffing the checkout and managing the stash. Yet, diffing is a strictly read-only operation, and managing the stash is likely either read-only or doesn't affect the checkout files. Providing web-driven manipulation of the checkout is a big step, one I'm not opposed to, but one I don't think we've ever considered. > which is what I wish it could..then it could be a fairly platform > independent checkout GUI….including over to headless linux boxes that > might have a check out there also. Headless Linux boxes have never been a problem for most folks because of SSH, X11, VNC, etc. Platform-independent GUIs however, that is an attractive concept. It's one we already enjoy in many respects, so why not more, huh? > Ultimately I guess I will have to roll out my own, as I don’t think > anything exists and I doubt there is much interest. Is there a reason why your developers can't clone their own repositories onto their own machines and do their work there in the environment that's most comfortable for them? If you need a shared server because everyone runs Windows at their desk yet development must
[fossil-users] Manifest command and ambiguous names
I'd be interested in having a command to get the manifest of a check-in. The artifact command comes up short when the check-in happens to have a delta manifest. I wrote a Tcl script to combine a delta manifest with its baseline, but I think it would be preferable to expose this capability already available inside Fossil. The trouble is the obvious choice of name for this command would be "fossil manifest", yet "manifest" is already the name of a setting. [f74f7014] combined the settings with the commands and web pages in the aCommand table. Should we add a manifest command, there would be two entries with the same name. I recently modified dispatch_name_search() to tolerate prefixes being shared between entries of different types. I can modify it further to tolerate different-type entries having the same names outright. However, there's still trouble when eType is CMDFLAG_ANY, i.e. when dispatch_name_search() is called by help_page() or help_cmd(). What to do? I could give up and continue to use my Tcl script, I could contribute my Tcl script for others to use, we could call the command that prints a manifest something other than "manifest", or we could add an alternative to dispatch_name_search() that can return more than one result. In that last case, "fossil help manifest" would print help for both the command and the setting. Thoughts? -- Andy Goth | ___ 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] web UI for a working checkout?
On 09/30/17 13:34, Andy Bradford wrote: Thus said Steve Schow on Fri, 29 Sep 2017 15:43:38 -0600: Who is hosting that and what is the longevity compared to github and others? Longevity on the Internet seems to be an often nebulous thing. How long was Google Code (code.google.com) around? How long did Source Forge last before people started ditching it? The nice thing about chiselapp.com is that it's really just Fossil. If chiselapp.com dies, you still have your source (assuming you clone and sync with chiselapp.com frequently) and it wouldn't take much to find a new host to put it on. One of the goals of Fossil was to transcend the problem of depending on the survival and continued interest of others by producing an enduring file format that can outlast any particular developer, software package, hosting service, or even database system. At heart, your Fossil repository is what you see when you do a deconstruct: a collection of artifacts, named by their checksums, tied together by manifests and other structural artifacts. The Fossil code base, the SQLite database, the Fossil web site, the Fossil developers, and the Fossil community exist to support this format, but should all these disappear, both your development history and your development future are safe. -- Andy Goth | ___ 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 and Emacs
On 10/01/17 07:07, Paul Onions wrote: https://chiselapp.com/user/venks/repository/emacs-fossil > So now I'm wondering, is this project actively maintained anymore? Try contacting avanv...@pragmatic-c.com. That's the only email address I could find amongst any of the repositories owned by the same user as emacs-fossil. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] enhanced-symlink branch
Please review the enhanced-symlink branch. I can't test it properly this weekend because I don't have Windows anywhere at home. On Monday I will give it another look, but perhaps before then someone else can try it out and share feedback. I'd like to get this merged into trunk and included in the next Fossil release, provided there are no objections. This branch adds a new "l" flag to the manifest setting. When specified, the "l" flag causes a new manifest.symlinks file to be created which lists all files which are symlinks. On Unix, that's the whole story, nothing more to say. On Windows, this new file can be edited to change which files are and are not considered to be symlinks. Thus, it becomes possible to create and unlink symlinks on Windows. I need this for a project that requires symlinks yet also needs to work in Windows. To make Fossil-style symlinks work in Windows, the few parts of my code that directly care about symlinks check a file I create in Linux that lists all the symlinks. Everything listed in that file is treated as Fossil-style symlinks, meaning that they are virtually replaced by whatever files or directories named within. To avoid having to keep this symlink file up-to-date, I would prefer that Fossil generate it for me the same way it generates its other manifest files. To enable me to actually change my symlinks while doing Windows development, I want this file to be read back in by "fossil changes" and "fossil commit", after having potentially been edited. None of this has any effect if the "l" flag is not set in the manifest setting. The effects of the "l" flag are also temporarily inhibited should the manifest.symlinks file be missing, though it will be regenerated after an update or a commit. If the manifest setting's value is "1" (one) not "l" (ell), the manifest.symlinks file is disabled. -- Andy Goth | ___ 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] enhanced-symlink branch
On 10/14/2017 5:16 PM, Andy Goth wrote: > Please review the enhanced-symlink branch. I can't test it properly > this weekend because I don't have Windows anywhere at home. Tested on Windows 7, works just the way my project needs it to work. The manifest.symlinks file is created when the "l" flag is present in the manifest setting. On Windows (not Unix), its contents determine what files are and are not considered to be symlinks. Editing the file influences the changes, status, and commit commands. I'd like to merge enhanced-symlink to trunk, but honestly I am afraid to just do so even though it passes all my tests because there's been zero mailing list discussion, aside from talking about Windows symlink functionality present on other branches which were themselves never merged to trunk. I still do not know my original change was moved off trunk. It didn't break compatibility, and it did provide a significant part of the needed functionality: listing symlinks in a way I can see them in Windows, short of parsing the manifest (another question I asked about that never got any replies on the mailing list). I asked for clarification for my code being moved off trunk but never got any. Now I see my most recent trunk check-in has also been moved off trunk, despite also not being a compatibility issue, with no explanation to either mailing list, my private email, or the check-in comment. I'm talking about http://fossil-scm.org/index.html/info/eb4dda482056b1db. Was there some policy change about committing to trunk that I missed out on? Before I spend any more time working on Fossil I need to know that I'm not doing something unwelcome. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] enhanced-symlink branch
Warning: beware of back references in this email. Plan to read this email twice. I guess I could have reorganized it, but I left Warren Young's text in its original order. On 10/16/2017 4:28 PM, Warren Young wrote: > On Oct 14, 2017, at 4:16 PM, Andy Goth wrote: >> Please review the enhanced-symlink branch. > > Aside from a manifest.symlinks file appearing at the project root, > what should we see? How do we test it? On Unix, the existence of the file is 100% the only thing you will see. On Windows, the file not only exists but also can be edited to change which files are and are not symlinks. Use the changes command to immediately see the effects of editing the file, or use the commit command to actually, well, commit. Or use commit -n to dry run creating the new manifest without actually changing the repository. Deleting manifest.symlinks temporarily disables its behavior, and Fossil will fall back on its normal behavior of inheriting the symlink status from the baseline check-in. I say "temporarily" because there are a great many actions that will regenerate manifest.symlinks, along with all the other manifest* files, for example committing. > For example, if I declare a file to be a symlink in the repository by > editing that file, what is supposed to happen on “fossil up”? I think "fossil up" will blow away edits to manifest.symlinks. That's arguably a bug, and thanks for bringing it to my attention. It would make more sense to preserve edits (or more precisely, the consequence of edits) to manifest.symlinks unless the user is expressly reverting them. > What if the so-named file is already under management? In this case, the file would become a symlink to whatever its content says it's a link to. All that's happening is the "l" permission flag is being added to the manifest. > I ask for the benefit of others, not myself, because in the uncommon > instances where I run Fossil on Windows, it’s almost always under > Cygwin or WSL. In the exceedingly rare exceptions, I use one of the > official binaries; I’ve never built a non-Cygwin fossil.exe. I don't have the luxury of Cygwin because my end users won't have it. It's already like pulling teeth (don't get me started) to get them to allow fossil.exe to be on the install CD even though it itself isn't being installed. It just needs to be there to support read-only browsing of the documentation and the revision history. Adding cygwin1.dll or whatever it's called will totally destroy the already strained relationship I have with them. I do not understand why this is such a massive issue, especially since they refuse to have a rational discussion about their concerns with me, but superstition rules the day. You may be asking why I care about symlinks in the scenario I outlined. It's because I want that same install CD to be useful to the real developers, who should also be able to run the build procedure to get fresh binaries including any changes they may be making. Thanks to the magic of SDX and Starpacks, I was able to sneak the "compiler" onto the CD since it's right inside the repository! > I did go ahead and build your branch on Linux and under Cygwin, and > all I was able to see is that “fossil set manifest l” caused the > manifest.symlinks file to appear, and “fossil unset manifest” made it > disappear. That's a very good start, thanks. I didn't even do Cygwin testing. I only tested using the Windows build procedure drh gave a month or two ago when I asked about it. >> On Windows, this new file can be edited to change which files are and >> are not considered to be symlinks. Thus, it becomes possible to >> create and unlink symlinks on Windows. > > If all this branch did is gave Fossil the power to declare where the > symlinks are, I’d say it’s probably a harmless change. > > The fact that manually adjusting the manifest apparently changes > Fossil’s behavior worries me. It feels like reinventing part of Unix, > poorly. "Reinventing part of Unix, poorly." Haha, you do realize we are talking exclusively about Windows, right? So YES you are correct. Just let me emphasize that I'm not the one doing the reinventing. > It also feels like reversing a causality arrow: shouldn’t manifests > merely declare separately-verifiable facts? You can’t change the > contents of a cargo container by rewriting its manifest; why do you > call your file a manifest if it doesn’t behave the same way? You raise an interesting point. An alternative to editing the checkout copy of manifest.symlinks would be defining a new "fossil symlink" command. However, it would have the same effect. In order to work with my application, all "fossil symlink" would do is edit the manifest.symlinks file
Re: [fossil-users] enhanced-symlink branch
On 10/16/2017 5:44 PM, Arseniy Terekhin wrote: > I want to share my thought about symlinking in fossil. > > dir "my_empy_dir" > dir "my_empy_dir2" > ln "existing_file_in_repo" "new_link" > ln_hard "existing_directory_in_repo" "new_hard_link" > attr_executable "bin/*.sh" > attr_hidden "*.cab" > > That setting can be applied whenever "empty-dirs" is currently applied. Everything you suggest can be placed in a makefile or other such script, no need to change Fossil to handle it. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ 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] enhanced-symlink branch
On 10/16/17 21:13, Warren Young wrote: On Oct 16, 2017, at 7:28 PM, Andy Goth wrote: I don't have the luxury of Cygwin because my end users won't have it. You can just distribute the DLL, then. The two programs that would need Cygwin are Fossil itself and my application. My application is written in Tcl and is bundled into a Starpack using a precompiled basekit. Said basekit is used both as the interpreter stub (placed inside the Starpack) and the standalone interpreter used to run the build script that actually creates the first Starpack. Only in the second role does it actually need to know anything about symlinks because they are used to define the layout of the Starpack virtual filesystem. Should I get a custom Cygwin-capable basekit, I'd be adding a dependency on Cygwin that complicates my install procedure without providing any runtime benefit. Or I could have two basekits, but that gives me an extra multi-megabyte blob providing no capability over and above what I have right now. Let me say that again. What I have works right now, and it's been working ever since the early days of my project. I see zero reason to incorporate Cygwin simply to avoid having to use the existing Fossil emulation of symlinks which already works fine for me. I'm curious, how far back does the Cygwin DLL work? I need to support all the way back to Windows 2000. Actually there's one Windows 98 system, but until they fix the network on it I can't support it anyway. Going the other direction, I think the newest system I have to support is Windows 7, although I do test on Windows 8.1. It's already like pulling teeth (don't get me started) to get them to allow fossil.exe to be on the install CD You can have an EXE but not a DLL linked to that EXE? I suppose dynamic linkage does increase the attack surface area, but it’s a pretty thin argument. The end user is simultaneously paranoid about security and ignorant about security. Please don't get me started. The whole reason I was given this project was to deal with this fact, and thus the slightest thing I do that they perceive as complicated (even if you and I know it's not) will cause me to fail in my task because they decline to adopt my solution and instead persist in manually doing the things that got them in trouble in the first place, and we are being held responsible for the consequences of their actions. It's not a happy situation. Let's not discuss it further. I'm not the one doing the reinventing. Except you are: there are at least 4 other existing implementations of symlinks for Windows, and you’ve just built a fifth. No I'm not. Fossil symlinks in Windows have always been ordinary files containing the names of their targets. That wasn't me. I'm merely exploiting this longstanding behavior because it's straightforward and does what I need. No, the current behavior for native Windows Fossil is to create ordinary files containing the name of their target (no trailing newline). I see why people keep trying to fix the problem, then. Right, it's fiddly and takes great care to use properly. Changing it is far outside the scope of my current effort. Others have already put forward alternatives on branches, but I'm not using them. I'm sticking with the bog-standard Fossil trunk here. I'm already taking heat for using Fossil in the first place, even though the alternative CM system I'm expected to use flat out doesn't work in the required development environment. For me to not only use Fossil but also some odd branch thereof would really push everyone over the edge. My work is focused on reflecting the list of symlinks back into the filesystem in the form of a manifest file. Granted, I could also have rewritten my code to parse the manifest file actually named "manifest" (not manifest.*) to find every line with the "l" permission, but I already wrote my application to read a newline-delimited list of filenames that does nothing more than list the symlinks, so I went with that simple format. Native Windows EXEs can call Cygwin EXEs, and vice versa. If the Tcl code doesn’t need to follow Fossil-created symlinks, Tcl needn’t be built under Cygwin. The Tcl code does need to follow the symlinks. The part of it that actually gets exposed to symlinks, I wrote to first look aside at the symlink list file so it knows which files to treat as such. Had I used Cygwin Fossil and Cygwin Tcl, that would all have been handled for me, at the cost of adding a runtime dependency on Cygwin and needing custom binaries of both that I can't be sure will work on all the required platforms, with a benefit experienced only during the Starpack build process that only developers will do. Though if you wanted, the Cygwin package repository should have a wide variety of Tcl stuff. Not the Starpac
[fossil-users] Fwd: Re: Fossil README symlink
I received this email from Matias Fonzo in reply to a message I sent him earlier today. With his permission, I am forwarding it to the list. The bottom line is that the requiring JavaScript access has proven to be fatal for his project's usage of Fossil. Forwarded Message Subject: Re: Fossil README symlink Date: Tue, 17 Oct 2017 21:49:35 -0300 From: Matias Fonzo Organization: Dragora GNU/Linux-Libre To: Andy Goth Hello Andy, I'm happy that you (a developer of Fossil) wrote me. Also, glad to see that you solved the symlink issue, but i am afraid that is too late for us to continue using Fossil. We migrated to Git[1] (again): [1] http://git.savannah.nongnu.org/cgit/dragora.git/ This was our previous home prior to switch to Fossil. Fossil is a great software and I consider it better than Git. The problem is the Javascript code to avoid the spam, and some people reported that they can not enter to the Dragora's website, which is a problem for me[2]. [2] https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg25230.html On Tue, 17 Oct 2017 10:33:13 -0500 Andy Goth wrote: > I see your README file at the top level is a symlink. This causes > "www/overview.md" (the filename, not the contents) to be shown when > browsing the top level directory in the /dir or /tree Fossil web > pages. > > You might want to have a look at the doc-symlink branch of Fossil. > In it I add support for README files being symlinks. > > http://fossil-scm.org/index.html/timeline?r=doc-symlink > > Please let me know your thoughts on this feature, also if you are > okay with me sharing them with the Fossil mailing list. > signature.asc Description: OpenPGP digital signature ___ 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] enhanced-symlink branch
On 10/18/17 08:42, Florian Balmer wrote: Handling Windows Shell Links (*.lnk) can be tricky: Off-topic, but does anyone know a good way to create *.lnk files from Tcl? The only way I've found is to use DDE to create start menu shortcuts, then move those shortcut files to wherever I need them, because they are in fact *.lnk files. This has some serious drawbacks, but again, it's the only way I've found to make *.lnk files at all. Because off-topic, please consider replying to me privately. -- Andy Goth | ___ 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] Content-Security-Policy Was: Fossil README symlink
On 10/18/17 09:46, Warren Young wrote: On Oct 18, 2017, at 8:27 AM, Warren Young wrote: On Oct 18, 2017, at 7:04 AM, Richard Hipp wrote: I'll have to add a "/fossil.js” resource While you’re about it, I’d suggest shipping /fossil-$hash.js instead and setting a multi-year Expires header for the file so that it only has to be pulled once and cached “forever”. $hash is the current Fossil checkin prefix, the same one reported by “fossil ver”. Thus, whenever Fossil changes, the file name changes, so the browser will pull the fossil.js file again. +1 to this idea. Ditto style.css, though the ability to change the CSS via Fossil UI complicates this. Currently, that gets pulled on every page load, even though it almost never changes. +0.98 to this idea. I'll contribute the remaining two cents by suggesting style-$hash2.css where $hash2 is a hash (or prefix thereof) of the contents of style.css, possibly combined with the Fossil checkin prefix. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fwd: Re: Fossil README symlink
More from Dragora about JavaScript. The part that's most interesting to me is they're not using Github. -- Forwarded message -- From: "Matias Fonzo" Date: Oct 18, 2017 13:26 Subject: Re: Fossil README symlink To: "Andy Goth" Cc: Hi Andy, On Wed, 18 Oct 2017 09:48:44 -0500 Andy Goth wrote: > > Here's the origin of the rest of the thread, if you wish to see: > > [..] Thanks. > > I think this is a good thing. Thank you for helping to get this ball > rolling. Hopefully it will bear fruit, even if it's not precisely > what you were asking for. > No problem. Two things, the report of the people is not about the login page only. They can't see some of the pages, cannot remember exactly those, but i think it was about the content, and the Timeline. I've followed the suggestions to try to avoid Javascript, but without luck. Probably is my bad interpretation, but we are not in Github (just in case, to make it clear). Currently, we have a mirror[1] in notabug.org (which is an alternative to Github). [1] http://notabug.org/dragora Best regards, Matías ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Incorrect arrow colors when using -bgcolor
When a custom bgcolor is set for a check-in, the arrow color coming out of the check-in is incorrect. In my test case, the outbound arrows are white, which doesn't look so great against the default white background. f new test.fossil mkdir test cd test f open ../test.fossil touch file f add file f commit -m 1 -bgcolor '#00aa00' echo moo > file f commit -m 2 -bgcolor '#00aa00' echo moo2 > file f commit -m 3 f ui -- Andy Goth | ___ 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] Incorrect arrow colors when using -bgcolor
On 06/06/18 19:46, Richard Hipp wrote: On 6/6/18, Andy Goth wrote: When a custom bgcolor is set for a check-in, the arrow color coming out of the check-in is incorrect. In my test case, the outbound arrows are white, which doesn't look so great against the default white background. Fixed on trunk Thank you for the quick turnaround! Fix confirmed good. -- Andy Goth | ___ 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] Show time...
On 06/06/18 20:26, Eduard wrote: I might enable public registration 'soon'. Now all I need is a catchy name, like `chiselapp` :p There are plenty of fossil terms to choose from, for example archaeo. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Attachment policy
What is the file attachment policy for this mailing list? I couldn't find it documented anywhere. It doesn't help that when I search the list for "attachment" I find so much about ticket attachments. May I attach plain text files? Binary files? What are the size limits? I have an 8.7 kilobyte binary file I'd like to attach (xz -9 compressed test repository), as well as an image file because I'm at a loss to describe what I'm seeing in the timeline. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Stray up arrow in timeline
While investigating a difficult-to-reproduce problem with rebuilds (to be discussed in a separate email if I ever come up with a procedure), I managed to get another problem. My timeline now has a stray up arrow coming off the check-in that comes "after" the one for which I amended the time. In the full timeline, the arrow goes upward toward infinity. It does not show in the context/family timelines, only the full timeline. I say "after" in quotes because the one I amended used to have a date before its successor but now has a date slightly after its successor, that successor being the one with the stray up arrow. In the end, I have two check-ins in a row that have dates preceding their predecessors. (My dates are squirrelly on purpose; that's not the point.) I'd like to post the repository but am asking permission first in a separate email because it's a binary file. Tiny though it may be, attachments often don't go well with mailing lists, particularly not binary attachments. Naturally, I can send it to anyone who requests it, if anyone's curious and can't wait for me to get the official nod. -- Andy Goth | ___ 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] Attachment policy
On 06/06/18 21:53, jungle Boogie wrote: Seeing that you have a Gmail account, you could upload to Google drive and make public. Then provide the link via email to that file. I'll do that for now, pending direction to attach to email or do anything else. Ideally the file would not be in separate storage from the email, but the way email attachments work sucks in general, so if we can't achieve this ideal, I understand. -- Andy Goth | ___ 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] Stray up arrow in timeline
On 06/06/18 20:58, Andy Goth wrote: While investigating a difficult-to-reproduce problem with rebuilds (to be discussed in a separate email if I ever come up with a procedure), I managed to get another problem. My timeline now has a stray up arrow coming off the check-in that comes "after" the one for which I amended the time. In the full timeline, the arrow goes upward toward infinity. It does not show in the context/family timelines, only the full timeline. Here is the procedure I followed, with timestamps: # Date: 2018-06-06 # Time zone: -0500 20:40:53 f new uparrow.fossil 20:40:54 mkdir test 20:40:55 cd test 20:40:59 f open ../uparrow.fossil 20:41:23 f commit -m 1 -tag 1 -allow-empty 20:41:26 f info 1 20:41:49 f commit -m 2 -tag 2 -allow-empty -allow-older -date-override 2018-01-01 20:41:56 f commit -m 3 -tag 3 -allow-empty 20:42:04 f commit -m 4 -tag 4 -allow-empty -allow-older -date-override 2017-01-01 20:42:08 f commit -m 5 -tag 5 -allow-empty 20:42:13 f commit -m 6 -tag 6 -allow-empty -allow-older -date-override 2016-01-01 20:42:17 f commit -m 7 -tag 7 -allow-empty 20:42:23 f commit -m 8 -tag 8 -allow-empty -allow-older -date-override 2015-01-01 20:42:27 f commit -m 9 -tag 9 -allow-empty 20:42:34 f commit -m 10 -tag 10 -allow-empty -allow-older -date-override 2014-01-01 20:42:38 f commit -m 11 -tag 11 -allow-empty 20:43:27 f rebuild 20:44:16 f amend -date 2018-06-07T01:42 2 I doubt that rebuild has anything to do with it, but nevertheless it's there in my shell history. I'd like to post the repository https://drive.google.com/open?id=1hCAqmgYxO30gF-mYeQsgP2HLIl6gC11A -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Compressed >>> uncompressed size
In a couple of my repositories (sorry, I can't share them), /artifact_stats shows artifact compressed sizes far larger than uncompressed sizes. For example, in the one I'm looking at right now, the ALL uncompressed size is 188,230,318, but the compressed size is: 262,107,865,366,396,928 That's a compression ratio of 139,248,484,596.619%. My tag uncompressed size is 13,628, versus the compressed size: 50,281,182,134,272 With a ratio of 368,954,961,360.9627%. That's even worse! I have a good mix of full-text and delta artifacts. Unsurprisingly, tag and cluster have zero delta artifacts, whereas manifest has 10:1 delta to full-text and file has 6:5 delta to full-text. Tested using fossil version 2.6 [7ac88481a6] 2018-06-07 00:45:54 UTC, plus I saw it in 2.5. -- Andy Goth | ___ 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] Compressed >>> uncompressed size
On 06/07/18 08:51, Richard Hipp wrote: On 6/7/18, Andy Goth wrote: In a couple of my repositories (sorry, I can't share them), /artifact_stats shows artifact compressed sizes far larger than uncompressed sizes. Can you send the HTML generated by /artifact_stats? Sure, though with some redactions. May I attach it to my email? -- Andy Goth | ___ 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] Compressed >>> uncompressed size
On 06/07/18 14:00, Andy Goth wrote: On 06/07/18 08:51, Richard Hipp wrote: On 6/7/18, Andy Goth wrote: In a couple of my repositories (sorry, I can't share them), /artifact_stats shows artifact compressed sizes far larger than uncompressed sizes. Can you send the HTML generated by /artifact_stats? Sure, though with some redactions. May I attach it to my email? I'm sorry, I can't wait any longer. I gotta run to somewhere else and won't have access to email. I've asked three times about attachments and haven't gotten an answer, so I'm just going to go ahead and attach the file. If it works, great. If not, well, hopefully it won't break digests and archives and all that. -- Andy Goth | Title: REDACTED: Artifact Statistics REDACTEDArtifact Statistics REDACTED â Logout Home Timeline Download Code Docs Branches Tags Site Map Admin Help Artifact List Repository Stats Overall Artifact Size Statistics: Number of artifacts:5,539 Number of deltas:3,336 (60%) Number of full-text:2,203 (39%) Uncompressed artifact sizes:largest: 5,913,941, average: 33,982, median: 7,168 Compressed artifact sizes:largest: 3,836,467, average: 11,017, median: 228 Delta artifact sizes:largest: 2,435,585, average: 5,384, median: 154 Full-text artifact sizes: largest: 3,836,467, average: 19,547, median: 1,904 Artifact size distribution facts: The largest 0.18% of artifacts (the largest 10 artifacts) use 50% of the total artifact space. The largest 1% of artifacts (the largest 56 artifacts) use 83% of the total artifact space. The largest 10% of artifacts (the largest 554 artifacts) use 94% of the total artifact space. The largest 25% of artifacts (the largest 1,108 artifacts) use 97% of the total artifact space. The largest 50% of artifacts (the largest 2,770 artifacts) use 99% of the total artifact space. Artifact Sizes By Type: Artifact Type Count Full-Text Delta Compressed Size Uncompressed Size tag 86 86 0 50,281,182,134,272 13,628 cluster 55 55 0 630,561,328,594,944 259,433 manifest 1,261 185 1,076 24,307,088,238,837,760 61,165,438 file 4,137 1,877 2,260 237,119,934,616,829,952 126,791,819 ALL 5,539 2,203 3,336 262,107,865,366,396,928 188,230,318 This page was generated in about 0.116s by Fossil 2.6 [7ac88481a6] 2018-06-07 00:45:54 ___ 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] Compressed >>> uncompressed size
32-bit Linux, no custom modifications, Fossil version e80667191a, self-compiled, ok. 5913941|3836467 5800401|3765158 3670410|3369067 3957878|3035526 3952468|3029402 3951235|2969330 3923360|2946572 4234202|2663321 5772779|2435585 3459064|2370320 I count 243 rows where length(content)>size, and max(length(content)-size) is 20. On Thu, Jun 7, 2018, 14:40 Richard Hipp wrote: > On 6/7/18, Andy Goth wrote: > > > > I'm just going to go ahead and attach > > the file. > > Very peculiar output. What platform is this running on? Have you > made any modifications? Did you compile Fossil yourself? > > Try this: > > fossil sql "pragma integrity_check" > > If that returns "ok", then try this: > > fossil sql "select size, length(content) from blob order by 2 desc > limit 10" > > > -- > 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 > ___ 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] style.css served with on settings conflict
On 06/07/18 19:55, Warren Young wrote: The error prepended to web pages served by Fossil on settings conflicts is being prepended to the style.css file, causing the CSS to be considered invalid by Chrome, at least. This should be done on HTML output only. I had this same problem back when we were having trouble with read-only repositories on Windows. Richard fixed it by reworking how SQLite deals with Windows virus scanners lying about file access, but we never actually changed the error logger. In the case of CSS, errors can still be reported, but they have to be made to look like comments. Text prepended to HTML tends to be tolerated as-is though, so only CSS needs a fix. Trouble is, how does the error logger know that its output will wind up inside CSS? -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil SlackBuild script
I just submitted an update to the Fossil SlackBuild script. Sorry, I haven't done this since version 2.3, and now we're on 2.6. I took the opportunity to update the README file with a few new bullet points and features. Here it is, pasted inline: Fossil is a distributed version control and ticket tracking system created by D. Richard Hipp, the primary author of SQLite. Features: - tamper-proof artifact record - simple command-line interface - customizable web interface with JSON, RSS, and built-in wiki - online project documentation with full-text search capability - online activity and ticket reports - user accounts with access controls - coherent versioning across all files - straightforward branching and merging - bisect searches to pinpoint behavior changes - SHA3-256 and hardened SHA1 checksums - FUSE filesystem makes all historical and branch revisions available - synchronization via http, https, ssh, and local/network filesystems - automated replication and backup - git import/export and Subversion/CVS import - nested checkouts to share common subtrees across related projects - checkout directory not cluttered with administrative files - support for Docker - unversioned file area for builds, statistics, other ephemeral content - optional PGP signing of commits - private branch which are excluded from syncs until published - bundles group a change set (e.g. a private branch) into a single file - users can make their own repositories, no need for special privileges - works in Windows as well as Linux and other Unix-like systems Fossil can host the entire project development website, including the download area, but it also can be used for individual projects with no need for a shared server. In addition to typical software development operations, one interesting application is coordination and auditing of /etc and other configuration files across a network of computers. Content is stored in an SQLite database for atomicity, durability, and effortless administration. See Fossil in action online: - https://fossil-scm.org/ - Fossil hosts its own development - https://sqlite.org/src/ - Fossil originally created to manage SQLite - https://core.tcl.tk/tcl/timeline?y=ci - Tcl/Tk migrated from CVS - https://chiselapp.com/ - Free public hosting for Fossil projects Key technical points: - unified revision history tree spans the entire repository - repository is a collection of artifacts identified by their checksums - artifacts are broadly grouped into content and structural artifacts - each check-in is tracked as a structural artifact known as a manifest - manifests primarily list the full names and checksums of each file - manifests can be amended by subsequent control artifacts - in most cases, symbolic names refer to the latest matching check-in - branches are implemented using propagating symbolic tags -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Amendments don't always survive rebuilds
Some amendments don't consistently survive rebuilds and syncs. I've noticed this with date changes and reparenting. Possibly it affects other types of amendments as well, but those are the two I've spotted. This has been plaguing me for years, but finally I have a repeatable test case. Repository before rebuild: https://drive.google.com/open?id=1-Ahs91NVigBX7uMk88wIBjClQj1yxGnm Repository after rebuild: https://drive.google.com/open?id=1CFzc9JyNQ5piSIO4YUqjSpqmmjPxmCsg I constructed a repository full of time warps, much like in my previous email about the stray riser. Then I used a bunch of amendments to straighten everything out. But once I rebuilt, the dates got jumbled again, and not in the same configuration as when I started. Some amendments survived, others didn't. Here are the commands I used to create the repository: f new test.fossil -admin-user username -date-override 2018-05-31 mkdir test cd test f open ../test.fossil f user default username id=1; for day in 15 13 16 12 17 11 18 10 19 09 20 08 21 07 22 06 23 05 24 04 25 03 26 02 27 01; do f commit -f -m "$id" -tag "$id" -date-override "2018-06-$day"; ((++id)); done for id in $(seq 1 26); do f amend -date "$(printf 2018-06-%02d "$id")" "$id"; done And then, to mess it up again: f rebuild I could also have sync'ed to another repository, but here I'm just showing the simplest way I know to trigger the problem. I wonder if the order in which artifacts are visited is impacting the outcome. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] SlackBuilds.org GitHub repository and DMCA Takedown notice
A few days ago, SBo and over 200 other repositories in GitHub were hit with a DMCA Takedown notice due to having a couple header files from Steinberg Media Technologies. There's a lot to say about that, particularly if you're into computer music synthesis, but I don't think this mailing list is the appropriate forum to discuss Steinberg's action. Instead I want to discuss the technical means by which any of the affected projects would comply with the takedown, had they been using Fossil. Quote from the SBo blog post: "The admins have discussed this matter last night and we came to a solution of fixing this issue permanently by removing the related commit and all the history for this script in master and 14.2 branch. This is not a trivial action as the commits involved were 11867 since 2017-02-04. Ponce did the initial testing and David did the final touch, including pushing an unexpected public update including with the mass re-base on master and 14.2 branch (Thanks David)." The post goes on to include a sequence of commands to be followed by everyone downstream to surgically fix their local clone of the SBo repository. "[A] simpler way is to re-clone our repository using git clone." Am I correct in my understanding that all a Fossil repository need do is issue shun artifacts for each file in the takedown notice? If the files had multiple versions (they didn't in this case), shun each version of them too, right? This would result in the file vanishing from every repository clone upon the next sync, though its name and checksum would remain in manifests. Any code #include'ing the header files (in this case) would fail to compile, on account of the missing file, so it would no longer be possible to recompile historical check-ins, not without creating a compatible replacement for the shunned files. Here's the original blog post I found: https://slackblogs.blogspot.com/2018/06/sbo-dmca-takedown.html For your curiosity, here's Google's cache of one of the affected files, but I'm sure Google will take it down too, so look quick. Right now, the important part is the comment "© 2006, Steinberg Media Technologies, All Rights Reserved". https://webcache.googleusercontent.com/search?q=cache:X4F7NEfgUlkJ:https://github.com/aardvarkk/soundfind/blob/master/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h+&cd=1&hl=en&ct=clnk&gl=us&client=firefox-b-1 -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Reparent problems
Even with the latest Fossil, I'm continuing to have problems with reparent. I'm also continuing to fail to produce a repeatable test case or even a repository I can share without endangering my livelihood. I've been trying for a couple years now, ever since reparent was first introduced. One would think a problem would be more likely to show itself in a stress test than in casual use, but here it's the opposite. A real Heisenbug. Today I resigned myself to the notion that I have to debug it on my own. I did find something, but I'm not sure it's even the issue I started out looking for, same as occurred recently for two issues with changing dates. I'm getting missing events in the database following rebuild or reconstruct, but the manifests and plinks and mlinks are all there. This results in holes in the timeline. I'm guessing the culprit is the test to only create the check-in event if there are no mlinks yet. Depending on artifact visitation order, this assumption might not work out too well. If the reparent tag is handled before the original check-in, will its event be created? ___ 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] Reparent problems
I tested a bit more by bypassing the mlink existence check for the artifacts I know to be affected. This resulted in the events being created but the reparents being ineffective. Artificial conditions, I know, but this reproduces the symptoms of my original problem. It looks like there are three cases: 1. Manifest artifact is visited first, at which point its event is created. Reparent tag artifact is visited later, successfully updating the plink table. All is well. 2. Reparent tag artifact is visited first, and mlink and plink are updated, but no event is created. Manifest artifact is visited later, but since it's already in mlink, no event is created. Check-in is not visible in the tree. 3. Reparent tag artifact is visited first, and plink are updated, but no event is created. Since there happen to be no (changed?) files, no mlink is created. Manifest artifact is visited later, and since there's no mlink, the event is created. However, the plink table is updated using only the P card in the original manifest, undoing the reparent tag. Check-in is visible in the tree but has the wrong parent. On Wed, Jun 20, 2018, 21:38 Andy Goth wrote: > Even with the latest Fossil, I'm continuing to have problems with > reparent. I'm also continuing to fail to produce a repeatable test case or > even a repository I can share without endangering my livelihood. I've been > trying for a couple years now, ever since reparent was first introduced. > One would think a problem would be more likely to show itself in a stress > test than in casual use, but here it's the opposite. A real Heisenbug. > > Today I resigned myself to the notion that I have to debug it on my own. I > did find something, but I'm not sure it's even the issue I started out > looking for, same as occurred recently for two issues with changing dates. > > I'm getting missing events in the database following rebuild or > reconstruct, but the manifests and plinks and mlinks are all there. This > results in holes in the timeline. I'm guessing the culprit is the test to > only create the check-in event if there are no mlinks yet. Depending on > artifact visitation order, this assumption might not work out too well. If > the reparent tag is handled before the original check-in, will its event be > created? > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
