[fossil-users] Fossil tarball URL
I'm experimenting with downloading specific versions of Fossil via its /tarball/ mechanism, but no matter what URL I use, I always get the current trunk. Here are a few I've tried: http://www.fossil-scm.org/fossil/tarball?ci=version-1.27 http://www.fossil-scm.org/fossil/tarball/version-1.27.tar.gz http://www.fossil-scm.org/fossil/tarball/13ad13092060dfb995404ca354aa4e458d66fdbf.tar.gz Changing the name of the final URL component only succeeds in changing the name of the directory into which the archive unpacks. The VERSION file contains 1.28 every time. tar.c appears to try to convert the filename (sans .tar.gz) to an RID (I assume that means aRtifact ID), but this doesn't seem to be working. Or it could be that I'm not specifying the name right. An example would be helpful. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil stash does not play well with fossil mv
On 3/17/2014 10:36 PM, Andy Goth wrote: The fossil stash command does not seem to understand fossil mv. When a stash is restored, the files are given their old names. Problem still exists in Fossil version 684eb478e7. Created ticket 99bca9b4d8ddc3ba9925dcd664df6da922a1439f to track problem. See http://www.fossil-scm.org/index.html/tktview/99bca9b4d8ddc3ba9925dcd664df6da922a1439f -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Files and directories in flat view
At present, the only way to distinguish between files and directories in flat view is to check whether their link URL goes to dir or finfo. Directories appear to be grouped first, but there's still no easy way to tell where directories and files begin. As is done with tree view, I suggest replacing the bullets with file and folder icons. Additionally, this would help with the case of a file and a directory having the same name, which can happen when showing the union of all check-ins: show the name twice, once with and once without the slash, linking to the directory and file information, respectively. At present, the current behavior is to show the name twice, like I suggest, but again it's hard to tell which is which. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] GitHub-style template
On 3/22/2014 7:17 PM, ma...@include-once.org wrote:
Also not sure if the Unicode glyphs show up for everyone, but I'm
reluctant to plaster heaps of /doc/tip/www/icon files into every repo.
Fossil currently implements tree view file and directory icons as data:
URLs embedded in the CSS.
.filetree a {
background-image:
url(data:image/gif;base64,R0lGODlhEAAQAJEAAP///yEhIf///wAAACH5BAEHAAIALAAQABIvlIKpxqcfmgOUvoaqDSCxrEEfF14GqFXImJZsu73wepJzVMNxrtNTj3NATMKhpwAAOw==);
background-position: left center;
background-repeat: no-repeat;
display: inline-block;
min-height: 16px;
padding-left: 21px;
position: relative;
z-index: 1;
}
.filetree .dir a {
background-image:
url(data:image/gif;base64,R0lGODlhEAAQAJEAAP/WVCIiIv///wAAACH5BAEHAAIALAAQABInlI9pwa3XYniCgQtkrAFfLXkiFo1jaXpo+jUs6b5Z/K4siDu5RPUFADs=);
}
--
Andy Goth | andrew.m.goth/at/gmail/dot/com
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Reconstructing a corrupted Fossil repository
The other day I converted a Subversion repository to Fossil via the
script presented at
http://www.fossil-scm.org/index.html/wiki?name=Cookbook#SVN . It mostly
worked, but the imported commits were not on the trunk branch. (By the
way, said Subversion repository did not utilize branching.)
I corrected that by adding propagating tags branch=trunk and sym-trunk.
However, at first I mistakenly put the tags somewhere in the middle of
the timeline, but I remedied this by putting them at the first non-trunk
commit, i.e. the first imported commit.
A day or two later, while dangerously bored, I experimented with
shunning, and I removed the erroneous tag edits in the middle of the
timeline. I'm not 100% sure how, and I haven't succeeded in completely
reproducing the damage with a test repository, but this somehow
fractured the timeline with several commit manifests having P cards
naming nonexistent predecessors. Very bad. Plus this broke the edit
link in the web UI for the affected commits.
I couldn't fix the repository in place without database editing beyond
my comfort level (zero), plus it's (currently...) impossible to generate
manifests having a predetermined SHA1 sum. It would have been okay to
let all the checksums change after the point of my edit, but still it
seemed like too much work.
I exported and reimported the repository using [fossil export] and
[fossil import], but the tree remained fractured. I tried editing the
exported file before reimporting it, but I still couldn't work out how
to make it do what I wanted.
My solution was to transfer the contents of each commit to a new
repository. Since the repository has fewer than 150 commits; no
branches; no special tags, users, or configuration; no tickets, wiki
pages, or events; nothing special at all; and no requirement to preserve
the checksums, this was acceptable. For this repository, the transfer
process takes about four minutes on my computer, almost all of it spent
inside [fossil commit], presumably doing checksums.
The strange thing I do is open two repositories simultaneously within a
single directory, shuffling multiple copies of .fslckout. Then [fossil
update] performs the edits that are committed with [fossil delete],
[fossil add], and [fossil commit], and I use [fossil changes] to see
what needs to be deleted.
Since someone (me?) might find this script useful in the future, perhaps
as the foundation for a more comprehensive database regeneration
procedure, or a for stress test, I'm pasting it below:
#!/usr/bin/env tclsh
set repo1 CORRUPT.fossil
set repo2 REBUILT.fossil
proc fossil {args} {
puts [concat fossil $args]
exec fossil {*}$args
}
set pwd [pwd]
file mkdir tmp
cd tmp
fossil open [file join $pwd $repo1]
foreach line [split [fossil timeline -t ci -n 0 -W 0] \n] {
if {![regexp {^=== (\d{4}-\d\d-\d\d) ===$} $line _ date]
[regexp {(?x)^(\d\d:\d\d:\d\d)\ \[([[:xdigit:]]+)\]
\ (?:\*CURRENT\*\ )?(.*)$}\
$line _ time version comment]} {
lappend history [list $date $time $version $comment]
}
}
set date [clock format [clock add [clock scan $date] -1 day]\
-format %Y-%m-%d]
fossil new --date-override $date 00:00:00 [file join $pwd $repo2]
file rename .fslckout [file join $pwd repo1.fslckout]
fossil open [file join $pwd $repo2]
file rename .fslckout [file join $pwd repo2.fslckout]
foreach checkin [lreverse $history] {
lassign $checkin timestamp version comment
file rename [file join $pwd repo1.fslckout] .fslckout
fossil update $version
file rename .fslckout [file join $pwd repo1.fslckout]
file rename [file join $pwd repo2.fslckout] .fslckout
foreach change [split [fossil changes] \n] {
if {[regexp {^MISSING +(\S.*)$} $change _ name]} {
fossil delete $name
}
}
fossil add .
fossil commit --allow-empty --no-warnings\
--date-override $timestamp --comment $comment
file rename .fslckout [file join $pwd repo2.fslckout]
}
file rename [file join $pwd repo1.fslckout] .fslckout
fossil close
file rename [file join $pwd repo2.fslckout] .fslckout
fossil close
cd $pwd
file delete -force tmp
# vim: set sts=4 sw=4 tw=80 et ft=tcl:
--
Andy Goth | andrew.m.goth/at/gmail/dot/com
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Reconstructing a corrupted Fossil repository
On 3/25/2014 1:06 PM, Stephan Beal wrote: i suspect a re-import from svn is the most expedient route here. I had considered that, but the subversion repository is hard to get to. It's on a private network my laptop cannot directly connect to without the aid of janky security software, then once I've done that, I need to construct a huge tar archive of the repository and manually transfer it from one computer to the next to the next to the next since no one bothered to set up routing. It takes over an hour, and once was enough. But once that was done, I would have to re-import the commits I had done since the initial import, so I'd still be facing my original problem. incrementally check out svn versions, export them to the same fossil checkout dir, use (fossil addremove; fossil ci -m 'revision r'). I didn't know [fossil addremove] existed. That would have eliminated the need for [fossil changes]! How convenient. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Reconstructing a corrupted Fossil repository
On 3/25/2014 1:23 PM, Andy Goth wrote:
I didn't know [fossil addremove] existed. That would have eliminated
the need for [fossil changes]! How convenient.
Here's an updated version of the script that uses [fossil addremove].
It also fixes a bug which included the user and tags in the comments.
#!/usr/bin/env tclsh
set repo1 CORRUPT.fossil
set repo2 REBUILT.fossil
proc fossil {args} {
puts [concat fossil $args]
exec fossil {*}$args
}
set pwd [pwd]
file mkdir tmp
cd tmp
fossil open [file join $pwd $repo1]
foreach line [split [fossil timeline -t ci -n 0 -W 0] \n] {
if {![regexp {^=== (\d{4}-\d\d-\d\d) ===$} $line _ date]
[regexp {(?x)^(\d\d:\d\d:\d\d)\ \[([[:xdigit:]]+)\]
\ (?:\*CURRENT\*\ )?(.*)\ \(user:\ .*\ tags:\ .*\)$}\
$line _ time version comment]} {
lappend history [list $date $time $version $comment]
}
}
set date [clock format [clock add [clock scan $date] -1 day]\
-format %Y-%m-%d]
fossil new --date-override $date 00:00:00 [file join $pwd $repo2]
file rename .fslckout [file join $pwd repo1.fslckout]
fossil open [file join $pwd $repo2]
file rename .fslckout [file join $pwd repo2.fslckout]
foreach checkin [lreverse $history] {
lassign $checkin timestamp version comment
file rename [file join $pwd repo1.fslckout] .fslckout
fossil update $version
file rename .fslckout [file join $pwd repo1.fslckout]
file rename [file join $pwd repo2.fslckout] .fslckout
fossil addremove
fossil commit --allow-empty --no-warnings\
--date-override $timestamp --comment $comment
file rename .fslckout [file join $pwd repo2.fslckout]
}
file rename [file join $pwd repo1.fslckout] .fslckout
fossil close
file rename [file join $pwd repo2.fslckout] .fslckout
fossil close
cd $pwd
file delete -force tmp
# vim: set sts=4 sw=4 tw=80 et ft=tcl:
--
Andy Goth | andrew.m.goth/at/gmail/dot/com
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Partial hash collision
Fossil uses unique prefixes of checksums as identifiers. What does it do when a previously-unique prefix becomes ambiguous due to a new commit? Also, what happens when an existing comment (or ticket or wiki page or whatever) references a no-longer-unique prefix? Fossil can't rewrite the old manifest without changing every checksum forward, so its only hope is to change the display, but that leads to more problems. It's quite likely this has already been discussed and resolved, but I haven't been able to track down any emails or documentation on the matter. I wish I could give you a test case, but the SHA1 function is thankfully difficult to invert, even for prefixes. :^) -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Partial hash collision
On 3/25/2014 4:40 PM, Andreas Kupries wrote: On Tue, Mar 25, 2014 at 2:28 PM, Andy Goth andrew.m.g...@gmail.com wrote: Fossil uses unique prefixes of checksums as identifiers. No, it does not. Fossil stores full identifiers I was referring only to the display. Full identifiers are usually shown only in detail pages and the actual manifests. and allows you to search for commits by prefix. IOW the prefix thing is a pure convenience to reduce the amount of stuff to enter. Understood, but this convenience feature feeds back into the database when the user enters a prefix into a commit comment or a ticket or a wiki page. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ 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 extra/s
[fossil extras] [fossil all extra] Why? Seems to me since the official, full command name is [fossil extras], [fossil all] should also allow its extra-file-lister subcommand to be spelled extras or any unambiguous prefix thereof, e.g. extra. $ fossil extras tune.tcl $ fossil all extras all subcommand should be one of: changes clean extra ignore list ls push pull rebuild sync -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] SIGSEGV on CR/NL convert for read-only files
src/checkin.c fea64cb746964053193c12937d90a7ba42b625fc line 1315 gives me a SIGSEGV. This is because the f argument is NULL due to fossil_open() failing on line 1305 with EACCESS because the file I'm checking in happens to be read-only. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] RCS import
The attached script imports an RCS repository into Fossil. It doesn't
support branching nor symbolic names, and it has a few peculiarities
designed to accommodate the RCS repository I just processed.
--
Andy Goth | andrew.m.goth/at/gmail/dot/com
#!/usr/bin/env tclsh
package require Tcl 8.6
# Confirm command line arguments.
if {[llength $argv] != 2} {
puts stderr Usage: [file tail $argv0] INPUT_RCS OUTPUT_FOSSIL
exit 1
}
set input [file normalize [lindex $argv 0]]
set output [file normalize [lindex $argv 1]]
# Executes a program after printing the command line.
proc run {args} {
puts $args
exec {*}$args
}
# Formats timestamps the way Fossil likes them.
proc fossilTime {timestamp} {
clock format $timestamp -format %Y-%m-%d %T
}
# Find all RCS files and load their logs into $database.
set dirs [list $input]
set database {}
while {[llength $dirs]} {
# Dequeue the first directory off the list and enqueue its subdirectories.
set dirs [concat [lassign $dirs dir] [glob -nocomplain -dir $dir -type d *]]
# Process all RCS files inside the directory.
foreach file [glob -nocomplain -directory $dir -type f *,v] {
# Determine the working file name by stripping the input root path, the
# ,v suffix, and (if present) the RCS subdirectory component.
regsub {/RCS/(?=[^/]*$)} [regsub {,v$} [string range $file\
[expr {[string length $input] + 1}] end] {}] / name
# Obtain the log, sans header.
regsub {.*?\n-{28}\n} [run rlog $file] {} data
# Process each revision.
set start 0
while {[regexp -start $start -indices {\n-{28}\n|\n={77}$} $data sep]} {
# Get the revision body text, and find the start of the next block.
set body [string range $data $start [expr {[lindex $sep 0] - 1}]]
set start [expr {[lindex $sep 1] + 1}]
# Extract the fields from the revision body.
regexp -expanded {
^revision\ ([\d.]+)[^\n]*\n
date:\ ([\d/ :]+);\ *
author:\ ([^;]+);\ *
state:\ [^;]+;\ *
(?:lines:\ [^\n]+)?\n
(.*)$
} $body _ revision date author message
set date [clock scan $date -format %Y/%m/%d %T]
# Process the message.
if {[set sep [string first \n@: $message]] = 0} {
set extra [string trim [regsub -line -all {^@: *}\
[string range $message $sep end] {}]]
set message [string trim [string range $message\
0 [expr {$sep - 1}]]]
if {$extra ne {} $extra ne $message} {
append message \n $extra
}
} else {
set message [string trim $message]
}
# Store the revision data in the database.
lappend database $date $name $revision $author $message
}
}
}
# Sort the database so the oldest entry is first.
set database [lsort -integer -stride 5 $database]
# Create the Fossil repository.
set lastDate [expr {[lindex $database 0] - 1}]
run fossil new --date-override [fossilTime $lastDate] $output
file mkdir tmp
cd tmp
run fossil open $output
# Process all revision data from oldest to newest.
set users [dict create [run fossil user default] {}]
foreach {date name revision author message} $database {
# Forbid equal timestamps.
if {[info exists lastDate] $date = $lastDate} {
set date [expr {$lastDate + 1}]
}
# Create users as they are first encountered.
if {![dict exists $users $author]} {
dict set users $author {}
run fossil user new $author {} {}
}
# Extract the file from RCS and place into the temporary directory.
run co -r$revision [file join $input $name] 2 /dev/null
if {![set exists [file exists $name]]} {
file mkdir [file dirname $name]
}
file rename -force [file join $input $name] $name
file attributes $name -permissions\
[expr {[file attributes $name -permissions] | 0600}]
# Make sure the file has Unix line endings.
if {[regexp {, with CRLF line terminators$} [run file $name]]} {
set chan [open $name]
chan configure $chan -translation crlf
set data [chan read $chan]
chan close $chan
set chan [open $name w]
chan puts -nonewline $chan $data
chan close $chan
}
# Add or update the file in the Fossil repository.
if {!$exists} {
run fossil add $name
}
run fossil commit --sha1sum --no-warnings --allow-empty\
--user-override $author --date-override [fossilTime $date]\
--comment $message
}
run fossil close
# vim: set sts=4 sw=4 tw=80 et ft=tcl:
___
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] RCS import
On 4/1/2014 10:24 PM, Andy Goth wrote: The attached script imports an RCS repository into Fossil. It doesn't support branching nor symbolic names, and it has a few peculiarities designed to accommodate the RCS repository I just processed. I should mention that this script opens the repository being created into a subdirectory called tmp. You're best off not having a directory with that name wherever your current working directly is. For me, the slowest part of the import was by far the RCS checkouts. Optimizing this would require writing a custom RCS checkout implementation that doesn't have to start from scratch for each revision that's requested, since it will ultimately have to produce all revisions. It might be possible to write this code in Tcl and still have it be faster than this current implementation. I wish Tcl had a [file tempdir] command... -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] RCS import
On 4/2/2014 12:56 PM, Stephan Beal wrote: On Wed, Apr 2, 2014 at 5:24 AM, Andy Goth wrote: The attached script imports an RCS repository into Fossil. i'm thrilled to see someone create a tool for exporting RCS repos to fossil :). These scripts I've written, is there a public place to collect, advertise, and improve them? This script imports from RCS, and the one I wrote before imports from Fossil (haha, that's really what it does). They're not fully featured; for instance neither does branches. But they meet my minimum requirements. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] RCS import
On 4/2/2014 1:21 PM, Stephan Beal wrote: On Wed, Apr 2, 2014 at 8:14 PM, Andy Goth wrote: These scripts I've written, is there a public place to collect, advertise, and improve them? You've done the first part ;). If you are up for this: http://fossil-scm.org/index.html/doc/trunk/www/copyright-release.html I've actually already signed that form, once for Fossil and once for SQLite, and I gave them to drh in person at the 18th Annual Tcl Conference (2011) in Manassas. However, this was immediately after the AlcoBOF, so I wouldn't be too surprised if it got lost. Richard, please confirm. then you can get commit access and add them to, e.g., tools/rcs2fossil. Okay, though not sure what else I'd commit. Maybe I could have committed a fix last night for the crash on CR/LF conversion, though I wouldn't trust myself with trunk. This script imports from RCS, and the one I wrote before imports from Fossil (haha, that's really what it does). LOL! You must really love RCS! Nope, sure don't. RCS sucks. But we have an old RCS repository with lots of useful data in it, and now Fossil gives us a wonderful way to organize and search it. And the one that imports from Fossil actually imports from one Fossil repository into another. Not generally useful, not worth publishing (though I attached it to an email to this list). I only made it to recover a corrupted repository, at the cost of invalidating all my checksums. They're not fully featured; for instance neither does branches i didn't even know RCS could do branches. My RCS phase was short-lived before upgrading to CVS. You're half right. Yes, RCS does branches. Branch numbers are sequences of an odd number of positive integers with dots between, and revision numbers are branch numbers plus one more integer. For instance, 9.4.3.5 is the fifth revision on branch 9.4.3, which in turn is the third branch rooted at revision 9.4, which is the fourth version on branch 9. See http://www.gnu.org/software/rcs/manual/html_node/Concepts.html for a more complicated explanation. No, RCS users do not do branches. http://en.wikipedia.org/wiki/Revision_Control_System#Mode_of_operation says: Although it provides branching for individual files, the version syntax is cumbersome. Instead of using branches, many teams just use the built-in locking mechanism and work on a single head branch. CVS branches work the same as RCS branches. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] RCS import
On 4/2/2014 2:03 PM, Stephan Beal wrote: On Wed, Apr 2, 2014 at 8:57 PM, Andy Goth wrote: We have an old RCS repository with lots of useful data in it. Okay, a love for your data is healthy and normal ;). I have no love for this data, and no one else does either, but we're stuck with it. For instance, here's a check-in comment from 2008: help me i am dyuing. help me I an choking on c code. And the one that imports from Fossil actually imports from one Fossil repository into another. Just out of curiosity: what's the (or any) use case for doing so? I had corrupted my repository such that some of the P cards named nonexistent manifests. This broke trunk into multiple branches, plus caused the Edit web UI to crash whenever in the vicinity of the breakage. So I just checked each version of the code into a new repository, preserving check-in comments. I hope never to need this again. CVS branches work the same as RCS branches. Though i used CVS heavily for 6 or 8 years, i don't remember ever trying to branch with it. Unsurprising. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] RCS import
On 4/2/2014 2:03 PM, Stephan Beal wrote: please send me your desired user name off-list and i'll get you set up after confirmation from DRH. I prefer andy, though obviously that can cause confusion. SELECT DISTINCT user FROM event ORDER BY user reveals we already have an andybradford but also many first-name-only users such as bob and eric and erik. So andy should be okay. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] RCS import
On 4/2/2014 2:22 PM, Andy Goth wrote: On 4/2/2014 2:03 PM, Stephan Beal wrote: please send me your desired user name off-list and i'll get you set up after confirmation from DRH. I prefer andy, though obviously that can cause confusion. Damnit, I really meant to reply to you off-list. I apologize. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Confusing highlighting in side-by-side ignore-whitespace diff
http://www.fossil-scm.org/index.html/fdiff?v1=ff3ce7fdb65c5501v2=f897c6fc3888f9easbs=1w The highlighting in most lines of this diff is confusing, and I don't think I can explain it fully. You'll just have to see for yourself. Indeed, there are numerous cases of something being highlighted as a change even though it's not a change at all. The show-whitespace diff looks good. (Fossil version 5fdad9bd8c) -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] RCS import
On 4/2/2014 5:57 PM, David Given wrote: I recently migrated the repo from CVS to hg (sorry). This is the first checkin: https://sourceforge.net/p/tack/tack/ci/4bea19e501ed That's actually *older* than CVS! It may even be older than RCS... RCS dates back to 1982, two years before your initial check-in. http://dl.acm.org/citation.cfm?id=807748 -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [fossil all extras] useless without --showfile
On 4/2/2014 7:47 PM, Joe Mistachkin wrote: Andy Goth wrote: I prefer the behavior of [fossil all changes]. By default it prints the names of both the repositories and directories with changes, plus doesn't print anything for directories with no changes. I would prefer to be consistent as well; however, given the implementation of the [fossil extras] command itself, it would be difficult to make the changes you are suggesting without breaking backwards compatibility with existing scripts that may wrap Fossil. I'm curious how a script could make use of [fossil extras] without the benefit of the --showfile option. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Suggestions for annotate/blame UI
1. With the potentially wider screen offered by a web browser, I don't see a reason why the user and line number can't both be displayed. Can annotate and blame be combined somehow? Perhaps offer magic JavaScript checkboxes to show/hide the various columns (commit, date, time [not currently shown], line number, user), and the default values of the checkboxes will depend on whether annotate or blame was clicked. 2. The color palette is fairly limited, making it hard to visually distinguish between nearby commits. I'd like to see a broader palette, for instance using HSV rather than RGB interpolation. 3. Colors are all set via span style='background-color:#abcdef;'. This bloats the HTML and prevents my next suggestion. Instead emit some CSS in the head to predefine the various span classes. 4. While any such spans are moused over, change the span's CSS so that all instances of that span are somehow marked, e.g. with a special highlight color like yellow. This should further help to distinguish between versions and see which lines were changed by the same commit. 5. Include the line number and/or user name in the span to visually offset it from the file being shown. 6. Syntax highlighting. Just kidding, I actually don't want this, but I'm sure somebody will ask someday. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Show entire file in diff UI
For unified and side-by-side diffs, I'd like the option to show the entire file in addition to the current behavior of showing only a limited context surrounding the changes. This can be exposed in the same way as the whitespace option. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Confusing highlighting in side-by-side ignore-whitespace diff
On 4/2/2014 8:53 PM, Andy Bradford wrote: It looks like a bug to me. For example, line 45 If you think that's bad, check (new) lines 105 through 108 and 112. Only when ignoring whitespace, they have non-changes highlighted as additions. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Show entire file in diff UI
On 4/2/2014 9:00 PM, Andy Bradford wrote: Thus said Andy Goth on Wed, 02 Apr 2014 20:52:04 -0500: For unified and side-by-side diffs, I'd like the option to show the entire file in addition to the current behavior of showing only a limited context surrounding the changes. Maybe I misunderstand your intention, but while viewing this: http://www.fossil-scm.org/index.html/fdiff?v1=ff3ce7fdb65c5501v2=f897c6fc3888f9easbs=1 There are two headers: Differences From Artifact [ff3ce7fdb65c5501]: To Artifact [f897c6fc3888f9ea]: Both of these can be clicked on to show the entire file prior and after the change. Is this what you are after? I want to see the two complete files simultaneously, with differences between the two highlighted as in the current diff displays. On the command line I approximate this with [diff -U], and in Vim (diff mode) I get this with zR (zM folds changes again). -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Very short UUID abbreviations
When the UUID is abbreviated to three characters, no artifact is found. When the UUID is abbreviated to one or two characters, the ambiguous artifact page is bypassed, and it always seems to link to a ticket. Good (shows two ticket changes): http://www.fossil-scm.org/index.html/info/4e684 Good (shows one check-in and two ticket changes): http://www.fossil-scm.org/index.html/info/4e68 Bad (no such artifact): http://www.fossil-scm.org/index.html/info/4e6 Bad (links to 4e2afbb41cfcf9205d7025cab0cbd3b6f9e51428): http://www.fossil-scm.org/index.html/info/4e Bad (links to 4013b0a81a66de9f7b5914e2eb56b4ce7c3213a3): http://www.fossil-scm.org/index.html/info/4 -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [fossil all extras] useless without --showfile
On 4/2/2014 11:42 PM, Joe Mistachkin wrote: Andy Goth wrote: I'm curious how a script could make use of [fossil extras] without the benefit of the --showfile option. The --showfile option is processed by the [fossil all] command, not the [fossil extras] command, which basically explains the underlying issue... The [fossil extras] command itself has never printed the associated repository information, while the [fossil changes] command has. Most of that is clear from behavioral observation, but my question still stands. I ask the question in reference to your statement: On 4/2/2014 7:47 PM, Joe Mistachkin wrote: however, given the implementation of the [fossil extras] command itself, it would be difficult to make the changes you are suggesting without breaking backwards compatibility with existing scripts that may wrap Fossil. Backwards compatibility is a worthy goal, but I'm not sure how valuable it is to maintain compatibility with something that could never have worked in the first place and therefore may not even exist. Now, an interesting detail. [fossil changes] has a --header option which implements the Changes for REPOS at DIRECTORY: headers, but [fossil extras] does not have anything of the sort. I see no harm in adding it to [fossil extras]. The compatibility problem only arises when changing [fossil all] to supply [fossil extras] with this new --header option, thereby changing its output format. A possible compromise is to have [fossil all] only give --header to [fossil extras] when [fossil all] was not given --showfile. I suggest this on the presumption that any existing scripts that actually use [fossil all extras] must use --showfile, because the output is otherwise useless except for the limited purpose of saying whether or not there exist any extra files, though not where exactly they are. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Very short UUID abbreviations
On 4/3/2014 12:46 AM, Andy Bradford wrote: Thus said Andy Goth on Wed, 02 Apr 2014 21:37:35 -0500: When the UUID is abbreviated to one or two characters, the ambiguous artifact page is bypassed, and it always seems to link to a ticket. It appears that if you happen to have a ticket UUID/SHA1 that just happens to match the beginning part of another artifact, the ticket will always win out. It's hard to test this because it needs a collision of at least length 4 between a ticket and a checkin. Ask and ye shall receive: http://www.fossil-scm.org/index.html/info/6b8e http://www.fossil-scm.org/index.html/info/6b8e09987a847440a2ebf772e4ddcb62c447306a http://www.fossil-scm.org/index.html/info/6b8e355d943a34507eea564ff7ecdcb2a0075d11 http://www.fossil-scm.org/index.html/info/6b8e82544dfc4e88297c8808b11712f1f334039e http://www.fossil-scm.org/index.html/info/6b8ef6a4fd5610f5f0cc648c59511d6e3b78620c http://www.fossil-scm.org/index.html/info/6b8ee7d40d5d7430e4ba816c888a73ba92f3eb2e And another test set which includes two tickets: http://www.fossil-scm.org/index.html/info/2898 http://www.fossil-scm.org/index.html/info/28987096acb2fd6a88b9869ec9f07477b1af6ce0 http://www.fossil-scm.org/index.html/info/289844a2cb535a465c4d956f9907e5b3762d2193 http://www.fossil-scm.org/index.html/info/289890d62b25566652f985cf5ca6bc87ffe69598 Here's a sample query for finding such collisions: SELECT * FROM (SELECT uuid, 'blob' FROM blob UNION ALL SELECT tkt_uuid, 'ticket' FROM ticket) WHERE substr(uuid, 1, 4) = (SELECT substr(uuid, 1, 4) AS prefix FROM blob WHERE prefix in (SELECT substr(tkt_uuid, 1, 4) FROM ticket) GROUP BY prefix HAVING count(*) 1 ORDER BY count(*) DESC LIMIT 1); -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ 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 all close]
It occurred to me that a good exercise for reacquainting myself with the Fossil source tree (it's been awhile since DRH's presentation on same) would be to add a [fossil all close] command. Plus I actually could use such a thing right about now since I'm reorganizing repositories and checkouts, and that requires a lot of closing. [fossil all close] is there in my checkout, and it works, but I'm not satisfied until it's polished, and that means error messages being useful. For example, saying current directory is not within an open checkout is most unhelpful when there's no indication which directory mistakenly found its way into [fossil all ls -c]. My design approach was simply to add close --chdir with useCheckouts and quiet to all_cmd, but this leads to confusing errors whenever anything is shy of perfect. I suppose I could ditch quiet, but I thought I might try improving close_cmd to say which checkout it's talking about. However, I did not want to break compatibility by changing the format of warning and error messages for modes of operation currently in use. So I figured I'd make it explicitly name the checkout whenever --chdir is in use. (Also silently ignore the not an open checkout error.) Just call find_option(chdir), right? Wrong. main() already snarfed it up, and find_option() has the lovely side effect of calling remove_from_argv() upon match. Could add global variables, or could add a --header option or --verbose or whatever, but none of these approaches appeal to me since they are simply workarounds for a design limitation elsewhere. The goal isn't to bang something out quickly, it's to explore the code, so please bear with me as I obsess over normally unimportant details. Not sure if I'm actually asking anything. I'm just putting out some thoughts and impressions. Perhaps someone will have a suggestion. Or I could indeed turn off quiet mode and leave close_cmd() alone. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Very short UUID abbreviations
On 4/6/2014 12:08 AM, Andy Bradford wrote: Thanks for the collisions! First time I was ever thanked for collisions. http://fossil.bradfords.org:8080/info/6b8e http://fossil.bradfords.org:8080/info/2898 Those look fine, but did you really intend to reject all requests for UUID abbreviations shorter than four characters? -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ 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 on Slackware
http://slackbuilds.org/repository/14.1/development/fossil/ I originally contributed this SlackBuild script for 1.27 then later updated for 1.28. I plan to continue updating the SlackBuild script as each new release comes out, though others can take on this duty if they feel they can handle it in a more timely fashion. As with all SlackBuild scripts, the installation procedure is: 1. Download the Fossil source, SlackBuild scripts, and signature using the links on the page. 2. Verify signature against http://slackbuilds.org/GPG-KEY . 3. Unpack SlackBuild script archive. 4. Put source archive in unpacked SlackBuild script directory. 5. Run the SlackBuild script to generate a Slackware package in /tmp. 6. Run installpkg /tmp/fossil-1.28-x86_64-1_SBo.tgz or whatever it's called on your system. 7. Optionally delete /tmp/SBo and /tmp/fossil-*_SBo.tgz . This is an important first step to getting Fossil included in the standard Slackware distribution. Slackware currently includes RCS, CVS, Subversion, git, and Mercurial. It also has SQLite (library, shell, headers, and Tcl extension). As for the next step... there isn't a defined process for lobbying Pat. As far as I know, Fossil needs to make a public splash, and it helps a lot if its compilation procedure is already given to him. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil on Slackware
On 4/7/2014 4:06 PM, Stephan Beal wrote: On Mon, Apr 7, 2014 at 11:00 PM, Andy Goth wrote: As for the next step... there isn't a defined process for lobbying Pat. As far as I know, Fossil needs to make a public splash, and it helps a lot if its compilation procedure is already given to him. Not sure what you mean by that exactly? Not merely how to compile Fossil but rather how to compile a Fossil package for Slackware. Yes it is simple, but it still has to be done. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Very short UUID abbreviations
On 4/7/2014 8:59 PM, Andy Bradford wrote: Thus said Andy Goth on Mon, 07 Apr 2014 14:33:10 -0500: Those look fine, but did you really intend to reject all requests for UUID abbreviations shorter than four characters? Yes, it was intentional. It was not my intention to change the length at which short UUIDs were supported, only to prevent an existing ticket from masking any other potential collisions. Yeah, no need to change. Matching on very short prefixes isn't useful. Do you think the error message would be better if worded to indicate that a longer UUID is required? Yes. To be fair, there is still one type of UUID that will work at a shorter length than 4; events currently do not go through collision detection, so it's possible to view an event with a length shorter than 4: http://fossil.bradfords.org:8080/info/a Should I also add event collision handling to this branch? I do prefer consistency, but we're going to need to think more about whether we want to break something which used to work just for the sake of consistency. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to unset global settings in local settings without the global taking precedence?
This being Unix, there are a million ways to do things. Just for the sake of curiosity, here are 0.0004% more of the possibilities. I only bring this up because I know several of my coworkers don't know about these tricks, so I imagine some others out there might not either. On 4/18/2014 4:17 AM, Stephan Beal wrote: echo '' .fossil-settings/ignore-glob (Unless you're in DOS or the Windows shell) echo with zero arguments just prints a newline. So you can skip the quotes. $ echo .fossil-settings/ignore-glob In bash (not csh), you can skip the echo too: $ .fossil-settings/ignore-glob This will trigger file creation which is a side effect of redirection, but since there's no command, there's nothing to write. csh explicitly forbids an empty command pipeline, so use the : quasi-command which is a no-op (does nothing, successfully): % : .fossil-settings/ignore-glob Or if the file doesn't already exist, touch will create it in the process of updating its timestamp: $ touch .fossil-settings/ignore-glob -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] assert failure in http
$ fossil http GET /timeline (blank line goes here) When I run [fossil http] and type GET /timeline followed by a blank line, I get a good HTTP/1.0 200 response but also this failure: fossil: ./src/blob.c:187: blob_reset: Assertion `(pBlob)-xRealloc==blobReallocMalloc || (pBlob)-xRealloc==blobReallocStatic' failed. Aborted The same failure occurs with an HTTP/1.1 request: $ fossil http GET /timeline http/1.1 Host: localhost:8080 (blank line goes here) I'm using fossil version 1.28 [53aea235fa] 2014-04-15 09:40:49 UTC. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] assert failure in http
On 4/19/2014 4:48 PM, Andy Bradford wrote: Thus said Andy Goth on Sat, 19 Apr 2014 16:38:44 -0500: $ fossil http GET /timeline Works for me: $ ../fossil http GET /timeline ... This page was generated in about 0.011s by Fossil version [53aea235fa] 2014-04-15 09:40:49 /div /body/html Also works for HTTP/1.1. I see we're using the same version of fossil, so there must be some other factors involved. What OS? Slackware x86_64 Maybe the problem is tied to a particular repository. Here's a sequence that fails for me: mkdir test cd test fossil clone https://chiselapp.com/user/andy/repository/test test.fossil fossil open test.fossil echo -en 'GET /timeline\r\n\r\n' | fossil http Just tried on another computer using fossil version 1.25 [b58800e5eb]. Doesn't fail there. I can't be bothered to update Fossil on that particular machine right now since it's a 350MHz Pentium II with 96 megabytes RAM. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] assert failure in http
On 4/19/2014 5:04 PM, Stephan Beal wrote: On Sun, Apr 20, 2014 at 12:02 AM, Andy Goth andrew.m.g...@gmail.com mailto:andrew.m.g...@gmail.com wrote: #5 0x0045238c in ssh_request_loop ( ??? You're doing an HTTP clone, i thought? Or is that part of ssl tunneling? i cloned w/o ssl because my fossil is built without it. No, just running [fossil http] and feeding it a raw request. It should (and does) give me the timeline as HTML, with HTTP header prepended. $ f info project-name: unnamed repository: /home/andy/x/test.fossil local-root: /home/andy/x/ config-db:/home/andy/.fossil project-code: 97cbb37d0a5689395f0f3a4a23bfbb9c5dee4580 checkout: 0c2f822bf5c396fe51ea4f7223195118fe639965 2014-04-19 20:42:49 UTC parent: 8b8761d05b9785b0445f91b1ccef4ce76ce8cffe 2014-04-19 20:40:25 UTC leaf: open tags: trunk comment: [single brackets] [[double brackets]] [test] [another test] (user: andy) checkins: 2 Not sure if this helps, but might as well toss it in. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] assert failure in http
On 4/19/2014 5:07 PM, Andy Goth wrote: On 4/19/2014 5:04 PM, Stephan Beal wrote: On Sun, Apr 20, 2014 at 12:02 AM, Andy Goth wrote: #5 0x0045238c in ssh_request_loop ( You're doing an HTTP clone, i thought? Or is that part of ssl tunneling? i cloned w/o ssl because my fossil is built without it. Well, I do have $SSH_CONNECTION set due to having logged in via ssh. Looks like the CGI code is seeing that variable and doing something special and/or stupid. After unsetting it, the assert failure no longer happens. $ echo $SSH_CONNECTION 192.168.56.1 58169 192.168.56.3 22 -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Inhibit links to deleted wiki pages in comments
I would prefer that the timeline and other places that display check-in
comments does not emit links to wiki pages that have been deleted. I'm
still trying to wrap my head around the sources and thus don't feel
comfortable making this change myself. So I'll just write down what
I've found, even though you guys surely already know this.
It seems to me that validWikiPageName() is the core function to modify,
but there needs to be an extra flag in Renderer to specify whether or
not deleted pages should be linked. Deleted page detection can be done
as in wiki_prepare_page_list() and wcontent_page() (nonzero second
column). Also modify vxprintf() to pass this no-missing-wiki-link flag
to wiki_convert() if one of the special printf flags is set, e.g.
flag_leftjustify or whatever we're least disgusted about abusing. And
of course modify wherever the printf format is used (all those @
lines...) to take advantage where appropriate.
Actually there's a simpler approach since the wiki appears to be doing
something special with bracketed text to pages that never existed.
Bracketed text within a wiki always links to a wiki page, provided that
the (potential) title is well-formed and doesn't already link to another
artifact. So simply make the validWikiPageName() modification and leave
everything else alone. That's pretty easy:
$ f diff
Index: src/wikiformat.c
==
--- src/wikiformat.c
+++ src/wikiformat.c
@@ -1150,11 +1150,13 @@
return zTarget+5;
}
if( strcmp(zTarget, Sandbox)==0 ) return zTarget;
if( wiki_name_is_wellformed((const unsigned char *)zTarget)
((p-state WIKI_NOBADLINKS)==0 ||
-db_exists(SELECT 1 FROM tag WHERE tagname GLOB 'wiki-%q',
zTarget))
+db_exists(SELECT 1 FROM tag WHERE tagname GLOB 'wiki-%q'
+ AND (SELECT value FROM tagxref WHERE tagid=tag.tagid
+ ORDER BY mtime DESC LIMIT 1) 0, zTarget))
){
return zTarget;
}
return 0;
}
I'm running it right now, and it seems to work the way I want it. But I
don't know what all to test.
--
Andy Goth | andrew.m.goth/at/gmail/dot/com
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] assert failure in http
On 4/19/2014 5:49 PM, Richard Hipp wrote: http://www.fossil-scm.org/fossil/info/a138dc97fcde6d323e4c3dbf31f3aef2e386cd47 Works for me! Thanks. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Inhibit links to deleted wiki pages in comments
On 4/19/2014 5:46 PM, Andy Goth wrote: Actually there's a simpler approach since the wiki appears to be doing something special with bracketed text to pages that never existed. ... or are currently empty. That is key. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Wibble import
I'm having yet another go at importing my Wibble development history into Fossil, this time with a much more modest goal: only import the code. But of course that's not possible, as I must also import my check-in comments describing the code. When that's all done, I'll see about bringing in the latest snapshot of documentation and examples and commentary and current bugs and such, with a document somewhere linking to the Tcl Wiki for historical data. The first part is done, that is importing the stuff that was hosted on the Tcl Wiki [Wibble] page, i.e. everything through 2009-12-19. Next I will import the [Wibble implementation] page. The problem I face now is adapting the rather copious check-in comments from the [Wibble change log] page. Go have a look: http://wiki.tcl.tk/27384 . How would I go about putting this into Fossil while keeping it readable and useful? I can keep the links to the announcements and bugs just by bracketing them, e.g. [http://wiki.tcl.tk/27383#pagetoc42e963e2] (though should explicitly give a page version to harden against future changes to the Tcl Wiki). I spy one case where I refer back to a previous revision, and I can just put the commit artifact ID in its place. And the links to other Tcl Wiki pages I can stand to lose. It seems the real problem is my two-level bulleted list layout. Collapsing it all to a linear series of sentences is an option I would very much like to avoid. If anyone cares about Wibble, my current progress can be seen here: http://chiselapp.com/user/andy/repository/wibble/ -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wibble import
On 4/20/2014 11:29 AM, Joe Mistachkin wrote: Andy Goth wrote: It seems the real problem is my two-level bulleted list layout. Collapsing it all to a linear series of sentences is an option I would very much like to avoid. Unless I'm wrong, I seem to recall that there is a setting to make the timeline permit wiki and/or HTML markup for check-in comments. General wiki markup would be awful for me because of all the bracketed Tcl command names in my comments. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wibble import
On 4/20/2014 12:17 PM, Andy Goth wrote: On 4/20/2014 11:29 AM, Joe Mistachkin wrote: Andy Goth wrote: It seems the real problem is my two-level bulleted list layout. Collapsing it all to a linear series of sentences is an option I would very much like to avoid. Unless I'm wrong, I seem to recall that there is a setting to make the timeline permit wiki and/or HTML markup for check-in comments. General wiki markup would be awful for me because of all the bracketed Tcl command names in my comments. I'll manage with plain text (using * and - for bullets) if only I am given a way to force line breaks. I remember there being some mention of that on the list recently, with a CSS way of making it happen. But how would this interact with [fossil finfo] and the like where (I think) line break is assumed to terminate the comment? -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Going to attempt a commit
Still just feeling my way through the Fossil code. I'd like to attempt a trivial commit to make sure I have that right. For the moment I just corrected a bit of spelling and formatting in the wiki formatting documentation. The patch is below. If anyone objects, speak up in the next couple hours. There's no need to muck around with branches for something like this. $ f diff Index: src/wiki.c == --- src/wiki.c +++ src/wiki.c @@ -891,11 +891,11 @@ @ liBlank lines are paragraph breaks/li @ liBullets are * surrounded by two spaces at the beginning of the @ line./li @ liEnumeration items are # surrounded by two spaces at the beginning of @ a line./li - @ liIndented pargraphs begin with a tab or two spaces./li + @ liIndented paragraphs begin with a tab or two spaces./li @ liHyperlinks are contained with square brackets: [target] or @ [target|name]./li @ liMost ordinary HTML works./li @ lilt;verbatimgt; and lt;nowikigt;./li @ /ol @@ -927,11 +927,11 @@ @ target can be a wiki page name, the artifact ID of a check-in or ticket, @ the name of an image, or a URL. By default, the target is displayed @ as the text of the hyperlink. But you can specify alternative text @ after the target name separated by a | character./p @ pYou can also link to internal anchor names using [#anchor-name], providing - @ you have added the necessary lt;a name=anchor-namegt;lt;/agt; + @ you have added the necessary lt;a name='anchor-name'gt;lt;/agt; @ tag to your wiki page./p/li @ li pspan class=wikiruleHeadHTML/span. @ The following standard HTML elements may be used: show_allowed_wiki_markup(); @ . There are two non-standard elements available: -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wibble import
On 4/20/2014 11:29 AM, Joe Mistachkin wrote: Unless I'm wrong, I seem to recall that there is a setting to make the timeline permit wiki and/or HTML markup for check-in comments. I pulled all my release code into the Fossil repository. Here's how it looks: https://chiselapp.com/user/andy/repository/wibble/timeline?n=200y=ci To be done: - Create branches for contributed/forked code. - Publish documentation and examples. - Create tickets for outstanding bugs. - Rearrange code now that it's feasible to have multiple files. - Remove Wibble code and such from the Tcl wiki and redirect to chiselapp. It bothers me that I will forevermore have to be careful about putting , , and in my check-in comments. I've already had to make several edits to fix this. I would prefer a more flexible wiki markup. In the future Fossil may grow an admin-selectable secondary wiki markup language that doesn't resort to HTML notation for things like nested lists. But when this is done, it would also be useful to get a conversion utility that parses existing comments and wiki pages and converts to the more advanced style. The purpose, the very definition, of a lightweight markup language such as wiki is to be easily readable in plain text form. Tossing ul and li and /li and a href and such all over the place is contrary to that goal. Are there any standardized wiki markup languages worth targeting, or does every wiki engine roll its own? -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wibble import
On 4/20/2014 3:48 PM, Andy Goth wrote: I pulled all my release code into the Fossil repository. Here's how it looks: https://chiselapp.com/user/andy/repository/wibble/timeline?n=200y=ci Damn it! For a bunch of versions I accidentally checked in not the Wibble code but rather the Tcl Wiki HTML. I can't go back and edit all the old commits, so it looks like I'll have to call this a failed import and start over. I'll try to salvage my commit text and such. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] libfossil + fuse
What I most look forward to in libfossil is the potential to expose a repository, including all its yummy history, into a Unix filesystem. At work I use ClearCase (when forced), and it bothers me a lot. But it does have one feature I use a bunch: mvfs. If I version /main/branch/5 of a file foo.c, I can access it as /repo/foo.c@@/main/branch/5 using any program I like, for instance vim and diff, and I'm not limited to using the rather pathetic tools that come with ClearCase for doing merges and such. I'd like something similar with Fossil, though completion of libfossil is an obvious prerequisite. Putting libfossil and fuse together could be the way to go. Of course, it would also be necessary to devise a mapping between filesystem names and Fossil. ClearCase's method of naming versions fits the Unix filesystem reasonably well, but Fossil deviates significantly, and for good reason. I'm not saying it's impossible, only that it will take some thought. Clearly, one way to go (can certainly support multiple simultaneously) would be to let artifact IDs, or unambiguous prefixes thereof, map to the artifacts. Whether this is only valid for checked-in files or also for stuff like events and wiki and tickets, that's an open question, as is what you get when you readdir(). The top level of the repository directory should probably contain subdirectories indicating the naming mechanism used within, for instance /repo/artifact/01234567 is how you get artifact with prefix 01234567 from the repository mounted at /repo. Ambiguous prefixes probably shouldn't be treated as nonexistent files, since nonexistent files ought only to mean there's zero artifacts with that prefix. Instead maybe make them directories containing all the artifacts with the prefix. How should different artifact types be distinguished? More directory hierarchy, I'd imagine. And where would the metadata go? I dunno. There are funny tricks where an object in the filesystem is both a file (you can cat it) and a directory (you can ls it), though perhaps there are better ways to go such as making the contents of the file be yet another kind of metadata. Or we just draw the line and say that only file data is exposed. I should hope knowing the artifact IDs isn't the only way to get around. Perhaps also have /repo/commit/VERSION/ be the root of a directory tree containing all the files in the commit named by VERSION, which could be an artifact ID or tag or date. This needs a great deal more thought. I'm just trying to put out some ideas to get us started. This would be a great way to glue Fossil to scripts or diff or vimdiff or whatever tools you like so you can simultaneously work with normal files and old stuff that would otherwise be buried in the repository. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FossilFS. Was: libfossil + fuse
On 4/24/2014 5:04 PM, Matt Welland wrote: I'm not sure you'd be able to deliver a precompiled binary with dependencies on fuse Then call it through pointers obtained from dlopen() and dlsym(). Now have fun making that portable. :^) -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Overlong finfo page in web UI
http://core.tcl.tk/tcl/finfo?name=ChangeLog This one's a doozy. 5.1 megabytes. Is there any way to limit the length of the result until the user asks for more? Actually, I'd like a URL that goes to version trunk of the file called ChangeLog. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tracking System Configuration Files - Best Practices
On 4/28/2014 3:15 PM, Joseph Mingrone wrote: Thank you all for taking the time to share your thoughts. Since I won't be moving these files around too often, I think I will give Fossil (along with Tripwire) a go at this. Does Fossil have something equivalent to another_unamed_scm config core.worktree ../../ which allows you to separate the repository from the source tree? Perhaps I misunderstand your question, but Fossil already separates your repository database file from your checkout directory. mkdir -p repos checkout fossil new repos/project.fossil cd checkout fossil open ../repos/project.fossil -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On 4/29/2014 11:36 AM, Richard Hipp wrote: The infrastructure exists for Fossil to recognize name changes: http://www.fossil-scm.org/fossil/artifact/59e624a3955?ln=353-376 That infrastructure is currently used for the update and merge commands. But it has not yet been incorporated into the diff command. Or Stash, I might add. http://www.fossil-scm.org/index.html/tktview?name=99bca9b4d8 -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Merging two leaves not on the same graph?
On 5/1/2014 12:24 AM, Gerald Gutierrez wrote: I've got a fossil repository that has had two years' worth of history. Recently, I decided to host it on chiselapp, so I created a repository on chiselapp with the same project-id as my repository. Did you use the Upload Repository feature? -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Merging two leaves not on the same graph?
On 5/1/2014 2:11 AM, Gerald Gutierrez wrote: Too big. Chiselapp has an 8MB upload size limit. That explains it. You created a new repository and pushed to it, but that new repository had that unwanted empty commit, set to the current date and time. Whenever I convert an existing project to Fossil, I have to do [fossil new -date-override] to specify the date of the initial commit, putting it before the oldest commit I'm going to be putting into it. Chiselapp doesn't directly have this feature, but that doesn't mean it's out of reach. You can make a new, empty repository on your own computer with the initial commit date set to whenever, upload that, then push to it. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Trouble when making new repository
With today's version of Fossil, I can't add anything to any freshly-created repositories. andy|slack|14:25|0|~/foo $ f version This is fossil version 1.29 [3ef59c357c] 2014-05-08 10:25:32 UTC andy|slack|14:23|0|~ $ mkdir foo andy|slack|14:23|0|~ $ cd foo andy|slack|14:23|0|~/foo $ f new foo.fossil project-id: 596092ff05ecf1b03730e82affc498ebd662c3d2 server-id: 59864d643d5ca6b3b7a52a4a12da6eea43288c66 admin-user: andy (initial password is 463e8a) andy|slack|14:23|0|~/foo $ f open foo.fossil project-name: unnamed repository: /home/andy/foo/foo.fossil local-root: /home/andy/foo/ config-db:/home/andy/.fossil project-code: 596092ff05ecf1b03730e82affc498ebd662c3d2 checkins: 0 andy|slack|14:23|0|~/foo $ echo hello file andy|slack|14:24|0|~/foo $ f add file ADDED file andy|slack|14:24|0|~/foo $ f commit -m test New_Version: 3a4aff36993d288a6dfb7b5c968c3af613c25547 ERROR: [file] is 6 bytes on disk but 0 in the repository NOTICE: Repository version of [file] stored in [file-22ef63d951e2b17d] working checkout does not match what would have ended up in the repository: fbde3b8287dec3dcf10d3327eac39581 versus d41d8cd98f00b204e9800998ecf8427e -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Trouble when making new repository
On 5/8/2014 2:40 PM, Stephan Beal wrote: On Thu, May 8, 2014 at 9:26 PM, Andy Goth wrote: andy|slack|14:25|0|~/foo May i say: that's a a pretty crazy prompt you have there! Username, hostname, time, background job count, current directory, (newline), dollar sign or pound sign depending on UID. Gives me a full line with which to type and plenty of space to see my directory since I'm working on a project which was cursed with stupidly deep nesting. You should see the colors I'm using, haha! Looking into it now, but suspect that Jan or Andy B might have a more immediate suspicion, seeing as they've been around that code lately. I think [3ef59c357c] is the culprit. In fact, the reason I made a new repository was to test that exact commit. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Excluding [brackets] from a.../a links
I'd like for the [bracket] characters to not be part of the a.../a links in Fossil web pages, at least when the link text is an artifact ID. This change would make it easier to highlight just the artifact ID and omit the brackets so that I can paste it elsewhere without having to then delete the brackets manually. Most web browsers make it very hard to start highlighting in the middle of link text, as they choose to interpret that as dragging an object. Any thoughts? -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Excluding [brackets] from a.../a links
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/14/2014 2:05 PM, Joseph Prostko wrote: I've encountered the problem you mentioned about highlighting, but admit I'm not sure if I'd like to see the brackets go away. I didn't suggest removing them from the display, only making them be outside of the clickable link. Current : a href=whatever[foo]/a Proposed: [a href=whateverfoo/a] - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTdCISAAoJELtYwrrr47Y49FgIAJM34akBSiqNcdb7/hrjBYhY VpFNTi9xxQuKBujW2/zS1imQ5aT2aTGxxWPQ5rOXmpehX68BrzY0/pe+/kmX0SPk ozN92Pm7r7/t3prWuqv1cS2pmSCALHHRWGFzgAWNRvkvChw97OVNvbhYyQVosXVh QI+f4WB61/4CZH+4eqfrVD1T9ygqWbixr/qnGdpJYZlGUV6GSnZ7qJG/20oRsMq6 cbFdHjtME4rzZGHokAuvwQ8Z9qWTCnfVtp0WeX9aOjudWwSK+f0e40VVpFOoEHAU 10JrYIRbS395pjdeNsK4aWC6WKzcS31Sf2K6ewcxhT00Y+FNZXt2GSSt634PxzY= =FuNl -END PGP 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] Excluding [brackets] from a.../a links
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/15/2014 4:46 AM, Mark Janssen wrote: How about taking a different approach and have fossil accept [..] as a synonym to . ? Or in other words let fossil strip any brackets when interpreting an SHA id. Perhaps, but brackets are interpreted by the shell, so Fossil isn't the only problem. I think it's simplest to change the HTML. I'd do it myself and put it on a branch, but I have to concentrate on paid work right this moment. Hopefully I'll get to it this weekend, if no one beats me to it. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTdOKKAAoJELtYwrrr47Y4ncAH/0O5JyPp+RvQxMY6M1hYUpEJ zMj3zLVhmq834PLDT4VQ6RSgqjvmArVAJXExB3U/iSrv0bfUfUFJlBc4eS1M/TFy qBA6jKi0DPD9XTNUwdrVpLvWoZSL5TqfZliXvpkt7bMlpGH2D4+1Hfxo9jTEWuW2 Jo9S4d7U+klvgLIGbcQdH3QADjwHMS+afiQFiFnCBY0mF8jIv/BOC7ocEYilL/rK 0f1K80dUUdkc7PND8tWiBV2c8RGqr+yGo3dA5i2wcbJkrPLwe0Ixf4qg8TWQkT9y 8J8bGaplXwqsUaCw4BDgaGMPvhyPRdY55BoFlI657gWEOR/JIkFmJqZACEY0zTU= =MR5h -END PGP 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] New Fossil SlackBuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have submitted an updated Fossil SlackBuild script which will soon appear here: http://slackbuilds.org/repository/14.1/development/fossil/ - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTmgHoAAoJELtYwrrr47Y4r6QIAIVO/k8FTn44XLTq84WQXe1B i/8ikxWWhtl1g1u/0JcRGBGJyz2EuVWuHW0kSUqdOFXEfaTyQTKZX9FLhEUr+q5e Nzm8v8JwDUs744PMczfQogOWLoTmnOfEIIaosCWGP7sS+2EbHkPBjx+zhmXujxT4 c95iH363TsCRgkFGi0NtqGW5iJfzB9dL49sirSzjvIvzwwjN0Cle9kDedoJAZ8uj 1jrMGUHePkL9/vf11c2YhGW/Ie2Ye10tHcI3zNcosGI9mNfpcSLT4NRYLNw1Z19P +3IF+BBAJVdAN3vCQ89ZrDC5UP1j92HyeFA5dqXyByXruwfHgtEZ2EQa3g0r3vk= =SreX -END PGP 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] Alternative approach to disambiguation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Right now, ambiguous artifact IDs are handled by showing a page listing all (*) the artifacts with the prefix. I suggest jumping straight to the oldest artifact with the prefix, but showing the alternatives on the page. Perhaps it would be easier to simply show a warning that there is ambiguity, and link to a disambiguation page like Fossil currently has. At the time an abbreviated artifact ID is generated (e.g. when making timeline HTML, from which the user may copy into a checkin comment), it's unambiguous. I should hope. Later checkins and other activity may collide with those old abbreviations, but we can safely disambiguate by assuming the oldest is what was intended, since again it was unambiguous at the time it was generated. As for the other possible cause of ambiguity (the user shortening the artifact ID without checking for ambiguity), that's (maybe?) a rarer case but is still handled via the alternatives list. What does oldest mean? To be accurate, it would have to ignore date overrides and instead look at when the artifact was actually entered into the database, rather than where it shows up on the timeline. I'm making the assumption that every time an abbreviated artifact ID is displayed in any form, the code first checks if it's ambiguous or not, then picks a longer form if needed, adding a certain number of digits each time it's not unique. (*) Is this really true of all types? I seem to remember there being some artificial partitioning and differences in handling various artifact types. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJToLEKAAoJELtYwrrr47Y42NsIANJEoFhHtqpH4RwiEyCidmKn G2v7IeD/OzwamA0PhExy1NtyvPJ0hoNrRgm73UAJKKPLkNj3EXb0jD0jkPiBLa0I SRyOA+kVuysloSfvUXCN9emhxjmEPinPiOD1+9KcAKXzkRTsSBp0OGI9Hx4Inb0i 4ElDiG5hqRWu1jtuvaESeHL/E4RtpsWgj+iCrSX/KjfeaRmjvGgVCzJlASmRthe9 AQ9G83rHZh4uiCQpD0vbDt4FSDSGZs+zK40pqet7UAWw3VCOSs1gZ6KPAW7tMoQi akMKdDb0Z1YxeBV1lLGEPbvj6cMLADGLgX3w0DujQP2x6ZKiB8OEIx9sphSfSDo= =cyuB -END PGP 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] fossil CLI tricks: interrupting a commit message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/16/2014 3:24 PM, Stephan Beal wrote: 1) Move your cursor to the beginning of the line. In Bash-like shells that's normally Ctrl-A, but many terminals support the Home key as well. 2) Type the '#' character (shift-3 on a US keyboard). That's the shell's comment-to-end-of-line marker. 3) Tap ENTER I do this a lot in bash. This almost works in csh (which I am regrettably forced to use). Yes, the command is not executed but is still stuffed in the history buffer, so the requirement is met. But it also generates an annoying error message about # not being found. csh doesn't understand comments when typed interactively. yukonbob's trick with : does work in csh without complaint. Thanks! I will definitely keep it in mind. Or, in the Bash shell, simply: 1) Tap Escape, then type the # character. That does all 3 of the above at once. Neat, I didn't know about this. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJToPLTAAoJELtYwrrr47Y43Y0H/jJLBWMy+XATUgUDa+K585sp DcYC3QooXTuDwtX+45AmT3BbaNARDs0rBYK+85+7GgoUA1yAeAsV55tAyxK/JHZR /psym9LX0S4q7ggvbymOqSCZ+QuzWpMSYEmSaIXGinvn8/o7eHj6YNAvF4A9wsNx lopqK5AlrhQebc8DxDk6paVHYIzxwShAp1kMmRpkCjegT2PnkfxbqfqhxMYZLz0o 2gqXUrRunofwmyNOi2kPjPoi9DMAmGQuwSGUp0+FDrrVs/qhAKIZpH8JKdgWNe0z cll7jDjLhU0Z2MR9rECVqvCj+AOzKBoptnttepgbHTEHblJNELUoTgkoJUp+k4g= =+8vk -END PGP 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] fossil CLI tricks: interrupting a commit message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/17/2014 9:40 PM, Doug Franklin wrote: On 2014-06-17 22:00, Andy Goth wrote: This almost works in csh (which I am regrettably forced to use). Yes, the command is not executed but is still stuffed in the history buffer, Maybe I'm OCD or something, but if I have to do it more than twice, it gets embodied as a script. :) The purpose of the exercise was to interrupt a command being typed, stash it somewhere handy (the history buffer works well), then be able to come back to it a short time later when the information needed to finish typing the command is in hand. I don't see any role for scripts in this operation, not unless someone wants to make a script to collect half-typed commands, thereby duplicating the (perhaps unintentional) shell feature discussed in this thread. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJToR+MAAoJELtYwrrr47Y4YgsH/3Hp9+4FgNtBpS56QHfSOD7h yA3XbD2MP1tTiiUlbkWlFsEWkGeljShcewIhWxG5h4zzpw5bvb5axH3gni26Z1dJ 6lgW9+iOynyGbsdouFyYTJHtT8YKRJhq10vhiMMpII26n+MrgDhEJBFBDXkab1K5 85oxvgNM70xVHGccja2gfcBvSutcD7W8k2rvfQOaAM8+odhdXLL+Xs9X2GVAf5gs RMtpGT4g2qKgpNtT8RDS9+H6tHNcyT1Bj/NIjlNNcnWfjIRJsXXG2OWj/LhbVvNZ NWiDXC/qdxaGFOmKYrJoLzYJBJ+F40MiXxTHAl1QLjxYckvLl7gTl/EIJpXV47E= =IcYY -END PGP 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] fossil CLI tricks: negative pattern matching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/19/2014 11:09 AM, Alysson Gonçalves de Azevedo wrote: Hi all. Just like Beal shared with us the # trick, today i'll share how i can commit all except one file using negative patterns http://www.cyberciti.biz/faq/linux-bash-delete-all-files-in-directory-except-few/, something like !(file). Here's more on this feature: http://en.chys.info/2009/02/extglob/ You've demonstrated the utility of !(file), but I was unsure of the other extglob modes such as @(). The link explains. And yes, you need to do shopt -s extglob to turn this feature on. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJToysSAAoJELtYwrrr47Y4nbIH/AlXbFBhk12AMcbgqvidd4K8 tU6sMbU+0XhQfdhjwnmjpZKWvHSSvT8qCVCd+fDAvrWm3g3tL7PFMSbXQpCEypZD PVKWlG3G7T/wA1zWsJ/kuRWR4+3BbP5mjDwVqtrSnARAzDLMZX+U0wO/XlkMMgUa kpYpGIfbufq2UikDNVqDDjDaJyL4Kn2qyHTWsrD5zljwQkjxXRSqjDQKGV+jkTgL UVkT++wTp+NCgW194eDrEDy55437cUQqPEbQ0K9G6rCRDN9rM+IQCJZFkc5uvxvM Qr1txwJHgI94kb1kDR0F32tOAWZkFr7etiAqLoz6Y6laWFtUp9Nk8Zi5faFKNIs= =kcQZ -END PGP 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] fossil CLI tricks: negative pattern matching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/19/2014 1:50 PM, Alysson Gonçalves de Azevedo wrote: And yeah, I agree with Beal for beeing cautious using this feature. we need to know how extglob works so we won't get in trouble. Whenever I'm unsure if a glob or substitution or other expansion will do what I want, I prepend the command with echo so instead of running, it just prints what it would have done. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTo0W9AAoJELtYwrrr47Y4MbkIAMEgnR3ObskwTi9KI7xYA5cy GGNKT9kd6hqrKxPlklya1wzMYyl3YqCdIEZ4X+2VVeO8glmJ2CzRbtpkOXX44Wn+ cv9W9XkCYIBvAtfLrJ52vACuAyEFtn121GkRfS25KVv0FsDheqr0twGi9y9yj6sp FoWqyAKDHpaH/Gzpyo+iS4TxcB429IBaMBJL6JLX26BdXgovhsM0Pjh9JPfchsiS 1JUB6Fs2SRMhwVnWqXxHmvwpqYLc7wyiCc6sx+Wcsil5W6wYhmY/I6UBWh4vBeBF npP3wR0r/3+0B+YoOJdgcAtOy/igqmd1slipEcLYRjrcTM1HN85WHghzDxPWoMk= =yMtV -END PGP 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] Slow commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm having trouble with each commit taking about 45 seconds in a new repository I initially populated with 5154 files totaling 425 megabytes. At this point, there are only five or six commits. I understand Fossil's SHA1 code has been found to be slower than most, and this may be the cause of the slow commits. Has any work been done to improve its performance? - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTqdu1AAoJELtYwrrr47Y4oRoH/2g2tVtlh/ausr59O+JwT/NE zLxe0qmc/K7GpdzaASZUa1WZjNEZpBCH1683h/L09EVEw2GX0T2vu62gOuCUvZYy 68hlPFEfQ3MfHOIr1ZTfzJSUWtU5AKrTMf1l/6lQDtg2JdIWucE0SVGLi9ZVebVF xhv3RbkgpEv+voOm6ClbC6PXfT4zGaqoWaiiUajyY/rBs0tHky6unZYAFWQmnoov ak9mrFRxG9WO0cAf42meemRQYzvXIti0/EigyMWd+rHA/Pu5O7qx7ulAiSlafc+9 zdkax+zOG52hNj8uGqdzuUqrzHxsvIBFX2DGpeYbvZzCE9DQJoKaNmaeIbLKA8E= =q/Ry -END PGP 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] Slow commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2014 3:12 PM, Andy Goth wrote: I'm having trouble with each commit taking about 45 seconds in a new repository I initially populated with 5154 files totaling 425 megabytes. At this point, there are only five or six commits. I understand Fossil's SHA1 code has been found to be slower than most, and this may be the cause of the slow commits. Has any work been done to improve its performance? By the way, running sha1sum on every file in the repository takes less than five seconds. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTqdzmAAoJELtYwrrr47Y4dBUIAMQdJPahT2c4yfFuHfrkSppr ty3mDD6Z+gOY2EEsGEn6yWOijMAxcxL9y2ZeSAtLSXbfSO12P/N0zfY77oTdgZjs GwiynyK3ajQElfRaefJ0ClY3D4+cB7OX1Rd5Zb2MF+5KMkZw0KE/9ryBgL4rb0Xd vw17uXpy/aq45fosgKdsm4vgmv1Da+iyTJ27HSJGhwrT6D4i/1oNpcniyucsXofF V7CcTGbUul6opNAE3yOH6pbo/JxyD01JVibNEjpzDWuxn7A9wjU4zokaSwEqL8Li lv+9Ishxl/icRZSmCbpnx6U+jOlBqt0Nj7cH6tc4jU7f4PQbXOV+r474TiiYB0U= =Lt47 -END PGP 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] Slow commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2014 3:22 PM, Warren Young wrote: On 6/24/2014 14:12, Andy Goth wrote: I'm having trouble with each commit taking about 45 seconds in a new repository I initially populated with 5154 files totaling 425 megabytes. At this point, there are only five or six commits. Does this happen when committing a new file to the repo, or only when changing an existing file? If only to existing files, does commit time correlate with file size? That is, does a file 2x larger take substantially longer to commit? Changing existing files. I haven't added new files since the initial commit. The time is independent of the file size. The files I've modified have all been quite small, microscopic in comparison to the repository size. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTqd5IAAoJELtYwrrr47Y4gBMH/3jY3+yJtusVYqXwAlbv7MDa ayZghTTFa9yEihcwFgpPS9VuJ4S6LQuX28A6FJ7qC1oNTdi+CgTf/PRSxTpUEqYE 0Nc1ELd+1bXUd1kRpYuIC1vE0uXNKmUVmZCiq0CN2bM1dtBBjBprnpw071awTBM8 l2WkqyRAmQ/cQUG9SErozH5FMhGd2gNclizpENt+GhPvBrQ8LZfAClsUvbNxO1Fn 9jaVo24eyxybsc0AG/dcQe3RAlHCEIlTCKlcQify9CQXceHvkwlPCG0e7eUhRKb6 rKL0gHiSo0QDvikyj5WZ+0af+67UKpCiC6zmIsK6bQqu8iQL6/p0A95o7a7emfw= =slCi -END PGP 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] Slow commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2014 3:27 PM, Richard Hipp wrote: On Tue, Jun 24, 2014 at 4:12 PM, Andy Goth andrew.m.g...@gmail.com wrote: Fossil computes an MD5 hash over all files in the repository as one of the verification steps prior to commit. See http://fossil-scm.org/index.html/doc/tip/www/selfcheck.wiki for additional information. Computing the MD5 sum over 425 megabytes is problem what is taking so long. It might be possible to provide an option to disable this checksum step for large repos. This command, run at the top level of the source tree: find -type f | xargs cat | md5sum completes in 3.62 seconds. To confirm, find -type f | xargs cat | wc -c outputs 428,488,837 (without the commas). - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTqeCVAAoJELtYwrrr47Y4Dd8IAJQa9/oOCzbazI1+6jOkDyxU OO09i38fGlcLNzgXVoCwaQH5dXWy2NjQTfj8WAYJDe4kLBRK89QSecmp6ilOlrDB p1dZozU1CaZRl/ejj7TLAttNLE5dugaVW6G4u2b1BbI+lyTx9p0kia12AjLj6HrU MrV7W50d+TrqM5tlgYegSQUWkvWqy86Uz0E6RtfKG8kpvRvyzX1RFPcJc4KcWvG4 SENpiRZKDBvkcKElrnpmvRl8EIZtzEYMHrA0SykRayRusyPOMkhjasgBtA87DfUn l/u6pN21Ef7chiZ7j+lJjZshUU92B9Tb/OQ368o49XXXmdGUczxVRqD94/H0R4o= =ImCZ -END PGP 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] Slow commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2014 3:41 PM, Stephan Beal wrote: i agree with Richard's suspicion - the R-card calculation is very costly in terms of system memory, and puts the allocator through the wringer. There's lots of db looksups, undeltification and unzipping going on which is not accounted for here: It takes 21.20 seconds to do a fossil open. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTqeMxAAoJELtYwrrr47Y4GdMH/2lnR9iB/r2VrqTZdP/mq77D JpovdImntN2+xjCqS9yyYo59oLSvv+xpBFH7V0DuzRTedzygQSxbqIE3nbLgJYNl eJOcXmYgnE/C++n/5VIiucmyMN+h3ksSL6nWRGVsRLzgWHOJPtbB8dM8KqbV5WYq rve5WkqyKIwWpW5yJRSIhnFEqIl1c21Ek5V0bugfr1A9ML5SedNyrIpRIOkAwiWo KgACDyL1HuB1av/R377rk4zV9VwxIhWYNaxF2HtXiyMGRvwY6XWDUiavkFqwPadN gWq3SKB40LjcXWAdvdO1tHbQN6Bk0cVAowa8dLYQq+TpFoVTVMlAjIGTDDqw6nQ= =YxBO -END PGP 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] Slow commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2014 4:33 PM, Richard Hipp wrote: Can you compile fossil with -pg, run a commit, and then consult gprof to see where it is spending all its time? I just did an empty commit. It took fifty seconds. Due to machine availability, I'm using a different computer than before, and this one has autosync turned off. gprof says 89.2% (10.74s) in MD5Transform, 1.16% (0.14s) in MD5Update, 1.08% (0.13s) each in pcache1Fetch and sqlite3VdbeExec. Cumulative time is shown as 12.04s. I'm not sure where the rest of the time went, but gprof isn't seeing it. Shouldn't be I/O or other kernel stuff since there's no autosync. I can send you the full gprof data if you need it. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTqfJsAAoJELtYwrrr47Y4M+UIANsGXYDG1+C1vhbtckokk1wk tTCteG+SKlzaaF6p8UVawQak/Sv6KFdZqVFiI6CfQdww/8iqLpYKcAI+onPEKx/m UBqWypBDVvlAWE2mJLMNoKqUCiC3QIFALYGgZqzNme0JVoYL0/7LRJBMey0djHVj 9b+iOzfSp76+Ipl6sIH/GchwhcQJvQZKWLaxAU26GbYSoEt6jcF28HJ+8emkMsZt xnTlRe7CV42G7zsNk3i8Eeu78Nx2thRxFI75HYnJIjB+/hHVIhrf3EqSeDK6E4p4 viJ4CwW4Id2pp95MU5caAwR+SCEeoZ8xZNVKIijhfOZiQUN5VmErHL49QI3F2v8= =UI+N -END PGP 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] Slow commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2014 6:38 PM, Andy Bradford wrote: fossil settings repo-cksum off This speeds things up mightily. Thanks! Now for my next problem: the clocks of two of the computers I'm worried about are off by 21.1 minutes, and this time skew varies. Sigh. I'll try using the date command to fix it, but experience has shown it'll get bad again soon. No idea why no one bothered to use ntp or clockspeed. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTqvh6AAoJELtYwrrr47Y4FLQH/RmVEE07oHFL770MTJqyxfdw orPzwduaKOBecFokC3h0G3NVvoMNjZdr7erTXturpE4rO7PpLEtSXV0kwME2RHPR DQODWD+CwfkY+gsk07tceR6f9mw7mPgJ6gvSneZuUu8TS+4FO3kpvKAV0JERT/Uh PWhjQv7Z4yIxlgrS0PUvE25TAZ3P8Gz6h0wucWHn6yszUnQdbJBzCqyzly+EiGLf OEgL8IRXy3QaHSe9jI9ZB1aKsDnr7wTpkTCOc7jFS+5/hFkT1HytLNFqtw0ThISW 4NWd8ZmG0olxeEgKHIdg64SMareYGtnwlmvpBJIbKAxcmlvF1jJ/DZb71Xv1hMY= =pZdN -END PGP 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] Fuse SIGSEGV
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Was trying to run find, eventually got this:
Program received signal SIGSEGV, Segmentation fault.
0x76574230 in __strncmp_ssse3 () from /lib64/libc.so.6
(gdb) ba
#0 0x76574230 in __strncmp_ssse3 () from /lib64/libc.so.6
#1 0x0045384c in manifest_file_seek_base (p=p@entry=0xc2a920,
zName=zName@entry=0x8612b0 ~/, bBest=1) at ./src/manifest.c:1267
#2 0x00455b3d in manifest_file_seek (p=0xc2a920,
zName=zName@entry=0x8612b0 ~/, bBest=bBest@entry=1)
at ./src/manifest.c:1285
#3 0x0044239a in fusefs_getattr (zPath=optimized out,
stbuf=0x7fffdf20) at ./src/fusefs.c:167
#4 0x76806be3 in ?? () from /lib64/libfuse.so.2
#5 0x76807b15 in ?? () from /lib64/libfuse.so.2
#6 0x76809ada in fuse_session_loop () from /lib64/libfuse.so.2
#7 0x7680f394 in ?? () from /lib64/libfuse.so.2
#8 0x004424e1 in fusefs_cmd () at ./src/fusefs.c:341
#9 0x00417e39 in main (argc=optimized out, argv=optimized
out)
at ./src/main.c:725
A little sniffing:
(gdb) p zName
$1 = 0x8612b0 ~/
(gdb) p p
$2 = (Manifest *) 0xc2a920
(gdb) p lwr
$3 = optimized out
(gdb) p p-aFile
$4 = (ManifestFile *) 0xc843d0
(gdb) p p-aFile[lwr]
value has been optimized out
(gdb) p i
$5 = optimized out
(gdb) ptype p-aFile
type = struct ManifestFile {
char *zName;
char *zUuid;
char *zPerm;
char *zPrior;
} *
(gdb) l
1262 return p-aFile[i];
1263}
1264 }
1265 if( bBest ){
1266i = (int)strlen(zName);
1267if( strncmp(zName, p-aFile[lwr].zName, i)==0 ) return
p-aFile[lwr];
1268 }
1269 return 0;
1270}
1271
While I have the debugger open (better ask soon), is there anything
more you'd like me to check?
This happened while exploring the fossil repository (current through
cfb8d6604f8a159e8a5c1fa8843be12060f0fff4 2014-06-26 07:40:11 UTC),
looking at checkins/tip.
I actually had another SIGSEGV earlier, not sure if this is the same
crash or not.
- --
Andy Goth | andrew.m.goth/at/gmail/dot/com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTrHwlAAoJELtYwrrr47Y4phoH/iVz7/gnObnYrbBKml+ydSWJ
zxpILKE2Lib4ob+I0UuPtwTLvMfD9okLbjk3/ZR1cVGpHexEI+BXDdxMqwdllV1J
hG4fExp2vKpPwz9Q7n6Pf4Ty4KqANAPdVKcnhliI+RBkFRzuCN7MXc45cfehf0y/
/ffQyIAYKfs0g+zz0Cv3Ym2Nc9nGoYwDo3ZEMagO+KOZLSeI4PI0iDo6XKMxmwaq
lS3Iq436rojCIdtkoY6xc8l0htMaZiGrmDdsIenJpLcMnI3i1Iamy48q25P+dDa3
SDGaCmlvF1nZUnV6lgAGy57RDlxuxHmPAhpkixaaZ6X3nb0XmW+GZrCfm+1mucY=
=aGaY
-END PGP 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] 2 repos being each others remote-url
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/21/2014 11:48 AM, Michai Ramakers wrote: does it make sense to have 2 repos on different machines having each others remote-url? I can imagine things get a bit weird, sync-tree wise, when more machines are involved, but I couldn't think of a counter-argument for 2 machines. It's just that I've never seen such a setup being mentioned here, afaik. I'm working with a bizarre setup where multiple computers need to keep a repository synchronized despite routing not being configured such that the computers can all talk to each other without intermediates. For the links that can go through TCP/IP, I just do manual pushes and pulls to keep it up to date. Autosync is nice, but it doesn't get me the whole way there. If I could configure a repository to automatically push to other computers whenever something is pushed to it, that would help. Not everything is as nice as TCP/IP though. I have one link that requires synchronization via Windows SMB/CIFS implemented over Citrix remote file access. The remote URL is file:client/c$/users/andy/desktop/work/fossil/whatever.fossil haha! It's monstrously slow, but it works. Then I have to further synchronize that file with a repository in a Slackware virtual machine on my computer, but at least that's TCP/IP again, albeit through VirtualBox rather than a NIC. The only thing that makes this not be a forking nightmare is the fact that I'm the only one who ever commits. As complicated as this sounds, it's vastly superior to the alternative of pushing individual files around, forgetting to keep stuff in sync, having mismatched versions everywhere, and not being able to track the status of everything. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTrIAdAAoJELtYwrrr47Y4uPgH/R5MtpJMJNCruESOfoSfnITd 4nSIaMm9kFI1pGeV63MujikuALJyJ9tBhrSPy5C2A5LFQvBkqduhKz6g30Pi+tN6 BZcU4DZnApU8p41uHZMB9WmG/NHFYodPy+5ww2QNSXKxmhHvSXpGAobaJQdiuRaI 6kszD3hDanCsJKl0B1nTzhJCh5BjbmRB95XzbLOW5wSzyYb4etdwuW2JKXBlMhNQ oOj1kax37mJnjezaqpXVLHWFZBPtzf8DsCd7g/rmI1BNvd7uTilybEF3IOaqlmW7 nRviNU3Sxey8S6iNddKUCkklyyJ1BsN7Dtt/VyIbv+mdm0aDOplU4fzauN4ZH3E= =rPUL -END PGP 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] Generous time formats
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fossil accepts dates with days beyond the end of the month, so long as the day is not 32 or greater. It also accepts times 24:00:00 through 24:59:59. For example, 2014-02-31T24:59:59 is valid. I imagine it means 31 days after the start of the day before February 2014 began, plus 24 hours plus 59 minutes plus 59 seconds. (Assuming 24:00:00 is considered to be the end of the day. I'm not sure how to tell.) This may be intentional, in which case carry on. I don't mind. I just wanted to be sure limiting time wasn't inadvertently overlooked. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTrLW7AAoJELtYwrrr47Y4WWYH/iLqDnCNd/FKST1Q6GmHrifv LgAw8LtYjGfIq5DzNunQHC6Xzg7SwiOU238cf/YcI/DrePyENkN379GuidNd5GMx 1kBxhobdDQneWzQFak4C616s8vQQuoznaJPhXq7jOmRWu0E0qC+6aFqvEwBaAw0j hDx7Uwl6GkHPeC/XpkzFQ80RPhmPlr6yjh4Lx+zA3ZsVkyO+hyoTed41Y+bJiope PGSbr8ckuaWpgmUfcjj96im+0G09XKEUT4hsD/vg6BqV7FkB1aIFpytzDpY4lrH8 4ksbbF3xcPxBaUltkrEqVSL881HP/krQU6XjV600qqRe+MTfiAWjdQgBkD03Ce0= =kpgX -END PGP 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] Fuse SIGSEGV
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/26/2014 3:39 PM, Richard Hipp wrote: Since you are able to repro this, can you rebuild Fossil w/o the -O2 option (so that variables are not optimized out) and rerun in the debugger yet again, then do the same analysis? I have done so, but I am not able to reproduce it consistently. I played around with it for a few minutes but couldn't make it break. I don't know if -O0 fixed the problem. If I can't get it to fail today, I'll go back to the default optimization and see if the problem comes back. That would be most troubling. I'll also refrain from updating my Fossil repository while hunting this problem. So, there's another issue. In a Fossil Fuse mount, find doesn't recurse. How very odd! I wonder if fixing this might have the side effect of revealing (or at least making it easier to find) the SIGSEGV we're chasing down. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTrLakAAoJELtYwrrr47Y4EpAH/RQAmMad8vx6aRxGvjRYiRIY 0FdSeTpcu+UMMrD/f0bK1+xHq19PGzrEvUKytgLGUKVPCQZoH7p+PiAV1XFhuTG4 /nZSS2Z+uioWazrGnLODvRdhpCLBT+b5F1ee1QY9FtxHwTvcMuAaqQCYTAljiPzr j+xt5jEaes63tWaFLfcoOH8zqWP892LL22iRgziIhi/HUuCl0vBQ9l2KL2Fl5z4N fQ06YzQjpdQu6vkpuG0mWM+NvNKspZhAYSMfo0jN3U5JAdB1aVOL0XMc4Oj/Y6P4 73FJtIQ/sVbSouXDkafEi9XZHSwaAo45ndDpLIi2EISvxF4XC3hqYbBMS3sDKD8= =8V5Z -END PGP 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] Incorrect error message for [fossil pull]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [fossil pull -R repos] prints Usage: fossil pull URL when the repository doesn't have a known remote URL. I believe the problem is on line 147 of sync.c in the current Fossil version (cfb8d6604f8a159e8a5c1fa8843be12060f0fff4). - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTrLnhAAoJELtYwrrr47Y4/lUIAMR9NPTkSLVzFk7IBElCPdeK KsYDhBJZVkPdHBjW8cC6u7oUY93Ubid2RFUBjSNqUlPtn7NNr5S6Nis7cVe7ZT/+ 6UjOOND9Y2jC80GMkQTLgROTTGZhKrOedxRNBO0qQeS9jcDAEUxrSbuTeeWWNzSG vm85KNnmhHM4e4L57tad946gnYFqJ0Xlc/njNSxDHQqb2o4CeX9HagZQGU8gjb6I jGGVVPEbYQTVXApJnfbc75RbG4IKg0jHYoU0Tdj285mUTB+53KPWpL0d1yzp3Z/I Z1tznH6C3Zm2BoUtrCmRSMbZe3G9LRtjZ5gBIFfP4Vg/w+aDuzkggTX8qjtVAiI= =LixL -END PGP 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] Fuse SIGSEGV
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/26/2014 7:11 PM, Andy Goth wrote: On 6/26/2014 3:39 PM, Richard Hipp wrote: Since you are able to repro this, can you rebuild Fossil w/o the -O2 option (so that variables are not optimized out) and rerun in the debugger yet again, then do the same analysis? I have done so, but I am not able to reproduce it consistently. I played around with it for a few minutes but couldn't make it break. I don't know if -O0 fixed the problem. If I can't get it to fail today, I'll go back to the default optimization and see if the problem comes back. That would be most troubling. I'll also refrain from updating my Fossil repository while hunting this problem. I couldn't make it break with -O0. Will try again with default optimizations. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTraEEAAoJELtYwrrr47Y4CrwH/07QPduByxl+HXoNFSlwoXUv UcL7gPNVPLqataA3/NDafY2T4tRSXT1YPmVt6g/3Ms5LmadfUw/w7JhRIA/41Vih i4fG2ikJc1xwHwLjwDnDPiq7GiWnO+qBsgZiHX/5YTzYxRkAabh7DJ/4j+Kacg3C raGL8VJuC49YlYHGjOuxaqDma9uJEIJnQeNPhEmk3Xn9yrEXgV6bPZA061gKeJnv h482q3ZC+AQ6p02Gy74lQV1nuBQNBtl1DFZGZEhr0juRGRxx9yWVPXAt4v7SWMi8 QzatQXUSzUUHshYqNEUCOchj1N4meBEWlsnGVo0VPmW1+DMA5K6xEO3nC632sl0= =4Bmf -END PGP 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] Fuse SIGSEGV
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/27/2014 11:51 AM, Andy Goth wrote: On 6/26/2014 7:11 PM, Andy Goth wrote: On 6/26/2014 3:39 PM, Richard Hipp wrote: Since you are able to repro this, can you rebuild Fossil w/o the -O2 option (so that variables are not optimized out) and rerun in the debugger yet again, then do the same analysis? I have done so, but I am not able to reproduce it consistently. I played around with it for a few minutes but couldn't make it break. I don't know if -O0 fixed the problem. If I can't get it to fail today, I'll go back to the default optimization and see if the problem comes back. That would be most troubling. I'll also refrain from updating my Fossil repository while hunting this problem. I couldn't make it break with -O0. Will try again with default optimizations. Tried again, no luck breaking it. I'm now regretting not saving a snapshot of the virtual machine state while I had it caught in a debugger. Even with optimized-out variables, I could have cross-referenced the source code with the machine code and registers to see what was going on. I switched back to the default optimization, thinking maybe the compiler is having its way with us. But I can't break it either, despite doing the same sorts of things I did yesterday. Here's the stress test I just ran inside the checkins directory: for x in $(seq 1 12); do for y in $(seq 1 31); do for z in $(seq 0 24); do find $(printf 2014-%02d-%02dT%02d:00:00 $x $y $z)/*; done; done; done The /* is necessary because find doesn't recurse in a Fossil Fuse. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTrcIOAAoJELtYwrrr47Y4B80H/j5rh4GycCCvOtT/Tp2gJ6fx BTCTxkPAqPdgIiVpDd1i2zERMkkkUJsUZn5Fywu9NWdiDNZjdZ2rDGT2sBhKSatI mRKyjS6BzfSIwZLKZFrnNwqsvYlowtWZmIdwMKZsBWfaolGqTM0uWAC6nUoilDIz TuEBlmOrgdR/c2TbaCIw1yUc+/wVTVlmO/9s7M+R+tEhqr5VVXmAkEF/F8Q83DEE p5XgTt3amUt4fJNVICac6LcVF3/N3qCwXAmDWPcSczb0sJ7bf6dreNAQZ0Ijj+1e MjjB2EL03yzcqCrmKPnKwOol1Ez+GRCdK+ILhryndVW9biEJbYthohtiBZzxk2U= =l3Hw -END PGP 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] Sixteen-digit event IDs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 How come events are always shown with (at least) sixteen digits on the timeline whereas other artifacts are given ten digits? http://www.fossil-scm.org/fossil/timeline?n=20y=e - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTreTRAAoJELtYwrrr47Y4090IAIgVQ/T1S9usyvEGZ4309c6d IQoD2TK9kgm7TDH1QPT1lurQwcugq1A7Q8PbR5ETedvIfGuQGRauajpSsbw1RU1/ rKcZQ/aCRMZUz5EP46CaCuw5vKI8zOa3aqIGzmQPYoqx1nVanoKe8JO6b0larbSS SKo1DBA5NAPjYZqbRMX7Wp9Ypn5YcWS1PxwBGY6GNpEcYwycv0D15PCHLd8JwjVd mVM4F6rbsyE9gjs5yjG5b0ZCfmx2HJqQWP0Z28FVaB40CexSzCOnbMe2zdmHrj57 dZlK6AKE0JHm2KRf7zzyezMC8chEXFBYi5rhLFxxYkwf/PX+ey2tDcAYzSYgJPY= =hmbi -END PGP 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] Problem accessing shared folder in VirtualBox
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/27/2014 5:56 PM, Alexander Strobel wrote:
Problem: I am getting the following error message when I try to
open a repo wich lies in a shared folder of Oracles VirtualBox:
[somelocaldir]$ fossil open ../geelaunch.fossil SQLITE_IOERR:
os_unix.c:29821: (22)
fsync(/media/sf_Projects/geelaunch_working/../geelaunch.fossil-mjC43B7293F)
- Invalid argument fossil: disk I/O error: {COMMIT}
Can someone confirm this behavior?
I have similar problems with VirtualBox shared files, and they're not
just with Fossil. Don't use it VirtualBox shared files for Fossil.
Instead use http or ssh to synchronize between a file outside and
inside the virtual machine using VirtualBox's TCP/IP capabilities.
- --
Andy Goth | andrew.m.goth/at/gmail/dot/com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTrf1WAAoJELtYwrrr47Y400cIAJjQa1EBkCVfAlzzfkTW4Aal
BL8P4sl9C7hplls/O+r3bjoa+6u/jkajX64nIYgpNBUvyxPawhH6OfRCxX+5Aazc
42lBQoCIffk0dRRQROYk9YhhZh5x1wJ9ws8fYVb8a+AvFBVJs8QD5JIn3VeSC4AM
YcqH866WLsL7gir7QEYBiWb0jknHDpzufuq4nWTqROdqGxfQb8abLVOPrR/Po4wk
wxoljBs/DhCOq9lKCqTVX8jqPEIiB6RlIzojkkJ4Gl9M88W82eFb2Fd1/S+djHCz
+WIhm2Uhyhy2vov+sIPIOmzd2K9M3itl8MerlI+qujZi9dwojUoTtm+mxr3F7iI=
=yH3a
-END PGP 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] Problem accessing shared folder in VirtualBox
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/28/2014 1:24 PM, HeadshotX wrote:
On 6/27/2014 5:56 PM, Alexander Strobel wrote:
Problem: I am getting the following error message when I try to
open a repo wich lies in a shared folder of Oracles VirtualBox:
[somelocaldir]$ fossil open ../geelaunch.fossil SQLITE_IOERR:
os_unix.c:29821: (22)
fsync(/media/sf_Projects/geelaunch_working/../geelaunch.fossil-mjC43B7293F)
- - Invalid argument fossil: disk I/O error: {COMMIT}
Is there any chance that it will work like I tried it first?
SQLite is quite strict with the filesystem, and it needs it to work as
advertised, for example with syncing and file locking. VirtualBox is
just not there yet. Go bug them. Give them a tiny test case, a
sequence of commands to create a repository and try to open it.
Actually, I just reproduced it here using Oracle VirtualBox 4.3.12
r93733 running on 64-bit Windows 7 (Pro, as if that matters). Just
include this email in your report. Here's the sequence:
1. Download Fossil version 1.29 to the host desktop.
2. Unpack the archive to get fossil.exe.
3. Start cmd.exe, cd to desktop, and run fossil new crash.fossil.
4. Start a guest OS (using Slackware64 14.1) in VirtualBox.
5. Install Fossil in the guest OS using any method.
6. Mount the desktop via a VirtualBox share, e.g. to /mnt.
7. Run fossil open /mnt/crash.fossil.
Error message is:
SQLITE_IOERR: os_unix.c:29821: (22)
fsync(/mnt/crash.fossil-mj698EA9932) - Invalid argument
fossil: disk I/O error: {COMMIT}
(line number may vary since I'm using Fossil 2e51be8ec2 in the guest)
Here's the failing function. The error is printed on line 29821, which
says unixLogError(SQLITE_IOERR_DELETE, fsync, zPath). Perhaps you
could try recompiling Fossil with SQLITE_DISABLE_DIRSYNC, though I'm
sure you will have other problems, e.g. database corruption.
/*
** Delete the file at zPath. If the dirSync argument is true, fsync()
** the directory after deleting the file.
*/
static int unixDelete(
sqlite3_vfs *NotUsed, /* VFS containing this as the xDelete
method */
const char *zPath,/* Name of file to be deleted */
int dirSync /* If true, fsync() directory after
deleting file */
){
int rc = SQLITE_OK;
UNUSED_PARAMETER(NotUsed);
SimulateIOError(return SQLITE_IOERR_DELETE);
if( osUnlink(zPath)==(-1) ){
if( errno==ENOENT ){
rc = SQLITE_IOERR_DELETE_NOENT;
}else{
rc = unixLogError(SQLITE_IOERR_DELETE, unlink, zPath);
}
return rc;
}
#ifndef SQLITE_DISABLE_DIRSYNC
if( (dirSync 1)!=0 ){
int fd;
rc = osOpenDirectory(zPath, fd);
if( rc==SQLITE_OK ){
#if OS_VXWORKS
if( fsync(fd)==-1 )
#else
if( fsync(fd) )
#endif
{
rc = unixLogError(SQLITE_IOERR_DIR_FSYNC, fsync, zPath);
}
robust_close(0, fd, __LINE__);
}else if( rc==SQLITE_CANTOPEN ){
rc = SQLITE_OK;
}
}
#endif
return rc;
}
- --
Andy Goth | andrew.m.goth/at/gmail/dot/com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTrw9vAAoJELtYwrrr47Y4zBYH/33YGML0DtTSaVnNsaatW3el
zjnFj8CwjYmsxlV9mrmbbw0gS/se0eHr/aMPF1XygS6oCZWEDwBsHaplvLldbkJB
XTJHbAbFUNizD4xaM3sKb28nexNjLQ4fp/Ks0dn9IdHU7u5N3ObWTucz0QFBeoEA
FLDz4hGnhZFD4BBstlllOYXzttL/MbnNH/6qDzGarOK+WzlVJoTjNmkOBRJCWMs7
17NH0W4YOcG2j2KM2U8QSDo1QkX3wO+UDiB9crNQRzc1HU+D9puNrbUPYqt/fMws
zwOwOSlMlVoxCQikqYaH1Qs6CgEOI+ftQ1FJD4/c7cgiI2PB7GYAQ+quryYj8jk=
=lfYj
-END PGP 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] Problem accessing shared folder in VirtualBox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/28/2014 5:16 PM, HeadshotX wrote: --- Original Message --- Is there any chance that it will work like I tried it first? SQLite is quite strict with the filesystem, and it needs it to work as advertised, for example with syncing and file locking. VirtualBox is just not there yet. Go bug them. Give them a tiny test case, a sequence of commands to create a repository and try to open it. Thank you for the detailed steps, I will write them to the VirtualBox team. Just one last uncomfortable(?) question: Why does everything work as expected in version 1.21 of fossil? (As long as I use fossil v1.21 it works, but as i use v1.27 or higher it gives me the initial mentioned error.) Or more specifically: What changed in the sqlite3.c file that causes this error? I did a bisect to pinpoint the fault. This is Fossil, after all. $ f bisect status 2013-11-19 13:09:40 6791ad1185f374dc BAD CURRENT 2013-11-15 12:58:56 1928cf526ef478b4 GOOD $ f timeline 6791ad1185f374dc === 2013-11-19 === 13:09:40 [6791ad1185] *CURRENT* Now that checkout_cmd() can handle the situation that vid==0 ([b725c1cf26]), no longer assume that the initial commit has rid=1: If the initial commit is not empty that will not be true any more. (user: jan.nijtmans tags: trunk) === 2013-11-15 === 12:58:56 [1928cf526e] Update custom makefile as well. If fossil is linked with external SQLite library, make sure it is used single-threaded. (user: jan.nijtmans tags: trunk) === 2013-11-14 === 19:36:30 [28c508679e] Update the built-in SQLite to the latest from upstream that includes the skip-scan optimization and the improved EXPLAIN display in the shell. (user: drh tags: trunk) 04:34:46 [87d5fef9ce] Set the error message to indicate the HTTP status code returned on CONNECT to avoid segfault. (user: andybradford tags: jan- httpsproxytunnel) === 2013-11-13 === 15:18:08 [40a2557f00] Minor correction to text in setup_timeline for description of setting. (user: andybradford tags: hide-diff-on- vdiff_page) How very curious! Version 1928cf works, but 6791ad fails. Yet it's 1928cf's *predecessor* that changed sqlite3.c! I can't explain this. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTr1tyAAoJELtYwrrr47Y4DKMIANsMnB8s8IG4XGvNT2m4Vy+1 dryc2S9bzcZqZkxEDlqREAO2KZTG2E2kjIa3GwKt9QBoGLzLsnbDRlzrG+K+Byha SUMRUffluCXjFyRVyeWUyI1a2LTBQYWjv6TGBZnN+j9ax04rWCjE82riSwwBKJTT OKb1Junlw9IXPvAN8aYBgzPk+FY4PE/fZUu/rVGYJIGEjacgiw0YH1Kyj0aK/Z7g 740dsYVDNsBpEsKwavrK9sHK7Fu0LYEXhPo8fwTyC/tLZ1LKqvnid8rIHJIVmkmg qkTk4mFiWc6WruyM5qxcfsEaDELWEzn0WWG1iUbrRD6tYdfigclp5uRCuU0KEhg= =wXO5 -END PGP 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] strange event UUID's in fossil timeline output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/1/2014 3:07 AM, Jan Nijtmans wrote: $ ./fossil timeline -t e === 2013-08-26 === 07:35:00 [94694585cd] Compare this with the uuid's in the following web-page: http://fossil-scm.org/index.html/timeline?y=e The UUID's are different! It looks like the web-page is correct, the UUID's in the fossil timeline output are the UUID's of the corresponding manifest corresponding with the event. This happens for event UUID's only, other UUID's don't have this problem (that's probably why no-one noticed this before) /event/UUID URLs for the above UUIDs don't work, but these do: http://fossil-scm.org/index.html/info/94694585cd http://fossil-scm.org/index.html/info/22c9d9a61f http://fossil-scm.org/index.html/info/60c7229505 http://fossil-scm.org/index.html/info/dfd6e05ab2 http://fossil-scm.org/index.html/info/82cdfeeffe As you say, event UUIDs are different than event manifest UUIDs. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTssipAAoJELtYwrrr47Y4b4wH/A8LvotedqunF4+1ryysQ7s1 GI3BlzrZVGdw3eZUgxlGrYbiLA4YREi+g60wwjSb9jiFKlFbUlg24qe9lJU1NsHb Bh+2QHJfQJf+pOnXEWXHXdHKKPsiB1FXXh3Md1WubVwuJnO/NRXQ2Vz1ENi85Emg fbCcksD2ZSSgmAwT2cJ91PntN2XmXoFLgCPejIYFirV+e6+1LPF3hnqAfOrxHA3S 56fgoywYINRjojgMpBXTg+bWq/ZLi/q3jxCAc3VJFNGdf1MjkfMDmiYy7F+9JfEN lWN4ITGV18Bb1R7JixBLtR31s60/vIdsLzi5BztAPurqWj9acVshDq1nrAFIPgo= =ft+E -END PGP 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] [fossil extras] versus symlinks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In one project tree I have a symlink pointing to a directory outside of the checkout directory. [fossil extras] lists all the files in the referenced directory as extras even though they are not actually part of the checkout. I think they should be omitted. According to the -n option, [fossil clean] would remove the files. That's rather serious. I think symlink handling needs to be reevaluated. Symlinks to files and directories outside the checkout definitely need to not have the effect of the referenced files be treated as if they were part of the checkout. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvZaWAAoJELtYwrrr47Y4gtMH/01FYqNHdXIRXVdY3weMsk73 bXIl5Ud3FRBedRAPNoPEam5NGqFwkS+jGdZFWZqa7mM+xif37tuARtnEqGuIdzUi SDcVNsBggENWA4YxlIiYBjL5Ds9Q3sOq7Vt2wvRPrzD7cLwntatn4uKfOH69VPFW cIcB0aDIWEzVgFN2p29uaONnJQyLWB1A9fYFOgGr5VruZcSYkdYMb5PI7C1pmYw3 zAiq79DAeykP1oxeH158mnG5Cgwu7GWRHkNjFIRWW34E5AHxITyCfXdMD5YeVlNa YitbhISlA0rr4Cavsyn0DOdljj26uGOP5R3yI9y4iM9Hr2jGZC+ZawZzXwjXQlM= =V7hm -END PGP 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] [fossil extras] versus symlinks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/9/2014 2:29 PM, Stephan Beal wrote: On Wed, Jul 9, 2014 at 9:23 PM, Andy Goth andrew.m.g...@gmail.com wrote: I think symlink handling needs to be reevaluated. Symlinks to files and directories outside the checkout definitely need to not have the effect of the referenced files be treated as if they were part of the checkout. Which commands are most seriously affected? - clean - extras ? addremove perhaps? I've been afraid to experiment because I don't want to jack up my repository. Since this project's awful build process hijacks a bunch of checked-in files during compilation, I've been explicitly listing the filenames I want checked in when running commit. So I'm already having to force Fossil to not just grab every file it thinks is appropriate. Yeah, I definitely want to fix it to not hijack everything, but budget for that sort of improvement is sadly limited. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvZokAAoJELtYwrrr47Y4U10H/0p692oitOos21RbBE5OTrzy MN7mWLakmh6xyIFNEyBYfxedNxS5wj9Jxh7dqhglm0xpTjvzYI8+jJEu7BaylkRm y/Pze9YB7+nqLlK79fenFmZwj9e14lBIty/D4eSxW8sF/IopRjPVvzqHXpdWAQEV 75ujTgw2Vbd6QPI6VFMtubVov2tgAuAkFIc8TGHV+5hMiadmxUQ6vl+qV6h03M8W CyR09k6cWJMt71tSx2q5rXjDJfVRAcub5KvppYj+Su0m7MJgdH3eHjdedwGM7Tcr GWCqfm+1OvIAxs22IS3f5IZnw3OB3t1EI9CZRYFcdITwXQxrrIB5DSTSsXRHO3Y= =ce98 -END PGP 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] Unusual timeline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://fossil-scm.org/index.html/timeline?p=92c2c1e5e18b19c5b05ea5684feb0bbeeb6670fd What's going on here? Everything is tagged trunk, yet [b4a53ba45f] is displayed as if on a branch. Was there a fork or something? - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvdUYAAoJELtYwrrr47Y4i1kH/RpWjlJEKTL8uSrPy37I6r8a U4mXIbS5CEFu5lLuMS/4R69V9v5xV5+UoTAR6rziCXj2m9oeGxZQAH3Zhu1U5LCB BKqkBqk1WcfzgELqdXnWEqcLgfTmpOfUC388n75vWrmQHSIOzdKmFHKk8M3/giFX etQJTuqAujsgS03/4Vz/a3DEtfe5SiNoEGl15HNKXuFnIH0UfaeGquwR622+atsT 22kjPdxvCpVPnUrMNeOqtEfljp5CcsxxwcXTmelY5m1zxJT+W2Lu7P5y1sd2L9Yn nj5UR7blgJ3T1cnUHioSrvVSU8cbEf8F0KuIRcTlb3uF+cu+iBrew3HM5JJoyq4= =H1a/ -END PGP 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] Fossil terminal I/O to custom terminal in Windows
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wrote a simple custom terminal program demonstrating how to work
with stdin/stdout/stdio, available on the Tcler's Wiki:
http://wiki.tcl.tk/3543 . Right now I'm finding it to be useful on a
system at work that halfheartedly hides cmd.exe in the name of security.
Even though it works with lots of standard programs like dir and type,
it completely fails to capture the stdout/stderr of Fossil. Whenever
I try to run Fossil, a window flashes onscreen for just a moment.
Is there any way to instead capture Fossil's stdout?
Here's the script from the Wiki, modified to use cmd.exe instead of
csh as the shell:
package require Tcl 8.6
package require Tk
set shell [list cmd.exe]
proc log {text {tags {}}} {
.output configure -state normal
.output insert end $text $tags
.output configure -state disabled
.output see end
}
ttk::entry .input
ttk::scrollbar .scroll -orient vertical -command {.output yview}
text .output -state disabled -yscrollcommand {.scroll set}
.output tag configure input -background gray
.output tag configure error -background red
pack .input -fill x -side bottom
pack .scroll -fill y -side right
pack .output -fill both -expand 1
focus .input
lassign [chan pipe] rderr wrerr
set stdio [open |[concat $shell [list 2@ $wrerr]] a+]
foreach {chan tags} [list $stdio $rderr error] {
chan configure $chan -buffering line -blocking 0
chan event $chan readable [list apply {{chan tags} {
log [chan read $chan] $tags
if {[chan eof $chan]} {
log EOF error
.input state disabled
chan close $chan
}
}} $chan $tags]
}
bind .input Return [list apply {{chan} {
log [.input get]\n input
chan puts $chan [.input get]
.input delete 0 end
}} $stdio]
- --
Andy Goth | andrew.m.goth/at/gmail/dot/com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTveDAAAoJELtYwrrr47Y42uMIAOc6LvK6PzZQyLKWDbRNyesh
pWDHQzcV9Q0a5rpdAr5ij+5tvpaMn4Rn47DTDosIlpAQ9VYT4o34wQ1EPc06CW1r
GXddlsubLjG7ho2bfoDKfM9ofwX6LwGhdBwv6S7wsi7uGooXrqWg+ycsSF3nR3Wb
6TPKNiFU/3yaT2p7yiD0+upDNuVyNYePOzRVpEU+bhCS5rW3tazeAh6eJP+bdNZh
zPivibNJ2t1UO2Ew5mPTGWr8RFSPSaQwTYcYkjjur6D1cqC/f2rH0yKHi0FUVSCe
d+iv3oPtraxG8BztyoszHDfMfa4SU45hhryDayRvfTEcnAnfBRN83eFTBQNwHtU=
=V+tr
-END PGP 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] /info/ versus /ci?name=
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What is the difference between the /info/ and /ci?name= URLs? When followed by a check-in artifact ID or unambiguous prefix thereof, it seems the only difference is /ci?name= shows diffs and /info/ merely offers to show diffs. The problem I have is using the edit link on /info/ returns me to the corresponding /ci?name= URL when I apply or cancel. It's rather jarring to start at a page not showing diffs, go edit something, then be returned to a page showing diffs. Actually it can be more than jarring. A few of my commits are monstrously large with diffs that are dozens of megabytes or larger, so of course I wouldn't want to see all those diffs. But nevertheless, they are pushed in my face after doing an edit check-in operation. I know it can be tricky for the edit page to return to the same diff options (hide/unified/side-by-side, show/ignore whitespace), so the easy way out, which I would be happy with, would be to always return to the /info/ page which hides diffs but makes them easy to obtain again. By the way, I also find it curious that /info and /ci can be followed either by /ARTIFACT_ID or by ?name=ARTIFACT_ID with the same result. Is there any particular reason why both are supported? I also see that these two styles are used by different parts of the Fossil UI. Is there an explanation for this apparent inconsistency? - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvguFAAoJELtYwrrr47Y4AhQH/2Y/i+t6NDh7i14H1tno9BfA +7nqarD83/QdqyqWUP5+P23RbET/BqoqTW0BFafF6V2Z7UvvgOE2o1bSflg7TgXt x17ymscDfUTl9O+fLOacNHy5sK/K8xQHT0K5ii0UMrefgw3ZpPLEvAXPAOB4uv9/ v+T78KtkHxO0yglSYCA5MsNIxqbkki6uKxaTYhAQNg4mZRpGTOiN9+sT7ac4nCuQ Fg4XpHPHLAiWpG6sGFiSSVnn46D7ZGBm0K21E0dLkKyVJOGD0oOXVm+OJ1divxuI 9wepvkWAtarev20sft1fptHOrfEBBfcO+dQFkh0OJhzPQdJEOhEUAUQO7mfGnLQ= =GscD -END PGP 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] [fossil extras] versus symlinks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jul 10, 2014 at 9:52 AM, Matt Welland estifo...@gmail.com wrote: What is allow-symlinks set to for you? From context it sounds like it is set to yes. If so this is *terrible* behavior and a bad bug. If it is set to 0 (IMHO an awful option that is default and should not even exist [i] ) then I think what you are seeing is the expected behavior. It wasn't set at all. I set it to 1 and now Fossil no longer follows the symlink. I'm okay with this. The default is 0 (no) which is what I was getting. 1 (yes) is the fix. On 7/10/2014 12:01 PM, Matt Welland wrote: An additional comment: did you perhaps have allow-symlinks set to 1 in one clone? I hadn't set it anywhere and was not aware of this setting's existence. The allow-symlinks is either flakey or not sticky (I don't recall which) and you have to set it anew on every clone. It is versionable, but I don't have a .fossil-settings directory. I don't think I should add one either because this is actually not natively a Fossil project, but rather one (mis-)managed by ClearCase. I'm just using Fossil on top of ClearCase to help inject a little sanity into the system. Adding files into ClearCase is normally difficult, but in our organization it requires us lowly engineers to petition the head of the CM department in order to add a file. It's unbelievable. I suppose I could start putting files into Fossil that I'm never going to ask to be added to ClearCase, but this could get dangerous. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvt2UAAoJELtYwrrr47Y4gE4IAJrXrPafeyvGGMhJrs8R2Kdj UjwxrExOFzlQ0QmCdbj/xvzQ/eRXYAccmqPa8KN9jHzg2Zyh8dSmnkqQVYdUmr9b U3gAj/T6theKoXDNw5Q8WPxeHuTXMY+7rbXMK6SgVycfguI6BYC4ZvUJhptOy7J8 E/kumwYDBjtGIFkerRfQ2y9LmThwkyqrUZJw/TSl076JpAj+o8sJHmSgM2VQ+s/f 1FUqQxs02HIxu+glr/pVDITUgeNHL1Ura+3ihM64emA/F78+3QYe1Wx29xUYSAN/ fzKvrZD/DAsjj0Nsd4LSwqhC83t9fDzBXjXbNQ+OcN2l+1Vs1XSMlAQdmzZgmNw= =t68w -END PGP 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] Visual indication of cherrypick and backout merges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At work we use ClearCase version tree merge arrows to visually indicate what Fossil calls cherrypick and backout merges. For a cherrypick merge, we draw a merge arrow from the contributor version(s) to the new version. For a backout merge, we tend to draw a merge arrow from the version just before the contributor. For whole-branch merges, we draw from the last version of the contributing branch. Of course there is ambiguity, but the presence of merge arrows clearly indicates that a merge of some sort took place, and the check-in comment tells what is meant by them. This is very helpful for glancing at a tree and seeing which projects picked up bits and pieces of stuff from which other projects, where projects are represented by separate branches but otherwise sharing files. Fossil doesn't quite operate this way. It has very easy merging, and it gives good visual indication of merging entire branches, but there's no visual for cherrypick and backout merges. The check-in comment can name the (positive or negative) contributor version(s), and those names are clickable links in the UI. But that's not quite enough, in my opinion. I want to see something in the timeline plot showing cherrypicks and backouts. Dotted, dashed, and/or colored lines might do the job. I also want to see the origins of cherrypicks and backouts listed in the family, ancestors, and both timeline links on the check-in info page. Let me make a request. If this feature is added to Fossil, I would like it to be possible to edit the cherrypick and backout merge arrows after the commit is complete, in the same way it's possible to edit tags. (Perhaps this could be implemented as special tags rather than as a new card type.) Many times while researching old code I've found engineers weren't always careful with documenting where they got code from, and I was glad I could add (or correct) merge arrows years after the fact so that we wouldn't have to repeat my research to determine the origins of everything. Knowing the genesis of every part of the code is quite helpful, for instance to find the original requirements, user desires, supporting documentation, test procedures, or responsible engineers. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvuk9AAoJELtYwrrr47Y4CKoIANdHjSArVKEZeYq4gx+iWZsV 5jrkam5E1hVGX/uIyIdY8+EwBDta77ZLbWEK99bNobD5U1bypX6tKCNclyTiOtWD sPut0KtwhKp2Xf4WjNJpmpAeRGo2j8hXVHBkamGH9Nj+2f8aJd+80O4fFCTResCs OLETnTkZFmDeEU78UyJ/fsTsskrlrG1fEaPnm3ZWP4Ae41k7MUNU6YQ3iTlrqHsm JS+x8gIAjcuslv+e/Ay24c1+1X54BH559fYHID7GTjXeeCwBdz0X8qL/NcLFF1sL LqQuS0/baHyZfXjSOTV++l7HZim2obmyZig8gv8IWEdtEqv5iWo2AuRAAjIwLYE= =oHLx -END PGP 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] Visual indication of cherrypick and backout merges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/10/2014 2:37 PM, Andy Bradford wrote: Thus said Andy Goth on Thu, 10 Jul 2014 14:27:57 -0500: I want to see something in the timeline plot showing cherrypicks and backouts. Dotted, dashed, and/or colored lines might do the job. I also want to see the origins of cherrypicks and backouts listed in the family, ancestors, and both timeline links on the check-in info page. This has been brought up before (I specifically mentioned that it should be possible given that the cherrypick merge is recorded with a Q-card), but this is probably low priority. :-) I'm putting together a mockup screenshot illustrating a few ideas and motivating this feature, but it's not ready yet. Can I send it to this list as an attachment, or do I have to host it somewhere and link to it? Let me make a request. If this feature is added to Fossil, I would like it to be possible to edit the cherrypick and backout merge arrows after the commit is complete, in the same way it's possible to edit tags. (Perhaps this could be implemented as special tags rather than as a new card type.) I'm not sure how this would work given that the source of the cherrypick is stored in the Q-card and is not alterable thereafter. It would seem to me that it shouldn't be possible for a cherrypick to be incorrect, or there's a bug in Fossil so what sense would there be in being able to edit it? Not all cherrypicks and backouts are done by [fossil merge]. Around here, lots of things are done by hand. Having better tools than what we have could help to improve matters, but there is a lot of inertia, habit, and general unwillingness to learn how to use the available tools as intended. Therefore it won't be possible for Fossil or any other CM system to always automatically know what merges have taken place. I don't know anybody who uses the merge tool that comes with ClearCase, so I really can't expect everyone to consistently use [fossil merge], should we adopt Fossil. What do the Q cards accomplish for cherrypicks and backouts? First off, am I right in assuming that Q + and Q - correspond to cherrypick and backout? Okay, so does this information get used for anything? It doesn't seem to be displayed anywhere outside the manifest. Tags and comments are editable, and this does not confuse Fossil. It knows not only the original tags and comments but also all edits, and it displays the accumulation of edits without losing track of the originals. So I don't see why Q cards can't be edited in the same way. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvvQPAAoJELtYwrrr47Y4zr0H+gPhLCHL6X7lPKCn6mKbYJMO /EdPl6nf3m9Vw4be50cj8uez1ZWxeGEkgjbG6P+/xKdfq6h81O/N6TbFpxZA2tgP kNYbxR1DQzpmC7rVrKcUA7h5j99LpuX32Y0jhgDChuyS1XgE0+y31B8r+JZy7WNC aU+NwJ+t0N2WQL2SS+/Js32C7O7WdegkKvgeuGxGcbqnUEn9up8eL/DTWtD+aFCb 9gSn26yHfsabQ1+jdRupnvBu2kP0YkCOjRyGemtg9vS61TrSBqwtKCM+5jNABI7L uf/f0kvU7WhgtB/47GfyBh6kwLq3MvhWt0Ix9oChMbtb2DoMIp2vAXWsQc6ASNo= =F7bT -END PGP 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] Visual indication of cherrypick and backout merges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/10/2014 3:14 PM, Andy Goth wrote: I'm putting together a mockup screenshot illustrating a few ideas and motivating this feature, but it's not ready yet. Can I send it to this list as an attachment, or do I have to host it somewhere and link to it? Let's just try it and see. Since the Fossil timeline arrows are constructed using rectangles made with explicitly positioned divs, it would probably be easiest to just set the color of the arrow rather than use dashed and dotted lines. So that's what this mockup does. This representation clearly shows the relationship between branches. It also highlights the fact that commit 58b4 has *not* been merged from trunk into proj2. That's what it means for the arrow in the top left to be green (cherrypick) rather than black (full merge). - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvv2cAAoJELtYwrrr47Y42z4IAK74VHJl4uL7cloWIhciHTju x4z2NhsQqwl5tQ67J1YyDHo0NIalGQxbG16ihzV7xWosmYe+l4+E/tY5kQ3EZohh 80/FI2XqxtDLbvczh3k2mcY/5kR0KXFmQ5Noxzxw+hB73Vl2u+Rla+t/H2FuXKWS jCcxrTCASh7mi8Ugl/c0lP9il2qP2T8oLT4mvfJpxilDpy55UcbTHXW7+V/WOu1e DXSU2kHQ95vBVW1kJUCtEWF2EsUJ/TG6jOumcpO94s4Zx212nG/5Zt7T0erCr/NK z6jIz2B0XEiMNnv1QpcsPQjqBqNxbDWnErzhJXj08P0G8G1NpP77HpQKdxw7o9I= =3Ahu -END PGP 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] Visual indication of cherrypick and backout merges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/10/2014 5:22 PM, Stephan Beal wrote: On Thu, Jul 10, 2014 at 11:01 PM, Andy Bradford amb-fos...@bradfords.org wrote: I see, I think I've misunderstood your proposal. You aren't suggesting that the Q-card stored in the manifest be changed, but that it be allowed to be superseded by another manifest that has different information than the original (this is how propagating tags and edits work). That's a fair question, not one that I think I can address. :-) If that summary indeed reflects the goal, i _think_ it's just a matter of changing the timeline query to do so. Looking at the code now, i see that graph.c is quite a bit more than a timeline parser, though, so maybe it's not as straightforward as changing a query. Yes, this is what I'm going for. (1) Show cherrypicks and backouts in a manner similar to normal merges but using a different color or dash pattern. (2) Allow cherrypicks and backouts to be edited by later manifests the same way comments and tags can be edited. (3) Include cherrypicks and backouts in the ancestor/family/both timelines, the same way merge contributors are shown. Not sure if my image attachment made it to the list, but here's a link to the mailing list archive which may work too: http://lists.fossil-scm.org:8080/pipermail/fossil-users/attachments/20140710/35580a49/attachment-0001.png The image doesn't show any examples of backouts, but I imagine they could be red. The line/s would come from whichever commit/s is/are being undone. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvxmmAAoJELtYwrrr47Y4NDYIAKUzDFyQyJ5pjMLpktcpko49 MzWmchZL9q/EhBBdMdWtL4jP8/aK4fA4Z28FsZEPazjsX30Md7WzrguAGC138dX/ ZY7+D9sLScvAK9NJOxsMJ251fjehSlBGqb9n5Bb6ujEf5hF2kKJebtOUZaEfRoIa 3gQMuUv8YrxSFNH5uR0IoQJaUj6+zHygwafXZvRbbmD8SgE3xW+nSSv29+pki/6T DnUQjgQWm4mkL/7KS85h+ArSMH1k05K/mxgupZjivXDUVMUT/0ygBjP17vQ52BFt SfMSAtEYIuQCe1DzeNmgnSvyR3enC/k8o98wSExsipx5qUo/zN7D7yxCXq32kk4= =43ec -END PGP 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] CHANGED versus EDITED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When a file has been modified, [fossil diff -brief] reports it as CHANGED, whereas [fossil status] reports it as EDITED. Is this inconsistent terminology intentional? What other inconsistencies are possible between these two commands? I would have thought they'd share the same reporting code. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTxJf3AAoJELtYwrrr47Y4ZEEH/3liMbB50goRpnrVTHsRbGc1 oYTHsqDz+n9Ipd9a7yloLvKk4dljkFFeZ38EjgMOCC6MXLFQUjsgLQi7A0CYjuuP Fzd0NB0a/LrK2CHyLlGEvUozL5IRH4h/gGkNqNPG2/ZETPLsDEhHnl5HA9xnhGSq 2AUmeSvIZKYQ1rk/lAbUCP7QGWfTSQIY34+sJvFo8eqsxPhnGWgAQESmT7iti/Cn qQyGSVe0dxn+Q5Q729RqbhkPyciPQo6+ZZiyIrxsDCD5Y12tdqe9w+/VqIGWcFlI hUYaIfkQ+U6sK6A71hieL+5uMLSP5jV3ZaFEH/Z8zmrTiC0fbGjeTKBSzsnzSBE= =nNVq -END PGP 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 item limit when viewing branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://fossil-scm.org/index.html/timeline?n=20ndr=trunkc=2014-07-16+23:01:54 Despite the n=20, the timeline display limits itself to eleven items. In my experience, using the r query parameter causes the timeline limit to be roughly half what is requested. To actually get twenty items, n=38 is needed. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTxzbRAAoJELtYwrrr47Y4GP8H/RIx6wNM/yhAWuUZ64kdTOSk em1edsPrfJzdGmL/t3ijhhT/Nlb1jRrF7c0bMkyPUuXkFlCLkgJywK+HPhSs++P7 QkIGeO36u0LvO23CWwjZPTa48qyYd9ADmOIfipZxLLEjmCRafGJ/XIik2nBsx1jB cnN/ihKNmzq6MHPG34XLDw4oOMbv+zG/eifZmXF9a5dkTgQc6q4/1fhJMRwIavAh ZND1v8jB3S2r6ejPxNeQTZC5XgPbsNQmEl5/kixp7gKSe4GHEnpUWH1Q3BtUdaT5 x9HDsxBo4+X0hvqIYrqMZfcbtz3zrbvtFq7VcrbKAuuwyjSDvtMnn4e3ZjDtcDE= =9Pts -END PGP 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] CHANGED versus EDITED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/14/2014 9:54 PM, Andy Goth wrote: When a file has been modified, [fossil diff -brief] reports it as CHANGED, whereas [fossil status] reports it as EDITED. Is this inconsistent terminology intentional? What other inconsistencies are possible between these two commands? I would have thought they'd share the same reporting code. I see [fossil changes] also says EDITED. Looks like [fossil diff - -brief] is the odd man out. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTx1IEAAoJELtYwrrr47Y4ts8H/iuuoG1nHJDGqz9nPByTc1vB F9OHYjh37fZjqX+GEJYsQyPahds4Wbd3nVg3crizSZIHlrKROrqo0fWKYP5HzlKy LefgTsW7fB0AibTXxc5+oEh8s0LI7jsF9x5gpshSXqTs2b6FNmbVYZ+bDJmGTIt6 W/qLwn3xVxBtphV52FxeUqZl2csJj/3Y2UOJtGXuHGqBT/jZE526HvbBREgZl51j kfjKSoorfkiE82qF8QDdXnKhVCzRK+QYgT1AscGaKGfjLk8IBuE39v79CReUVegH jZ+hxLYJpjx4YXneWGC90o1r4blX4WlijA5ko5YudELPVqj8VvwlDaMYXgv5JBo= =foqR -END PGP 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] libfossil: new script binding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/17/2014 3:22 PM, Stephan Beal wrote: in terms of memory use, it seems to be on par with lua, and lua is the lightest-memory interpreter i've yet run through valgrind. Most of them individually leak more memory than lua and s2 allocate combined. Sorry to drag this away from Fossil and TH1 and S2, but I suggest running Tcl in Valgrind sometime. It's very, very good about memory usage. Aside from interim development versions, the only leak I've found is a performance optimization in which it doesn't bother free()ing everything on exit, much the same way Fossil doesn't clean up because it knows the operating system will do it faster and better. There's a compile-time option set via preprocessor to make it go back to the old behavior of tidying up all allocations at the end. This is very important to me because I frequently use Tcl for testing other code written in C and Fortran and such, and I need Valgrind to spot my errors without being mired in the test harness. http://wiki.tcl.tk/3840 - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTyDQYAAoJELtYwrrr47Y4iBkH/j3cBBloLwFAxigrX8xhTydy I1c++agxS/veY0kdWoXqbnRYTluHXGlLy4JetWEOk3PmkgNa3EBZRsVtuUSRiqdl gpD1R0kP+7izLDlZuPKXWBjQNtdeAslSTcyuIFQVWTfHa1gFKT12GQ5oKuwo98yi Zl2uxhq6vgZK4cX3zg/S2SH2QA4avdMFJRxmBUXeBil6wqpr/oYKznD4kxtmTsEy zSysbC6Jz0l6dIbh+whAgNxhhf6QroItCwqCHtfeWBHkx05KCzUddXKizX72ggrz 0aIu1loCz+Kb5v7JHnG8n8lzySTtKIBb0idUW5t1WCTmgJHyPrdLDvgmYrzOgBY= =XwRk -END PGP 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] Ticket attachments sometimes redirect to home
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When viewing my local Tk repository clone via [fossil ui] or [fossil server], accessing any of the attachments for this ticket: http://core.tcl.tk/tk/info/45bc2252066b706bfea8553c34b13a92ca3bbb3d results in a Location: header redirecting my browser to the home URL. However, when viewing the same repository via the above link, the attachments display correctly. It's not my browser, since I have tabs accessing both the local and core.tcl.tk repositories, and I logged out of both to keep things the same as possible. Yet there is still a difference in behavior. The same issue appears when accessing the attachments via the timeline (must have All Types selected). I tried downgrading my Fossil version from a0c8a0869d to 6728a8bd08 to match core.tcl.tk, but the problem persisted. I simply cannot see attachments in my clone of the repository. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTyDXFAAoJELtYwrrr47Y4108IALlPHiqEPN7T2QfL8rNG56nR h5DrDsLDBYhpPVupDbHcofYnxYQdJ5ot0aIgfR+nRhlArg64Zl1KP+e62YPfIGex omMjuxeOpCxQT2g6aSTDnNl0dhmf9fPxLbaIKSjLpVCuUe7AES8eAYbhb/WQ++uB t0fNA3c5WSh/5a4D7AaNXWRMye3ngp25ZelZD9o7gpCV44PhWu/iukGIuZ9jF9CS 7rqQBjvKV30trBYsrBeOyeKWl4ow6F7R3NdLqse/4jTdCcflHwyEd60Hc57XF3a4 zTTvbBPTYW5i1/vV0BrYNvRGZ4sbU6yHLPXMcENGTn1gekZwOaqWb1H+CIaARLQ= =FxTb -END PGP 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] CHANGED versus EDITED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/16/2014 11:33 PM, Andy Goth wrote: On 7/14/2014 9:54 PM, Andy Goth wrote: When a file has been modified, [fossil diff -brief] reports it as CHANGED, whereas [fossil status] reports it as EDITED. Is this inconsistent terminology intentional? What other inconsistencies are possible between these two commands? I would have thought they'd share the same reporting code. I see [fossil changes] also says EDITED. Looks like [fossil diff -brief] is the odd man out. Furthermore, I see [fossil changes] and [fossil status] respect the relative paths setting, as discussed in a previous email Inconsistent paths replied to by Jan Nijtmans. However, [fossil diff] and [fossil diff -brief] do not honor relative paths. Once again, [fossil diff] is the odd man out, and I remain surprised it doesn't share the reporting code with the other two commands I mention. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTyEAXAAoJELtYwrrr47Y4UfIIAJqSOs8sNiIzudRITcHH8Td/ kLWBtUePwwCl87pI6kxV9gt6lL68gqvH53JiBlxvCd62HpEPnumxeEPTEwTXjjZF dLB7KjrgNFVq4k4JtsUcz1H2EV1Zs2Q4l1/f9U21HB5kcE6DgfBmAe3mlC/ZmyOl 3JnAwf6Dh9ljIHN/LszGWTTk90YgKCJgj2A0gPASYxtxKjuBXcleULvNqgfBLIoU II9yVTRxDavyQX7VV+Ii/Ebh8o/oR9F7WkURK7Cg/FEB1HG2noduFa5PGNKGBE/e DJJ1WcfGhOcXx5Zm1iqYg+HwbMQvEvxBzAY1dO4isqR3C8Fngr9QozQUywIau4E= =RP5D -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
