Index: src/report.c ================================================================== --- src/report.c +++ src/report.c @@ -749,11 +749,11 @@ /* Output the separator above each entry in a table which has multiple lines ** per database entry. */ if( pState->iNewRow>=0 ){ - @ nCol)>  + @ nCol)>  } /* Output the data for this entry from the database */ zBg = pState->iBg>=0 ? azArg[pState->iBg] : 0; Index: src/stat.c ================================================================== --- src/stat.c +++ src/stat.c @@ -421,13 +421,13 @@ ); } fsize = file_size(g.zRepositoryName); approxSizeName(sizeof(zBuf), zBuf, fsize); @

Repository Size: %s(zBuf)

- @
+ @ piechart_render(800,500,PIE_OTHER|PIE_PERCENT); - @
+ @ if( g.localOpen ){ db_multi_exec( "DROP TABLE temp.dbx;" "CREATE VIRTUAL TABLE temp.dbx USING dbstat(%s);" @@ -450,11 +450,11 @@ ); } fsize = file_size(g.zLocalDbName); approxSizeName(sizeof(zBuf), zBuf, fsize); @

%h(file_tail(g.zLocalDbName)) Size: %s(zBuf)

- @
+ @ piechart_render(800,500,PIE_OTHER|PIE_PERCENT); - @
+ @ } style_footer(); } Index: src/statrep.c ================================================================== --- src/statrep.c +++ src/statrep.c @@ -340,13 +340,13 @@ "CREATE TEMP VIEW piechart(amt,label) AS" " SELECT count(*), ifnull(euser,user) FROM v_reports" " GROUP BY ifnull(euser,user) ORDER BY count(*) DESC;" ); if( db_int(0, "SELECT count(*) FROM piechart")>=2 ){ - @
+ @ piechart_render(700, 400, PIE_OTHER|PIE_PERCENT); - @
+ @
} @ @ @ @@ -501,13 +501,13 @@ " WHERE ifnull(coalesce(euser,user,'')=%Q,1)" " GROUP BY 2 ORDER BY cast(strftime('%%w', mtime) AS INT);" , zUserName ); if( db_int(0, "SELECT count(*) FROM piechart")>=2 ){ - @
+ @ piechart_render(700, 400, PIE_OTHER|PIE_PERCENT); - @
+ @
} @
User
@ @ Index: src/style.c ================================================================== --- src/style.c +++ src/style.c @@ -1318,10 +1318,15 @@ { "table.label-value th", "The label/value pairs on (for example) the ci page", @ vertical-align: top; @ text-align: right; @ padding: 0.2ex 2ex; + }, + { ".statistics-report-pie-chart", + "for the /reports pie chart", + @ display: block; + @ margin: auto; }, { ".statistics-report-graph-line", "for the /reports views", @ background-color: #446979; }, @@ -1429,10 +1434,15 @@ { "span.snippet>mark", "Search markup", @ background-color: inherit; @ font-weight: bold; }, + { ".search", + "Search form", + @ display: block; + @ margin: auto; + }, { "div.searchForm", "Container for the search terms entry box", @ text-align: center; }, { "p.searchEmpty", Index: src/user.c ================================================================== --- src/user.c +++ src/user.c @@ -540,11 +540,10 @@ style_submenu_element("Newer", "Newer entries", "%s/access_log?o=%d&n=%d&y=%d", g.zTop, skip>=n ? skip-n : 0, n, y); } rc = db_prepare_ignore_error(&q, "%s", blob_sql_text(&sql)); - @
fLogEnabled = db_get_boolean("access-log", 0); @
Access logging is %s(fLogEnabled?"on":"off"). @ (Change this on the settings page.)
@
DoW
@ @@ -569,11 +568,11 @@ } if( skip>0 || cnt>n ){ style_submenu_element("All", "All entries", "%s/access_log?n=10000000", g.zTop); } - @
DateUser
+ @ db_finalize(&q); @
@
@ Index: src/wikiformat.c ================================================================== --- src/wikiformat.c +++ src/wikiformat.c @@ -1996,11 +1996,11 @@ ** Attempt to reformat messy HTML to be easily readable by humans. ** ** * Try to keep lines less than 80 characters in length ** * Collapse white space into a single space ** * Put a blank line before: -** 


+**          

 **    *  Put a newline after 
 and 

 **    *  Start each of the following elements on a new line:
 **          
    • 
 **          
      • 
 **

Index: www/branching.wiki
==================================================================
--- www/branching.wiki
+++ www/branching.wiki
@@ -1,16 +1,17 @@
 Branching, Forking, Merging, and Tagging
+
 
      Background
      
 
 In a simple and perfect world, the development of a project would proceed
 linearly, as shown in figure 1.
 
-
    
+
    
 
    
 
    
 Figure 1
-
    
+
 
 Each circle represents a check-in.  For the sake of clarity, the check-ins
 are given small consecutive numbers.  In a real system, of course, the
 check-in numbers would be 40-character SHA1 hashes since it is not possible
 to allocate collision-free sequential numbers in a distributed system.
@@ -38,15 +39,15 @@
 
 Alas, reality often interferes with the simple linear development of a
 project.  Suppose two programmers make independent modifications to check-in 2.
 After both changes are committed, the check-in graph looks like figure 2:
 
-
    
+
    
 
    
 
    
 Figure 2
-
    
+
 
 The graph in figure 2 has two leaves: check-ins 3 and 4.  Check-in 2 has
 two children, check-ins 3 and 4.  We call this state a fork.
 
 Fossil tries to prevent forks. Suppose two programmers named Alice and
@@ -77,15 +78,15 @@
 To resolve this situation, Alice can use the fossil merge command
 to merge in Bob's changes in her local copy of check-in 3.  Then she
 can commit the results as check-in 5.  This results in a DAG as shown
 in figure 3.
 
-
    
+
    
 
    
 
    
 Figure 3
-
    
+
 
 Check-in 5 is a child of check-in 3 because it was created by editing
 check-in 3.  But check-in 5 also inherits the changes from check-in 4 by
 virtue of the merge.  So we say that check-in 5 is a merge child
 of check-in 4 and that it is a direct child of check-in 3.
@@ -124,15 +125,15 @@
 When multiple leaves are desirable, we call this branching
 instead of forking.
 Figure 4 shows an example of a project where there are two branches, one
 for development work and another for testing.
 
-
    
+
    
 
    
 
    
 Figure 4
-
    
+
 
 The hypothetical scenario of figure 4 is this:  The project starts and
 progresses to a point where (at check-in 2)
 it is ready to enter testing for its first release.
 In a real project, of course, there might be hundreds or thousands of
@@ -164,15 +165,15 @@
 
 Tags and properties are used in fossil to help express the intent, and
 thus to distinguish between forks and branches.  Figure 5 shows the
 same scenario as figure 4 but with tags and properties added:
 
-
    
+
    
 
    
 
    
 Figure 5
-
    
+
 
 A tag is a name that is attached to a check-in.  A
 property is a name/value pair.  Internally, fossil implements
 tags as properties with a NULL value.  So, tags and properties really
 are much the same thing, and henceforth we will use the word "tag"

Index: www/copyright-release.html
==================================================================
--- www/copyright-release.html
+++ www/copyright-release.html
@@ -74,12 +74,11 @@
 
 
    By filling in the following information and signing your name,
 you agree to be bound by all of the terms
 set forth in this agreement.  Please print clearly.
    
 
-
    
-
    
+
    
@@ -95,14 +94,13 @@
 
 
    
 
    Your name & email:
 
       
     
 
 
    
 
    Signature: 
     
    
 
    Date: 
     
    
 
    
-
    
 
 
    Send completed forms to:
 
    
 Hipp, Wyrick & Company, Inc.
    
 6200 Maple Cove Lane
    
 Charlotte, NC 28269-1086
    
 USA
 
    

Index: www/fossil-v-git.wiki
==================================================================
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -19,11 +19,11 @@
 wiki, tickets, or tech-notes, so those elements will not transfer when
 exporting from Fossil to Git.
 
 
    2.0 Executive Summary:
    
 
-
    
+
    
@@ -34,11 +34,11 @@
 
-
    
 
    GITFOSSIL
    
 
    File versioning only
     Versioning, Tickets, Wiki, and Technotes
    
 
    Ad-hoc, pile-of-files key/value database
     Relational SQL database
    One check-out per repository
     Many check-outs per repository
    
 
    Remembers what you should have done
     Remembers what you actually did
    
 
    GPLBSD
    
+
    
 
 
    3.0 Discussion
    
 
 
    3.1 Feature Set
    
 

Index: www/index.wiki
==================================================================
--- www/index.wiki
+++ www/index.wiki
@@ -18,11 +18,11 @@
      
      
      
    •  [http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-users | sign-up]
      
    •  [http://www.mail-archive.com/fossil-users@lists.fossil-scm.org | archives]
      
    
 
-
    
+
 
 
 
    Fossil is a simple, high-reliability, distributed software configuration
 management system with these advanced features:
 

Index: www/mkdownload.tcl
==================================================================
--- www/mkdownload.tcl
+++ www/mkdownload.tcl
@@ -31,26 +31,24 @@
 Tickets
 Wiki
 Download
 
 
    
-
    
-
-
    }
+
    }
 puts $out \
 "To install Fossil → download the stand-alone executable"
 puts $out \
 {and put it on your $PATH.
-
    
+
    
+
    
 RPMs available
 
 here.
 Cryptographic checksums for download files are
 here.
-
    
-
    
-
+
    
+
    
 
 }
 
 # Find all all unique timestamps.
 #
@@ -62,12 +60,12 @@
 
 # Do all versions from newest to oldest
 #
 foreach vers [lsort -decr -real [array names avers]] {
   set hr "/fossil/timeline?c=version-$vers;y=ci"
-  puts $out ""
   puts $out ""
 
   foreach {prefix img desc} {
     fossil-linux-x86 linux.gif {Linux 3.x x86}

Index: www/mkindex.tcl
==================================================================
--- www/mkindex.tcl
+++ www/mkindex.tcl
@@ -88,16 +88,14 @@
 set out [open permutedindex.html w]
 fconfigure $out -encoding utf-8 -translation lf
 puts $out \
 "
    "
 puts $out {
-
    
 
 
 
 
-
    
 
    Primary Documents:
    
 
      
 
    •  Quick-start Guide
 
    •  FAQ
 
    •  Compiling and installing Fossil

Index: www/permutedindex.html
==================================================================
--- www/permutedindex.html
+++ www/permutedindex.html
@@ -1,13 +1,11 @@
 
      
 
-
      
 
      
 
 
 
-
      
 
      Primary Documents:
      
 
        
 
      •  Quick-start Guide
 
      •  FAQ
 
      •  Compiling and installing Fossil

Index: www/sync.wiki
==================================================================
--- www/sync.wiki
+++ www/sync.wiki
@@ -385,11 +385,11 @@
 
 
 
        As of [/timeline?r=trunk&c=2015-03-19+03%3A57%3A46&n=20|2015-03-19], the configuration-name must be one of the
 following values:
 
-
    "
-  puts $out "
    Version $vers
    "
+  puts $out "
    "
+  puts $out "Version $vers"
   puts $out "
    
+
    
-
    
 
    
 
      
 
    •  css
 
    •  header
 
    •  footer
@@ -436,11 +436,11 @@
 
    •  @reportfmt
 
    •  @user
 
    •  @concealed
 
    •  @shun
 
    
+
 
 
    New configuration-names are likely to be added in future releases of
 Fossil.  If the server receives a configuration-name that it does not
 understand, the entire reqconfig card is silently ignored.  The reqconfig
 card might also be ignored if the user lacks sufficient privilege to

Index: www/tech_overview.wiki
==================================================================
--- www/tech_overview.wiki
+++ www/tech_overview.wiki
@@ -65,11 +65,11 @@
 SQLite's [http://www.sqlite.org/lang_attach.html | ATTACH] command.
 
 The chart below provides a quick summary of how each of these
 database files are used by Fossil, with detailed discussion following.
 
-
    
+
    
 
    
 
 
    Configuration Database
    "~/.fossil"
    
 
      
 
    • Global [/help/setting |settings]
@@ -103,11 +103,10 @@
 
    • Information needed to "[/help/undo|undo]" or "[/help/redo|redo]"
 
    
     		
 
    
 
    
-
    
 
 
    2.1 The Configuration Database
    
 
 The configuration database holds cross-repository preferences and a list of all
 repositories for a single user.