# ticketchng

login: nobody
mimetype: text/x-fossil-wiki
icomment:
  Might want to consider closing this ticket, as not_a_bug, or something similar. I was definitely a little put off by the *large* number of open tickets in the backlog. Went to the oldest and found that a discussion had been completed around the topic, but it was never closed out.


login: stephan
mimetype: text/x-fossil-wiki
icomment:
  FWIW:

  [http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki#summary]

  making the W card optional would appear to be kosher in the sense that a Wiki manifest is still uniquely identifiable as such because it requires an L-card. Removing the W card sounds to me like a nice solution, but would break on older clients, which assert that the required W-card is there:

  if( p->zWiki==0 ) SYNTAX("missing W-card on wiki");

  Maybe go ahead and make it optional now (remove the assert), but don't yet place any special meaning on it being missing (just treat it as an empty page for the time being)? Then allow that to simmer for a version or three before filtering them out of wiki lists and otherwise treating them as if they were deleted?


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  Ticket search is very important for project management. I'm not sure if this can be done by customizing the ticket reports.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  as a new user of fossil (attracted by the HN discussion), I like it so far, thanks! But the lack of full text search is killing me, how do you guys find related wikis you wrote long time ago?

  I support the "fossil grep pattern" idea discussed above... thanks


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  Suggested fix in [ceb11b0787]. Setting bit 11 of the "general purpose bit flag"
  field indicates that all filenames and comments are in UTF-8, without
  it, IBM-437 is assumed. For the zip specification, see:
  [http://www.pkware.com/documents/casestudies/APPNOTE.TXT]


login: nobody
mimetype: text/x-fossil-plain
icomment:
  I originally opened this ticket. I can confirm that with fossil build based on version [3ff5ca0573] I can run test script added to this ticket on [2008-12-03 04:53:53] with expected results:

  1. file and directory is correctly named and browsable by fossil GUI (with all accented characters nicely shown)

  2. zip archive contains file with original path and file name, again with all accented characters

  Thanks for fixing this issue.

  Peter


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  Fixed in [3cadf76c3d]. Remember that in Cygwin, all paths must take the UNIX form, so /cygdrive/c/........


login: stephan
mimetype: text/x-fossil-plain
icomment:
  This discussion has been around the block a couple of times. Summary: it's a platform-specific behaviour, which is something fossil tries to avoid unless absolutely necessary. Closing ticket as part of spring cleaning.


login: nobody
username: J Esteves
mimetype: text/x-fossil-plain
icomment:
  For those editing embedded documentation .wiki files with emacs, comments are also useful to specify file variables. Not sure if other editing tools make a similar use of comments, but surprised this issue persists anyway.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  This doesn't sound terribly realistic in terms of expected features. A user cannot (normally) disable a specific menu of a program just because he doesn't like it, and fossil running in local (not network) mode assumes the user knows what he's doing - it offers lots of chances for users to shoot themselves in the foot if they're not careful (e.g. irrevocably losing stashed changes via 'close'ing the repo). Such a feature also implies the addition of a --force (or similar) command to force execution of a disabled command. That, in turn, would give the user back his gun so that he could shoot himself in the foot again. It would also have side-effects on any commands which themselves use such a flag for other purposes.


login: nobody
mimetype: text/plain
icomment:
  Reopening issue, since this functionality don't work again. Tested on Windows. I will try to find issue myself


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  This is not a Fossil bug. Building fossil from sources on Cygwin result in a cygwin executable, not a win32 executable. Win32 executables cannot easily spawn Cygwin executables, that's a Cygwin limitation fossil can't do much about.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  Because "known good" is nothing more than a tag, and the trunk tag is (barring natural disasters) considered stable in this project, this is already possible:

  http://...fossil-url.../zip/Fossil-trunk.zip?uuid=trunk


login: nobody
mimetype: text/x-fossil-plain
icomment:
  I didn't realise this ticket was already fixed and was over a year and a half old! Silly mistake. I found it on Google and it was close to the beginning of the list of results, so I assumed it was rather a recent ticket.

  I do apologise for any inconvenience caused by this.


login: mistachkin
mimetype: text/plain
icomment:
  I believe the underlying issue has already been fixed quite a while ago, by
  normalizing the slashes and character case used by the file names stored in the
  "_fossil" file.

  The solution might simply be to remove all (duplicate) entries from the "_fossil"
  file.  When the entries get re-added, they should only occur once.

  The canonical names in the global_config table should look something like:

  'ckout:C:/sqlite/core/'
  'repo:C:/repositories/sqlite3.fossil'

  Notice the drive letter is capitalized and forward slashes are being used.


login: jan.nijtmans
mimetype: text/plain
icomment:
  C:\Localdata\workspace\fossil>fossil all rebuild
  C:\Localdata\Tcl\bin\fossil.exe rebuild C:/fossil/fossil.fossil
    100.0% complete...

  C:\Localdata\workspace\fossil>fossil test-move-repository C:/Fossil/fossil.fossi
  l

  C:\Localdata\workspace\fossil>fossil update
  Autosync:  https://jan.nijtmans@www.fossil-scm.org/fossil
  via proxy: http://192.168.13.12:8080
  Round-trips: 1   Artifacts sent: 0  received: 0
  *** time skew *** server is slow by 3.3 minutes
  Pull finished with 442 bytes sent, 2598 bytes received
  -------------------------------------------------------------------------------
  checkout:     90bd20308b5705caa687acb2aab1f62a6c77a4bb 2014-02-07 08:58:55 UTC
  leaf:         open
  tags:         trunk
  comment:      Add the .clone command to "fossil sqlite3". Taken from SQLite
                trunk. (user: jan.nijtmans)
  changes:      None. Already up-to-date

  C:\Localdata\workspace\fossil>fossil all rebuild
  C:\Localdata\Tcl\bin\fossil.exe rebuild C:/Fossil/fossil.fossil
    100.0% complete...
  C:\Localdata\Tcl\bin\fossil.exe rebuild C:/fossil/fossil.fossil
    100.0% complete...

  C:\Localdata\workspace\fossil>


login: anonymous
mimetype: text/x-fossil-plain
icomment:
  Or just always store in UTC and render in local time zone if required.

  Possible solution as cut & pasted from:
  https://bugzilla.mozilla.org/show_bug.cgi?id=182238#c3
  ---
  Note that it is trivial to display times in the users local time zone, without
  any per-user settings on the server. The web server sends a timestamp, and the
  browser display the date/time in local format.

  Here is how:

  Opened: <script type="text/javascript">
  <!--
  var time1 = new Date(the_time_as_miliseconds_since_epoch__inserted_by_server);
  Document.write(time1.toLocaleString());
  -->
  </script><noscript>2002-11-27 08:09 PDT</noscript>
  ---


login: stephan
mimetype: text/x-fossil-plain
icomment:
  Closing as "way out of scope." The JSON API allows one to store whatever text format he wants as a wiki page, provided the client is willing to deal with the data format somehow (e.g. client-side rendering).


login: stephan
mimetype: text/x-fossil-plain
icomment:
  Optimizations and their effects on app runtime are highly platform- and compiler-(version) dependent. It doesn't seem reasonable to expect a project to guaranty that a specific compiler flag will have been used to generate published binaries. To get this behaviour on your own binaries, simply replace the setting in the configure-generated Makefile.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  To be perfectly reliable this would have to work at the UUID level, not version number level, and would mean that the fossil developers would be continually hounded by such a warning (which implies yet another config option to disable it).


login: stephan
mimetype: text/x-fossil-plain
icomment:
  Adding such support would require reimplementing the args parsing support completely and require differentiating between --long-form and -s hort form flags, something fossil doesn't currently do and cannot do without a good deal of significant CLI backwards incompatibility.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  Bumped into this with the following scenario:

    #  Commit to a fossil repository in a machine with the correct time setup.
    #  Run a fossil server off a repository in a USB drive on the machine.
    #  Sync the local repository with the USB repository.
    #  Stick the USB drive into a new machine with a time setup that puts it in the past (in my case, it was an earlier timezone).
    #  Run the fossil server off the USB drive in the new machine.
    #  Sync a local fossil repository in the new machine with the USB fossil server. The local fossil repository will receive the artifacts from the "future".
    #  "fossil update" the local repository. It will not retrieve the file contents from the "future".

  As the original reporter commented, the least intrusive fix here would be to warn of strange timestamps during a sync or a pull. That should clue the user in to check the time settings. Once those are fixed, things work fine.


login: wyoung
mimetype: text/x-fossil-wiki
icomment:
  The trick here is how do you know what a "sane" time value is, if the local clock is desynchronized?

  The best idea I've got at the moment is that the Fossil <tt>configure</tt> script can look at time stamps or <tt>fossil stat</tt> info to find the newest timestamp on any file in the source tree, then consider that a minimum sane date for new content.

  In production, this will put a floor on sanity down in the weeks to months range, so it would catch the 2002 problem brought up above, but it won't catch a problem where one client is only minutes to hours off of correct.

  We've got to be somewhat careful here.  For instance, if I turn off autosync while I'm off on a 2-week vacation, then make a few checkins on my portable machine while my relatives go do unimaginably weird things like visit the beach instead of write new software, when I return to work and sync my changes up, the server is going to see checkins up to 2 weeks old. The server must not reject those simply because they were created "in the past."

  In a DVCS, there's a limit on how strict the central server can be. If we cannot trust time sync in 2018, a whole lot of other things break, too. <tt>make</tt> breaks, for instance.


login: anonymous
username: gergely@polonkai.eu
mimetype: text/plain
icomment:
  The (almost?) same problem exists on my CentOS host with fossil version just downloaded from the site (http://www.fossil-scm.org/download/fossil-linux-x86-20140612172556.zip). I currently have no option to test with latest sources; if I can, I will attach my findings here.

  Navigating to http://gergely.polonkai.eu/fossil/astrognome redirects to /fossil/index instead of /fossil/astrognome/index. The login page link also has the same bug.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  It's sad to see that this suggestion from 2010 has not been followed up on... Separating the HTML/CSS from code would have so many advantages, it's hard to know where to begin.

    *  easier to build skins
    *  easier to internationalise all strings in the interface
    *  easier to update the web interface code when web interface standards change - i.e., add HTML5 elements, or use the latest css framework or javascript library
    *  easier for in-house designers and non-programmers to tweak the web interface to suit their needs
    *  enable user customisation of ALL content pages, individually (admin, tickets, timeline, wiki, etc.) - as opposed to being able to just fiddle with a generic 'header' and 'footer'

  Right now, in 2014, the html/css output by Fossil is less-than-optimal: it is riddled with inline styles (very, very bad), uses table-based layout for most of its pages, and makes no use of widely accepted HTML5 elements.

  Fossil is a GREAT piece of software, but the web GUI really need an update.


login: nobody
mimetype: text/plain
icomment:
  Agreed. It's sad to see that after four years, this is still open and pending, What happened to separation of concerns?


login: stephan
mimetype: text/x-fossil-plain
icomment:
  This was coincidentally re-added recently in the form of the "dbstat" command, which essentially shows the same info as the /stat page. i was unaware of "rstat" or i might have recycled that command name.


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  Probably dup of [85017e9273], as I cannot reproduce this any more.

  Please verify that this is really fixed on trunk now.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  This is far out of scope for fossil's current incarnation. i could imagine it being feasible to do in a library version of fossil, but that won't happen before v2.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  This seems to have been fixed in the mean time. In my tests the result is:

  [stephan@host:~/tmp/f/x]$ cat b.txt 
  Hello
  newline


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Still a problem in 1.22 [ab461f39af].

  Is the problem that the description text never gets stored, or never gets displayed? Is the description still in fossil somewhere? Or is it gone for ever?


login: stephan
mimetype: text/x-fossil-plain
icomment:
  1.22 is ancient - please try with a newer version (1.26 is current as of today). Yes, the comments are saved (and in your db somewhere), they are apparently just not being displayed on your particular version.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Thanks stephan for your quick reply that I somehow never noticed.
  1.22 is the version that comes with my distribution (Mint).
  I'll try with a later version if I get a chance


login: nobody
mimetype: text/plain
icomment:
  I have just added an attachment with a comment and the comment does not show up besides the attachment list, but it appears as expected on the "details" view.


login: anonymous
username: dkf
mimetype: text/html
icomment:
  This is particularly important when dealing with a project with a <i>lot</i> of issue reports, such as the Tcl and Tk repositories (which have over 15 years of issues in the database). The all-tickets report is unusable due to the sheer number of items involved right now.


login: nobody
mimetype: text/html
icomment:
  I think this is basically the same bug (feature?):
  <pre>
  fossil mv some_directory other_directory
  </pre>
  Will move the contents of some_directory to other_directory instead of some_directory itself, which would be expected, as that is the behaviour of posix <tt>mv</tt>, that is it will act like one would expect from
  <pre>
  fossil mv some_directory/* other_directory
  </pre>
  which in turn would move the contents of the subdirectories of some_directory... you get the idea.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  The JSON API allows one to do this, and there's a proof-of-concept/demo here:

  http://fossil.wanderinghorse.net/repos/fwiki/editor/

  that requires rendering on the client side (or whoever fetches the data, since that might itself be a pipe of some sort).


login: anonymous
mimetype: text/x-fossil-plain
icomment:
  I would like to bump this up. It's been two years and even incremental import from git (or git bundles, which can be offset from a tag/rev/time offset) would be most useful.


login: anonymous
username: Srivathsan Madhavan
mimetype: text/plain
icomment:
  I am still having this issue with WinXP Sp3 + cumulative fixes till date and IE8.  I even tried changin the max-upload setting value to 20 * 1024 * 1024 (20MB) but still I couldn't upload a 72kb image (JPEG) file.  Truly frustrating!


login: stephan
mimetype: text/x-fossil-plain
icomment:
  Closing - fossil won't ever have direct support for specific binary file formats, with the exception of its archive generation features.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  I think I got a workaround on Unix, no idea about windoze:

  $ export USER=my_special_username
  $ cat git-export | fossil import new-repo.fossil

  I prefer to do this on a brand new (temporary) shell session. I have no idea about how different software will behave when USER env var has a value different than the user's login name.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  Reminder: i looked at changing that config field in /setup_settings a TEXTAREA, but it's handled by a generic property loop which assumes a TEXT field, so adding this to the web UI requires a bit of effort. The ignore-glob internally supports newline as a separator, so this is "just" a matter of getting the UI for it.


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  Experimental fix committed to [949976e065]. Could use some tweaking in the exact layout, but actually already looks quite good.


login: nobody
mimetype: text/html
icomment:
  Hi, I managed to configure a "read only my tickets" Fossil repository. Please see <a href="http://snowflakejoins.com/fossil/private.html">http://snowflakejoins.com/fossil/private.html</a> for implementation details
  <br>
  -Alexandru Toth


login: nobody
mimetype: text/html
icomment:
  Please see <a href="http://snowflakejoins.com/fossil/fossil.cgi/index">http://snowflakejoins.com/fossil/fossil.cgi/index</a> for the Fossil Tickets.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  Closing as "should have been discussed on the list first" (like the ticket page banner suggests). AFAIR this is the first time this particular request has come up, and seems like a very limited use case to me.

  Feel free to bring it up on the mailing list - i'm practically famous for being in the minority on this type of thing ;).


login: drh
mimetype: text/x-fossil-plain
icomment:
  Konstantin Khomoutov writes on the fossil-users mailing list:

  I'm just handwaving, but Git's code base recently received some
  modifications to specifically deal with issues a native Mac OS X
  filesystem have with regard to UTF-8.  AFAIK the deal was about that
  filesystem pefrorming one of standard UTF-8 normalizations either when
  writing or when reading (or both) so that when you create a directory
  entry and then read it back, you might get an octet string different
  from that you wrote.

  See the extensive commit message in [1] and [2] in general.

    1.  [https://github.com/git/git/commit/76759c7dff53e8c84e975b88cb8245587c14c7ba]
    2.  [http://en.wikipedia.org/wiki/HFS_Plus]


login: anonymous
mimetype: text/x-fossil-plain
icomment:
  I checked this a bit further to include a Windows 7 environment. Win 7 and OSX 10.7 respond differently

  A. On the Ubuntu 12.04LTS machine
    #  add the folder  and "WiThCaPiTals" and "WiThCaPiTalsó"
    #  In both folders "withcapitals" and "WiThCaPiTalsó" add the file "FilEWithCapItals.rst"
    #  In the folder "withcapitals" add the file "filewithcapitals.rst"

  B. Update the repo on OSX 10.7
    #  fossil: changes 3 files modified
    #  fossil: WARNING: 1 unmanaged files were overwritten
    #  the result is one folder: "WiThCaPiTalsó" containing the file "FilEWithCapItals.rst"
    # Two folders and two files dissapeared.

  B. Update the repo on Windows 7
    #  fossil: changes 2 files modified
    #  fossil: WARNING: 1 unmanaged files were overwritten
    #  the result is two folders: "WiThCaPiTals" and "WiThCaPiTalsó" both containing the file "FilEWithCapItals.rst"
    # One folder and one file dissapeared

  It looks indeed as if this is caused by how the underlying OS deals with capitalization and non-ascii characters. I used fossil for a workshop on version control and some participants had issues like the change of direction of the accent. But I have not been able to replicate those. Neither have I been able to replicate the issues in the Wiki we saw, that is why I have not reported it separately.


login: drh
mimetype: text/x-fossil-wiki
icomment:
  See also: [http://en.wikipedia.org/wiki/Unicode_equivalence#Errors_due_to_normalization_differences]


login: nobody
mimetype: text/x-fossil-plain
icomment:
  After editing a wiki page a security code (captcha) has to be entered for confirmation and to prove that a human made the changes. The code (mixed digits and characters) is displayed in uppercase letters, but entering the code exactly as shown always leads to an "incorrect security code" message. Apparently the letters have to be given in lowercase form.
  Additionally for people not immediately aware that only hex digits (0-9, A-F) are used here, the zero (0) might be confused with an uppercase "O". A short hint about the valid character range might be useful.


login: drh
mimetype: text/x-fossil-wiki
icomment:
  The solution is to add some crazy-looking javascript to work around the non-compliant javascript implementation of IE8 and earlier.  I am reluctant to add such hacks.


login: altufaltu
mimetype: text/x-fossil-plain
icomment:
  OK. I was only worried that links removed by [89ab1185bf] should not heavily affect functionality for IE. I see that the Diffs: line will go away from checkin information page - minor one.


login: drh
mimetype: text/x-fossil-wiki
icomment:
  Possible solution:
  [http://stackoverflow.com/questions/10286162/pageyoffset-scrolling-and-animation-in-ie8]


login: altufaltu
mimetype: text/x-fossil-plain
icomment:
  Works on IE8 now. Thanks for fix.

  One suggestion: To mark version corresponding to second click (version to be diffed with) with a different color (although temporary) or change pointer to hourglass so that user knows that 2nd click was registered and diff is expected in few seconds.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Summary: Computers A B and C are all in sync. On Computer A, I made some commits, created a new branch, made more commits, and then synced with my central repository (computer C). I then synced Computer B with C, but it synced everything except for the last branch I created. I ran fossil sync repeatedly, and everytime it would say syncing was complete, no artifacts sent or received, but when I run fossil timeline, my newest branch is missing, and fossil checkout *newbranchname* reports that the branch does not exist.

  Computer A is a laptop running Ubuntu 12.04. Computer B is a late 2009 Mac Mini. Computer C is a VPS linux server (Ubuntu). All computers are running the fossil version stated in this ticket.

  If I clone the repository from C to B, the cloned repository has my newest branch available. But if I try to sync the repository already on B with C, it doesn't make any changes and the branch is still missing. If it will help, I am willing to send you copies of my repository (about 3-4 MB each) for you to psychoanalyze them.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Also I must add that I have a repository set up at chiselapp which does nothing but pull from my linux VPS node. The repository on chiselapp also fails to pull in my latest branch. The fossil version on chiselapp is [8d758d3715].


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Also of note, the branch is not a private branch. Running fossil timeline on the linux VPS server (C) displays my new branch (which is missing on chiselapp and my Computer B), which would not have appeared if the branch was created privately on my Computer A.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Fixed by adding a new commit to the trunk and syncing. Syncing from the other repositories now pulls in everything that previously would not sync.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Incorrect MIME-types for these formats is causing download links to misbehave. For instance, when attempting to download a xlsx file, the user will receive a xls file.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  The correct MIME types for Office 2007 appear in this TechNet article:
  [http://technet.microsoft.com/en-us/library/ee309278%28office.12%29.aspx]


login: nobody
mimetype: text/x-fossil-plain
icomment:
  I usually name my databases like ".db.fossil"...
  and 3 days ago i closed the working copy with
  > fossil close

  It deleted the working files but my databases was erased too.


login: drh
mimetype: text/x-fossil-wiki
icomment:
  Already fixed by check-in [fcdeaa2909].  But this problem should not have
  existed in a released version of Fossil.  The OP must be running a self-compiled
  version of Fossil made from sources obtained between 2012-11-10 and 2012-11-28, which is the window during which this bug existed.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  The help text for "fossil help all" suggests that running "fossil info" on a repository will add it to the known list. However, doing this with Fossil 1.24 (on both Windows and Linux) doesn't add the repo to the list reported by "fossil all ls".


login: anonymous
mimetype: text/x-fossil-plain
icomment:
  In mercurial, it is default option for keep symbolic as symbolic.
  That will reduce the disk space usage too.
  So, I suggest let the function be default option.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  When looking at the main timeline or a branches timeline the "show files" button follows the "older" button.  If the "show files" view is accessed, the "hide files" button precedes the "older" button (buttons swap locations).  The distinction is particularly pronounced on a branches timeline views.  

  I considered listing this as cosmetic, but it impacted usability which is more than cosmetic to me.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  Per a mailing list comment from DRH, the current (and preferred) behaviour is that the buttons sort alphabetically.


login: anonymous
mimetype: text/x-fossil-plain
icomment:
  $ fossil stat
  repository:   /home/dlin/fs/kernel.fossil
  local-root:   /home/dlin/src/kernel/
  checkout:     c0f6f49fa0651745cb0531f4e43eb27b8694af1e 2013-01-03 02:19:55 UTC
  parent:       269a3406c14bde8e05f8a62b84ef152e4207a2f6 2013-01-02 15:38:21 UTC
  tags:         trunk
  comment:      undo fake version. add netfilter_bridge_cdc_ether.config (user:  dlin)
  EDITED     256M.config
  EDITED     mk_ub.sh
  EDITED     smit.config

  $ rm mk_ub.sh
  $ fossil stat
  repository:   /home/dlin/fs/kernel.fossil
  local-root:   /home/dlin/src/kernel/
  checkout:     c0f6f49fa0651745cb0531f4e43eb27b8694af1e 2013-01-03 02:19:55 UTC
  parent:       269a3406c14bde8e05f8a62b84ef152e4207a2f6 2013-01-02 15:38:21 UTC
  tags:         trunk
  comment:      undo fake version. add netfilter_bridge_cdc_ether.config (user:              dlin)
  EDITED     256M.config
  MISSING    mk_ub.sh
  EDITED     smit.config

  $ fossil revert mk_ub.sh
  REVERTED: mk_ub.sh
   "fossil undo" is available to undo changes to the working checkout.

  $ fossil stat
  repository:   /home/dlin/fs/kernel.fossil
  local-root:   /home/dlin/src/kernel/
  checkout:     c0f6f49fa0651745cb0531f4e43eb27b8694af1e 2013-01-03 02:19:55 UTC
  parent:       269a3406c14bde8e05f8a62b84ef152e4207a2f6 2013-01-02 15:38:21 UTC
  tags:         trunk
  comment:      undo fake version. add netfilter_bridge_cdc_ether.config (user:  dlin)
  EDITED     256M.config
  EDITED     mk_ub.sh
  EDITED     smit.config


login: nobody
mimetype: text/html
icomment:
  When compiling althttpd.c on FreeBSD, there's a missing header. Since you can't submit tickets on <a href="https://www.sqlite.org/docsrc/finfo?name=misc/althttpd.c">sqlite.org/misc/althttpd.c</a>, I'm including it here since it's used primarily for fossil.

  <pre>--- althttpd.c.orig	2013-01-08 20:51:11.000000000 +0000
  +++ althttpd.c	2013-01-08 20:51:05.000000000 +0000
  @@ -86,6 +86,9 @@
   #include <sys/sendfile.h>
   #endif
   #include <assert.h>
  +#ifdef __FreeBSD__
  +# include <signal.h>
  +#endif
   
   /*
   ** Configure the server by setting the following macros and recompiling.</pre>


login: nobody
mimetype: text/x-fossil-plain
icomment:
  There have
  been many other systems developed since them some open source and some proprietary.

  on page 5 should be:

  There have
  been many other systems developed since then some open source and some proprietary.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Would it be possible to adapt the code from tortoisebzr or tortoisesvn for the shellext and compile it into the windows version of fossil? That way it would be possible to get a direct graphical view for the status of the repository while browsing its files. 

  I'm no cpp developer, but as far as it seems, there shoul'nt be to much code needet to achive this. (tortoisebzr shellext: http://bazaar.launchpad.net/~tortoisebzr-developers/tortoisebzr/0.5/files/381/shellext)


login: nobody
mimetype: text/x-fossil-plain
icomment:
  when commiting with fossil, I miss git's "git commit -v" feature that appends the diff of changes being commited to the file where I edit a commit message. This way, I can see what exactly I'm commiting when typing the message. It saved me from a wrong commit a few times. Of course, I could call "fossil diff" before (and I do that now), but it's not that convenient. Would it be difficult to add this to fossil?

  (Discussed in [http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10969.html]).


login: anonymous
mimetype: text/x-fossil-plain
icomment:
  http://www.fossil-scm.org/download.html
  Please fix informations in this page because we do not know if the package we may download is good or not...
  (Date in the end is 2013-01-17 when the date in the top is 2012 ...)

  And it seems that 1.24 is not the latest : am I wrong ?

  Thanks.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  Cannot reproduce. The current download page contains releases 1.22 to 1.24 in proper order, and 1.24 was the last official release.


login: anonymous
username: eric
mimetype: text/plain
icomment:
  Ticket creator appears to have been referring to the versions available for download (1.24 and earlier in the download list) not matching the version currently running on the server (2013 compile date in the page footer).


login: nobody
mimetype: text/plain
icomment:
  The current RSS feed provided by fossil is giving out all the Timeline updates.  While this could very well be the default behaviour, the 'timeline.rss' URL could probably take some parameters by which some filters are possible; like:
  1. Checkins
  2. Events
  3. Tickets
  4. Wiki
  5. Tags

  No need to provide any gui-based mechanism; just some parameters as part of the URL like:
  - http://.../timeline.rss?checkins=1&events=0&tickets=1

  Any possible, meaningful combinations of the params would be wonderful


login: anonymous
mimetype: text/x-fossil-plain
icomment:
  # rm b.fossil                                                 / 9:58
  # fossil new b.fossil                                         / 9:58
  project-id: 8a35ed693272739afe853304b1df50b7539a07ad
  server-id:  955520e8161701af952a162a4010992117161d5c
  admin-user: root (initial password is "a0d0a3")
  # fossil open b.fossil                                        / 9:59
  # fossil add /etc/hosts                                       / 9:59
  ADDED  tc/hosts
  # fossil stat                                                 / 9:59
  repository:   ./b.fossil
  local-root:   ./
  checkout:     b0990f21f0001a24925ad9ba8cb0715865fa5fe9 2013-02-02 01:58:59 UTC
  tags:         trunk
  comment:      initial empty check-in (user: root)
  MISSING    tc/hosts
  This is fossil version 1.25 [fe56e5aa4f] 2013-02-01 12:33:13 UTC


login: nobody
mimetype: text/x-fossil-plain
icomment:
  I've observed this in Linux as well as Windows with [d2e07756d9].

  Sample console session in Windows XP:

  C:\>fossil init test.fossil
  project-id: ...
  server-id:  ...
  admin-user: ... (initial password is ...)

  C:\>fossil open test.fossil

  C:\>mkdir c:\tmp

  C:\>echo "hello world" >c:\tmp\helloworld.txt

  C:\>echo "hello world 2" >c:\tmp\helloworld2.txt

  C:\>fossil add /tmp/helloworld.txt
  ADDED p/hello.world.txt

  C:\>fossil status
  repository:   C:/test.fossil
  local-root:   C:/
  checkout:     ...
  tags:         trunk
  comment:      initial empty check-in (user: ...)
  MISSING    ../p/helloworld.txt

  C:\>fossil add c:\tmp\helloworld2.txt
  ADDED  tmp/helloworld2.txt

  C:\>fossil status
  repository:   C:/test.fossil
  ...
  MISSING    ../p/helloworld.txt
  ADDED      ../tmp/helloworld2.txt

  C:\>fossil version
  This is fossil version 1.25 [d2e07756d9] 2013-02-16 00:04:35 UTC

  C:\>


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  On my repository, when I type fossil info, it says the number of checkins is 431. If I Admin->Stats on the webpage generated with fossil ui, it says number of checkins is 432.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  Fixed in [b27c0d6d3fd0abe50a14e85b557]. We had some confusion in a couple places about what the proper approach is for counting checkins.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  If you add an empty-dirs file in your .fossil-settings directory on a branch, the empty directories are created when you update to the trunk, and not when you update to the branch.

  Steps to reproduce:

  fossil init bug.fossil
  mkdir bug
  cd bug
  fossil open ../bug.fossil
  fossil branch new empty-dirs-branch
  fossil update empty-dirs-branch
  mkdir .fossil-settings
  echo testdir > .fossil-settings/empty-dirs
  fossil add .fossil-settings/empty-dirs
  fossil commit -m "New empty-dirs file for this branch"
  fossil update trunk

  At this point, the "testdir" directory has been created, even though that setting was part of the branch, not the trunk.

  cd ..
  rm -rf bug
  mkdir bug
  cd bug
  fossil open ../bug.fossil
  fossil update empty-dirs-branch

  At this point, "testdir" has not been created.


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  Try "fossil test-move-repository" when the original location is no longer available.

  $ fossil test-move-repository C:/fossil/foo.fossil
  Fossil internal error: repository does not exist or is in an unreadable directory: H:\fossil\foo.fossil

  Also note that db_open_repository() and db_record_repository_filename() don't require a normalized path name, so the file_canonical_name() call in cmd_open() is not necessary.

  Proposed fix in branch "fix-test-move-repository"


login: nobody
mimetype: text/x-fossil-plain
icomment:
  I recently upgraded from version 1.24 and noticed a break or a change in behavior on how the binary-glob works. I looked in open tickets and all tickets as well as the change log for 1.25 to see if this was a deliberate change but I didn't see note of it, perhaps I missed it?

  I create a new repo, add my settings, checkin settings, add my project files which contain binary files like *.lnk and *.bin, then try to commit my initial check in. I then receive the following even though I have both *.bin and *.lnk in .fossil-settings\binary-glob. If I change back to the 1.24 executable I do not experience the issue. 

  "fossil commit -m "mbp:
   Initial check in of NI PXI-5412 example code"
  fossil: SQLITE_IOERR: delayed 25ms for lock/sharing conflict
  ../../Waveforms/SineI16BigEndian_1000.bin contains binary data. Use --no-warnings or the "
  binary-glob" setting to disable this warning.
  Commit anyhow (a=all/y/N)? n
  fossil: Abandoning commit due to binary data in ../../Waveforms/SineI16BigEndian_1000.bin"


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  It looks like the glob_expr() function (src/glob.c line 17) doesn't handle newlines as it should. Proposed fix in [ticket-ed23ef59cf] branch. I'm not sure if this fix handles quotes correctly, but at least it's a start.

  Workaround: don't use newlines to separate multiple entries, use ','


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  I did a bisect in order to find out when this bug was introduced. The result was: 
  [0c7c61447f]

  Guess what. This commit adds the binary warning to the commit dialog, previously the function glob_expr was only used to handle "crnl-glob". So, the 'bug' (glob_expr doesn't handle newlines as glob_create does) has always been there, but no-one noticed it because the commit dialog didn't use it. It was only used in the diff logic.

  Anyone having objections to merging [e0e88821bd] to trunk?


login: mjanssen
mimetype: text/plain
icomment:
  Fossil pull fails from a file if a proxy is set, seems fossil tries to use the proxy anyway:

  C:\Path>fossil setting proxy
  proxy                (global) http://host:8080

  C:\Path>fossil pull
  Server:    file://C%3A/path/repo.fossil
  via proxy: http://host:8080
                  Bytes      Cards  Artifacts     Deltas
  Sent:             146          2          0          0
  fossil: server says: 502 Proxy Error ( The Uniform Resource Locator (URL) does n
  ot use a recognized protocol. Either the protocol is not supported or the reques
  t was not typed correctly. Confirm that a valid protocol is in use (for example,
   HTTP for a Web request).  )
  Total network traffic: 334 bytes sent, 1000 bytes received


login: nobody
mimetype: text/x-fossil-plain
icomment:
  It would be useful to have the means to find out (or have fossil.exe describe) which features it was compiled against (e.g. whether it was compiled with OpenSSL). This could be something like:

  C:\> fossil.exe version
  This is fossil version 1.2 [d2e07756d9] 2013-02-16 00:04:35 UTC

  C:\> fossil.exe version -info
  This is fossil version 1.2 [d2e07756d9] 2013-02-16 00:04:35 UTC
  - mingw32 
  - openssl (1.0.1d)

  C:\>


login: stephan
mimetype: text/x-fossil-plain
icomment:
  This has been implemented, to some degree, in [1be15a57f1a6447], in the form of a new -verbose flag for the 'version' command. i'm not sure how to get some of the details (e.g. the OpenSSL implementation name and version number), so it just spits out some simple text, e.g.:

  [stephan@host:~/cvs/fossil/fossil/src]$ f version -v
  This is fossil version 1.25 [0d55a0ad0f] 2013-03-15 14:35:26 UTC
  Compiled with the following features enabled:
  	SSL
  	JSON


login: nobody
mimetype: text/x-fossil-plain
icomment:
  OK, I see that it has more code since [d2e07756d9]: 
  [/vdiff?from=d2e07756d9ecc505&to=1be15a57f1a64478&name=src/checkin.c]


login: nobody
mimetype: text/x-fossil-plain
icomment:
  As part of checkin [7ef7284d6b9], which added the zlib sources directly to the fossil sources, the line containing the "MSCDIR = c:\msc" definition was removed in "win/Makefile.msc", and the definition of the header and library inclusion paths "INCL" and "LIBDIR" a few lines later were adapted as well.

  These changes are understandable if you consider only zlib, but the comment in the line before the MSCDIR definition mentioned that it is also used for SSL support. If one wants to compile fossil with SSL support, a setup as described here has to be used:

  http://www.fossil-scm.org/fossil/wiki?name=compillingOnWindows
  (By the way, shouldn't this be only one "l" in "compiling"? Can't edit the name of the wiki page itself, only its contents)

  These instructions are not valid anymore now with regard to OpenSSL!

  Instead of each user manually adding the correct paths to the OpenSSL headers (INCL) and libraries (LIBDIR) and merging these fixes on each "fossil update", the cleaner and better solution to handle such additional external code would be to get back the separate MSCDIR definition and the usage of "(MSCDIR)\extra\include" or "(MSCDIR)\extra\libraries" for INCL resp. LIBDIR.


login: mistachkin
mimetype: text/x-fossil-plain
icomment:
  Fixed on trunk by check-in [c46e5f933d].  The wiki page is still incorrect.

  To compile with OpenSSL enabled using MSVC, uncomment this line:

  # FOSSIL_ENABLE_SSL = 1

  Prior to doing this, follow the OpenSSL instructions for building it with MSVC.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  fossil init test
  fossil open test
  echo. > a.Txt
  fossil add . 
  fossil commit -m test

  ren a.Txt a.txt

  fossil add .
  => ADDED a.txt which is ok.

  fossil add .
  => ADDED a.txt "a.txt" will be mentionned everytime from now on.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  This occurs because file names are case sensitive.  Execute this command:

  fossil rename a.Txt a.txt

  and you will see this problem disappear.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Thanks for the info.

  But under Linux, change the case of an existing file and it will only be added once. Which is ok.

  Under Windows, it keeps getting added everytime.
  Which would make me think there is some case-related issue under Windows.


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  Even though it's a minor bug, I think I found the cause. See [d0764530d3] for the suggested fix.

  The function vfile_scan() is documented to "Omit files named in VFILE",
  but this is not done case-insensitive on Windows. This also means
  that "fossil extras" and "fossil clean" need the --case-sensitive
  option, just like "fossil add" and "fossil addremove".

  Please evaluate. Does this change have any side-effects I didn't think of?


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Thank you for the patch.
  I have made a few tests and it seems to work fine.

  Sorry to ask, but is this ok in add_cmd() ?

   if( caseSensitive ){
        db_multi_exec(
           "CREATE INDEX IF NOT EXISTS vfile_pathname "
           "  ON vfile(pathname COLLATE nocase)"
        );

      }


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  Fixed on trunk now.

  >Sorry to ask, but is this ok in add_cmd() ?

  Yes, I think it is: The index is only needed when case-sensitive is off.
  On Windows, "case-sensitive" should be always off, on Cygwin it should
  be switchable (which is done in [9359b41fd5]), but that's unrelated
  to this buglet.


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  >Sorry to ask, but is this ok in add_cmd() ?

  Oops, you are right: the if expression should be opposite! Thanks for catching this!


login: nobody
mimetype: text/plain
icomment:
  Program received signal SIGSEGV, Segmentation fault.
  fossil_strcmp (zA=zA@entry=0x7fffffffda20 "zshrc", zB=zB@entry=0x3e613738464947 <Address 0x3e613738464947 out of bounds>) at ./src/printf.c:908
  908           b = *zB++;
  (gdb) bt
  #0  fossil_strcmp (zA=zA@entry=0x7fffffffda20 "zshrc", zB=zB@entry=0x3e613738464947 <Address 0x3e613738464947 out of bounds>) at ./src/printf.c:908
  #1  0x0000000000433fe6 in mimetype_from_name (zName=<optimized out>) at ./src/doc.c:323
  #2  0x0000000000442f25 in artifact_page () at ./src/info.c:1652
  #3  0x0000000000448ec0 in process_one_web_page (zNotFound=zNotFound@entry=0x783160 "http://chiselapp.com/notfound", pFileGlob=pFileGlob@entry=0x0) at ./src/main.c:1499
  #4  0x0000000000449cc6 in cmd_cgi () at ./src/main.c:1602
  #5  0x0000000000416257 in main (argc=<optimized out>, argv=<optimized out>) at ./src/main.c:559
  (gdb) print zB
  $1 = 0x3e613738464947 <Address 0x3e613738464947 out of bounds>
  (gdb)


  Core file and compiled "fossil" executable available upon request


login: nobody
username: rkeene
mimetype: text/plain
icomment:
  Better backtrace, and additional information:

  Core was generated by `fossil repository'.
  Program terminated with signal 11, Segmentation fault.
  #0  0x000000000045e5a2 in fossil_strcmp (zA=0x7fffffffd991 "shrc", zB=0x101010101010101 <Address 0x101010101010101 out of bounds>) at ./src/printf.c:908
  908           b = *zB++;
  (gdb) bt
  #0  0x000000000045e5a2 in fossil_strcmp (zA=0x7fffffffd991 "shrc", zB=0x101010101010101 <Address 0x101010101010101 out of bounds>) at ./src/printf.c:908
  #1  0x00000000004352fc in mimetype_from_name (zName=0x7f88f0 ".zshrc") at ./src/doc.c:323
  #2  0x0000000000447c53 in artifact_page () at ./src/info.c:1652
  #3  0x000000000044f1d6 in process_one_web_page (zNotFound=0x7d1160 "http://chiselapp.com/notfound", pFileGlob=0x0) at ./src/main.c:1499
  #4  0x000000000044f78b in cmd_cgi () at ./src/main.c:1602
  #5  0x000000000044d1cf in main (argc=2, argv=0x7fffffffdd68) at ./src/main.c:559
  (gdb) up
  #1  0x00000000004352fc in mimetype_from_name (zName=0x7f88f0 ".zshrc") at ./src/doc.c:323
  323           c = fossil_strcmp(zSuffix, aMime[i].zSuffix);
  (gdb) print zSuffix
  $1 = "zshrc\000\000\000@�S\000\000\000\000\000\000\032\177"
  (gdb) print aMime[i].zSuffix
  $2 = 0x101010101010101 <Address 0x101010101010101 out of bounds>
  (gdb) print i
  $3 = 196
  (gdb) print aMime[i-1].zSuffix
  $4 = 0x534d53 "zip"
  (gdb)


login: rmax
mimetype: text/plain
icomment:
  $ fossil annotate generic/tclCompile.c | head -1878 | tail -1
  2b1f602d05 2005-10-13 dkf: cmdNsPtr = envPtr->procPtr->cmdPtr->nsPtr;

  But the last change of that line was in eb4fd595f3, not in 2b1f602d05.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  -1

  First of all, this Ticket was submitted as a Code_Defect so I took the liberty of marking it as Feature_Request (which better reflects this Ticket).

  Secondly, although the request described is a convenience (and a point-and-click interface feels more comfortable than typing in), IMHO this would create more problems than it would solve. Add, delete and commit belong to the working copy and nowhere else, the repository (and everyone else) see none of what you do until a successfuly commit is accepted by the repository; whereas the ui stuff is done on the on the repository and don't affect your (or any other users on localhost or elsewhere) local copy until you checkout/update from the repository.
  (Problems I see: what happens when two users are working on the same version? what happens when you open a version on another working copy, do you get only the files of that version or also the added files? what happens when you force a close of a working copy and then open a new working copy, do you get the added-but-not-committed files or do they stay in a limbo?)

  --[jbatista]


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Sure, it is a "feature request".

  I understand your point, and effectively, there are some restrictions/rights that are required to be properly managed. Possibly, only localhost user is to be allowed for such actions. Other restricting solutions could be imagined (administration configuration, checkin rights, etc).

  I keep convinced that such facility would be very good point for new fossil users, and for everyday users not having to use the command line. Personnaly, I like it a lot.

  I started some tests to implement it, and I am happy with these first results. Implementation best arrangement is not so easy, in particular the "commit" because of the mix of user interactions and functionnal checks and actions. However, it looks very feasible.

  If others are interested in this, I would appreciate to spend more time on it. In such a case, I would also appreciate,
   some advices of fossil developpers for the best way to do it, in particular in regard to the commit function, and menu implementations.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Seems conflict access could be solved by checking the "g.localOpen" boolean, does'nt it?

  Working on this subject, seems very useful. Check that other people requested this function on several blogs, and some others consider the absence of this function as a disadvantage of Fossil.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Hi, 
  look at the web code editor ticket [http://www.fossil-scm.org/fossil/tktview?name=ad98e8f665]  
  it seems to be the same problem with per-user staging area.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  after pressing the hyperlink button a pop-up appears to enter the Target-URL. after entering and clicking ok nothing visible is inserted.


login: drh
mimetype: text/x-fossil-wiki
icomment:
  An attempt to run "fossil export" on a repository that includes timewarps
  generates a get-fast-export file that contains out-of-order records.  Git
  requires that records be in check-in order, not in chronological order.

  An example timewarp can be seen at [http://www.sqlite.org/docsrc/timeline?c=1ac9233c15&n=7].  Timewarps are caused when developers do check-ins
  from a machine where the system clock is set incorrectly.  You can get a list
  of all timewarps in a repository by visiting the test_timewarps URI.  
  For example: [http://www.sqlite.org/docsrc/test_timewarps].

  A work-around it to repair the timewarps by editing the check-in time of
  the commit.


login: nobody
username: tim
mimetype: text/x-fossil-wiki
icomment:
  $ fossil export --git ../sqlite.fossil | git fast-import
  fatal: mark :60713 not declared
  fast-import: dumping crash report to .git/fast_import_crash_3740

  To replicate, using latest version of sqlite


login: nobody
username: tim
mimetype: text/x-fossil-wiki
icomment:
    commit refs/heads/trunk
    mark :60705
    committer drh <drh> 1257341402 +0000
    data 83
    from :60691
    M 100644 :60706 src/main.c
    M 100644 :60698 src/sqliteInt.h

    commit refs/heads/shunning_error
    mark :60721
    committer drh <drh> 1257360677 +0000
    data 24
  * from :60713

  Active Branch LRU
  -----------------
      active_branches = 4 cur, 5 max

    pos  clock name


login: nobody
mimetype: text/plain
icomment:
    db_prepare(&q,
      "SELECT strftime('%%s',mtime), objid, coalesce(ecomment,comment),"
      "       coalesce(euser,user),"
      "       (SELECT value FROM tagxref WHERE rid=objid AND tagid=%d)"
      "  FROM event"
      " WHERE type='ci' AND NOT EXISTS (SELECT 1 FROM oldcommit WHERE objid=rid)"
      " ORDER BY mtime ASC",
      TAG_BRANCH
    );

  export.c has the db call above. In investigating the sqlite3 database for sqlite, objid 30360 is of type 'ci' but the from, 30356 is not of type ci. Conversion is 2* + 1, this corresponds to 60721 and 60713. The latter is not included in the output (shunned?) and so git freaks. What to do about this?


login: nobody
mimetype: text/plain
icomment:
  60713 is a tag (and excluded from the commit and yet tied to 60720 as a plink).

  sqlite> SELECT * FROM event WHERE objid IN (30360, 30356) ORDER BY mtime;
  g|2455140.26131944|30356|||||drh||Edit [eb7a544fe49d1626bacecfe53ddc03fe082e3243|eb7a544fe4]: Change background color to "#ffc0d0". Edit check-in comment. Timestamp 2009-11-04 13:30:02.||
  ci|2455140.28561343|30360|||#c0c0c0||drh||Fix documentation typos.||2455140.28561343
  sqlite> SELECT * FROM plink WHERE cid = 30360;
  30356|30360|1|2455140.28561343


login: nobody
mimetype: text/plain
icomment:
  db_prepare(&q3,
        "SELECT pid FROM plink"
        " WHERE cid=%d AND isprim"
        "   AND pid IN (SELECT objid FROM event)",
        ckinId
      );

  I wonder if this query for the "from" should also include a check for type 'ci'


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  I made the change and ended up running into my first "real" timewarp. 

  <pre>
    commit refs/heads/trunk
    mark :70907
    committer drh <drh> 1285705604 +0000
    data 94
  * from :70901

  sqlite> SELECT * FROM event WHERE objid = (70907-1)/2;
  ci|2455468.35189815|35453|||||drh||Simplify the test that determines if the name of a new table collides with
  a prior index name.||2455468.35189815
  sqlite> SELECT * FROM event WHERE objid = (70901-1)/2;
  ci|2455468.80332176|35450|||||dan||Fix some problems that can occur if a trigger has the same name as another database object.||2455468.80332176
  sqlite> SELECT * FROM plink WHERE cid = 35453;
  35450|35453|1|2455468.35189815
  </pre>

  Thinking I had some good ideas, I changed the sort from mtime to objid and ran into the inverse timewarp where the plink actually goes backwards.

  <pre>
    commit refs/heads/trunk
    mark :91
    committer drh <drh> 959622265 +0000
    data 11
  * from :93

  SQLite version 3.8.7 2014-10-17 11:24:17
  Enter ".help" for usage hints.
  sqlite> SELECT * FROM event WHERE objid = (93-1)/2;
  ci|2451694.10138889|46|||||drh||initial check-in of the new version (CVS 1)||2451694.10138889
  sqlite> SELECT * FROM event WHERE objid = (91-1)/2;
  ci|2451694.23917824|45|||||drh||:-) (CVS 2)||2451694.23917824
  sqlite> SELECT * FROM plink WHERE cid = 45;
  46|45|1|2451694.23917824
  sqlite>
  </pre>


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  This makes me want to cry a little bit.

  <pre>
  sqlite> SELECT COUNT(1) FROM plink WHERE pid > cid;
  1065
  sqlite> SELECT COUNT(1) FROM plink WHERE cid > pid;;
  13533
  </pre>

  Legacy?


login: nobody
username: tim
mimetype: text/x-fossil-wiki
icomment:
  I know I'm just a nobody around here... but if there is anyone out there to advise or console it would be much appreciated. Upon further analysis, the correct sort order is NOT objid or mtime, but something derived from the plink table, so that no "from" reference comes up before it is declared. Probably this is not an issue in more modern fossil repositories. Wonder if the right solution is a "repair" of sqlite.fossil rather than trying to build something fancy in export.c.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  Maybe not as bad as I thought

  <pre>
  sqlite> SELECT l.*, ep.mtime, ec.mtime FROM plink l LEFT JOIN event ep ON pid = ep.objid LEFT JOIN event ec ON cid = ec.objid WHERE ep.mtime > ec.mtime LIMIT 10;
  35460|35462|1|2455469.26833333|2455469.46484954|2455469.26833333
  35450|35453|1|2455468.35189815|2455468.80332176|2455468.35189815
  sqlite>
  </pre>

  Did old timewarps get fixed?


login: nobody
mimetype: text/plain
icomment:
  After attempting to add a comment to a ticket from the fossil command I got an error.

  $ fossil ticket set ee2d4d2c9439dbb2556670db97be7e65985bae2a +icomment 'Fixed for BtrFS in [476ec98751]'
  fossil: SQLITE_ERROR: near "+": syntax error
  fossil: near "+": syntax error
  INSERT INTO ticketchng(tkt_id,tkt_mtime,+icomment,tkt_rid)VALUES(13,:mtime,'Fixed for BtrFS in [476ec98751]',613)

  Further attempts to commit to the database re-issued this error (but took the commits)


login: nobody
mimetype: text/x-fossil-plain
icomment:
  After cloning the official SQLite repository from http://www.sqlite.org/src I tried to export it into a git repository to use as a submodule.

  So I started `fossil export --git ../sqlite3.fossil | git fast-import` and after working for some time it failed with "fatal: mark :60631 not declared"

  You can find the full git crash log (1.82 MB) at https://dl.dropboxusercontent.com/u/3916812/fast_import_crash_6328


login: nobody
mimetype: text/x-fossil-plain
icomment:
  The fossil download page has the title "Fossil: Timeline", which is the same as for the real timeline page. This is confusing if you have both open e.g. in different tabs. The title of the download page should probably be "Fossil: Download" to match its actual content.


login: mjanssen
mimetype: text/x-fossil-plain
icomment:
  The define changes in sqlite3.c introduced in commit [6ec8818ff1] break the build for Android. With the android NDK __linux__ is defined but posix_fallocate is not available in the Bionic C library.

  Patch at http://mpcjanssen.nl/cgi-bin/fossil/vpatch?from=ea018d154657ddd9&to=f0df1fe2d8f001e3 fixes the android build


login: mjanssen
mimetype: text/x-fossil-plain
icomment:
  The server command doesn't accept --localhost. The reason is that in main.c the argument count check for the server command is done before the check for the --localhost option.

  Diff below should fix it (can't test atm)

  Index: src/main.c
  ==================================================================
  --- src/main.c
  +++ src/main.c
  @@ -1803,18 +1803,19 @@
     zPort = find_option("port", "P", 1);
     zNotFound = find_option("notfound", 0, 1);
     zAltBase = find_option("baseurl", 0, 1);
     if( zAltBase ){
       set_base_url(zAltBase);
  +  }
  +  if ( find_option("localhost", 0, 0)!=0 ){
  +    flags |= HTTP_SERVER_LOCALHOST;
     }
     if( g.argc!=2 && g.argc!=3 ) usage("?REPOSITORY?");
     isUiCmd = g.argv[1][0]=='u';
     if( isUiCmd ){
       flags |= HTTP_SERVER_LOCALHOST;
       g.useLocalauth = 1;
  -  }else if ( find_option("localhost", 0, 0)!=0 ){
  -    flags |= HTTP_SERVER_LOCALHOST;
     }
     find_server_repository(isUiCmd && zNotFound==0);
     if( zPort ){
       int i;
       for(i=strlen(zPort)-1; i>=0 && zPort[i]!=':'; i--){}


login: nobody
mimetype: text/x-fossil-plain
icomment:
  ## Fully updated Mac OS X 10.8.4

      % uname -a
      Darwin zinc 12.4.0 Darwin Kernel Version 12.4.0: Wed May  1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64

  ## Cannot execute newest release of fossil:

      % unzip fossil-macosx-x86-20130618210923.zip 
      Archive:  fossil-macosx-x86-20130618210923.zip
      replace fossil? [y]es, [n]o, [A]ll, [N]one, [r]ename: y
        inflating: fossil                  
      % ./fossil version
      dyld: Library not loaded: /opt/local/lib/libreadline.6.1.dylib
        Referenced from: /Users/karrick/Downloads/./fossil
        Reason: image not found
      zsh: trace trap  ./fossil version

  ## Same computer, the previous version of fossil works:

      % unzip fossil-macosx-x86-20130216000435.zip 
      Archive:  fossil-macosx-x86-20130216000435.zip
      replace fossil? [y]es, [n]o, [A]ll, [N]one, [r]ename: y
        inflating: fossil                  
      % ./fossil version                          
      This is fossil version 1.25 [d2e07756d9] 2013-02-16 00:04:35 UTC


login: nobody
mimetype: text/x-fossil-plain
icomment:
  ## Fully updated Mac OS X 10.8.4

      % uname -a
      Darwin zinc 12.4.0 Darwin Kernel Version 12.4.0: Wed May  1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64

  ## Cannot execute newest release of fossil:

      % unzip fossil-macosx-x86-20130618210923.zip 
      Archive:  fossil-macosx-x86-20130618210923.zip
      replace fossil? [y]es, [n]o, [A]ll, [N]one, [r]ename: y
        inflating: fossil                  
      % ./fossil version
      dyld: Library not loaded: /opt/local/lib/libreadline.6.1.dylib
        Referenced from: /Users/karrick/Downloads/./fossil
        Reason: image not found
      zsh: trace trap  ./fossil version

  ## Same computer, the previous version of fossil works:

      % unzip fossil-macosx-x86-20130216000435.zip 
      Archive:  fossil-macosx-x86-20130216000435.zip
      replace fossil? [y]es, [n]o, [A]ll, [N]one, [r]ename: y
        inflating: fossil                  
      % ./fossil version                          
      This is fossil version 1.25 [d2e07756d9] 2013-02-16 00:04:35 UTC

  ## Same computer, download source code and compile:

      % ./configure && make
      (elided)
      % ./fossil version
      This is fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC


login: nobody
username: mgagnon
mimetype: text/x-fossil-plain
icomment:
  Seems it's not first time it happens: 

  [http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg09555.html]

  I guess someone with enough privilege will see this ticket and upload a new version soon.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  In an e-mail of 2012/12/01 the addition of three new suffixes to the list of mimetypes was requested:
  http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10235.html

  The problem is that this list is not exhaustive. If really caring for all the new extensions introduced with Office 2007 (and continued in Office 2010 and probably also Office 2013), the following list should be used as reference:
  https://office.microsoft.com/en-us/help/introduction-to-new-file-name-extensions-HA010006935.aspx

  This still does not consider the product "Access", here a list like the following one can be used:
  https://en.wikipedia.org/wiki/Microsoft_Access#File_extensions


login: nobody
mimetype: text/x-fossil-plain
icomment:
  for files in repository like:

  d1/f1
  d1/f2
  d1/f3

  if I do
  fossil mv d1 d2
  mv d1 d2

  It shows 
  MISSING d1/f1, d1/f2, d1/f3

  I wish it could rename files in sub-directory automatically.  This is a common usage when we require rename the directory.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  The "Revert to Default" option in the CSS, Header and Footer edition pages should ask for confirmation. It's far too easy to hit it by mistake and lose a lot of work (or at least have to pull it from some mirror).


login: nobody
mimetype: text/x-fossil-plain
icomment:
  It would be nice if all configuration could be done through command line. I picked just the project name as it seems to be the most obvious.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  Also <b>setting password for a newly cloned repo</b> is a bother via ui. Everytime I have to first set web-browser to lynx and then do that stuff in lynx, which is a nuisance. I usually operate remotely on servers without X...


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Steps to reproduce
  -----

  Make some changes (to existing files) and commit them to a branch (private branch used in example)
  Switch to another branch
  merge the change
  stash the uncomitted changes
  apply the stashed change
  commit

  Expected
  ------

  Stash contains changed lines
  Applying stash causes merged changes to be re-applied
  Commit contains merge.

  Actual
  ------
  Working copy reverted
  Stash contains BLANK diffs for each changed file <- This means that the diff has been lost
  Applying the stash has no effect
  Commit does not contain merge.

  This has been written up in a test script here: [https://gist.github.com/stestagg/6155515]


login: nobody
mimetype: text/plain
icomment:
  This tag closing issue for definition lists still persists
  http://lists.fossil-scm.org:8080/pipermail/fossil-users/2012-January/007943.html
  Actually this is also present in Fossil version [a89560616f], used at www.fossil-scm.org, as seen in the URL suggested in the message above,
  http://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki

  For my work, I ended up activating "use HTML as wiki markup language", converted all but links to pure HTML, but then met another problem: the first 'wiki link' in a .wiki file (only the first such link) was then rendered preceded by a spurious <p> element. (this only tested viewing locally in ckout, with version 1.22 [ab461f39af]).  Thus, now also avoiding also 'wiki links', only using HTML...


login: nobody
mimetype: text/x-fossil-plain
icomment:
  I'm using the new feature in the fossil server to server static web pages. More specifically, I'm using 0install feeds to extend fossil so that it can also serve as a package distribution server.

  This would all work fine however fossil does not recognize the *.gpg extension as pgp mime type. This is a requirement for 0install in order to check package signatures.

  Can you please add .gpg as a recognized mime-type? There is already a *.pgp but I could not fool 0install into using the renamed public key file.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  i cannot seem to find an official mimetype for these and am hesitant to just set it to application/octet-stream or text/plain. Suggestions?


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  That link should be: [http://filext.com/file-extension/GPG]
  But there's no official mimetype there.


login: anonymous
mimetype: text/x-fossil-plain
icomment:
  I'm trying to get the graphical merge tool diffuse to support Fossil, and this issue is currently holding up the works - please refer to: http://sourceforge.net/tracker/?func=detail&atid=805209&aid=3589074&group_id=157784

  In a probably related issue, finfo on the original filename does not seem to work.

  Thanks,
  Shi.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  For console processing, it would be nice if "fossil timeline -t ci" and "fossil finfo -l" had an additional option which produced one log entry per line, even if it extended beyond the terminal width. This would be useful for external tools parsing the repository activity, besides the current format which is adequate for visual inspection.

  For example, 
  $ fossil timeline -t ci
  == 2013-03-19 ==
  11:45:27 (ad72bf2392) *CURRENT* test (user: user2 tags: trunk)
  == 2013-03-07 ==
  15:23:41 (c5b25c1b6d) *BRANCH* new xml and this is a very long entry 
           that continues on next line on the console (user: user1 
           tags: trunk)
  15:22:11 (fbc698da06) hello 1 (user: user1 tags: trunk)

  and if the switch was the "-1" (1 per line) the output could be:
  $ fossil timeline -t ci -1
  2013-03-19 11:45:27 (ad72bf2392) *CURRENT* test (user: user2 tags: trunk)
  2013-03-07 15:23:41 (c5b25c1b6d) *BRANCH* new xml and this is a very long entry that continues on next line on the console (user: user1 tags: trunk)
  2013-03-07 15:22:11 (fbc698da06) hello 1 (user: user1 tags: trunk)


login: nobody
mimetype: text/x-fossil-plain
icomment:
  This can done through some SQL magic, e.g.:

  $ fossil sqlite3 repository.fossil -separator " " "SELECT DATETIME(event.mtime) as mtime,substr(blob.uuid,1,10) as id,event.comment as comment,event.user as user,tagxref.value as tags FROM event,tagxref,tag,blob WHERE event.type='ci' AND event.objid=blob.rid AND event.objid=tagxref.rid and tagxref.tagid=tag.tagid and tag.tagname='branch' ORDER BY mtime DESC;"


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Donnys-MacBook-Pro:trunk donny$ fossil stash apply 3
  UPDATE Makefile.darwin
  UPDATE Makefile.linux
  UPDATE Makefile.win32
  UPDATE NMakefile.win32
  UPDATE source/common/common.h
  ADD source/common/input_handler.h
  ADD source/common/input_handler.cpp
   "fossil undo" is available to undo changes to the working checkout.
  Donnys-MacBook-Pro:trunk donny$ fossil status
  repository:   /Users/donny/Developer/wilderness/trunk/../../fossils/wilderness.fossil
  local-root:   /Users/donny/Developer/wilderness/trunk/
  checkout:     xxxxxxxx
  parent:       xxxxxx
  tags:         trunk
  comment:      Made a variable const. (user: Donny)
  EDITED     Makefile.darwin
  EDITED     Makefile.linux
  EDITED     Makefile.win32
  EDITED     NMakefile.win32
  EDITED     source/common/common.h


  Summary: Add a file with fossil add and then save a stash. When applying the previously saved stash, the previously added files will be restored, but they have not been readded to the working copy, so fossil add must be entered manually after applying the stash. I think this is a bug if the intent of the stash is to restore the working copy to the state from when the stash was saved.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  The fossil web pages rptsql and rptedit to show and edit the sql of a ticket report show the ticket schema the user works with.

  Unfortunately the schema shown is neither the default schema found in tktsetup.c/schema.c, nor the custom schema a user may have configured (entry "ticket-table" in table "config"). Well, actually it shows part of the latter, but not all.

  At fault is the function report_format_hints() in report.c which pulls the schema for TICKET to show directly out of the fossil db. Which is nice and good, and completely forgets the table TICKETCHNG which may also exist. See the defaults referenced.


login: nobody
mimetype: text/html
icomment:
  <p>By default, Fossil uses UTC for the timestamps of commits, tickets, events, etc. This is fine when the user is <em>not</em> allowed to specify the timestamp manually. In cases where the user can edit the timestamp manually (as happens with the HTML <a href="/index.html/eventedit" title="Edit event">event edit form</a>), the user can quite easily forget that he/she might be inserting a timestamp on his/her localtime instead of the server time (UTC).</p>

  <p>The suggestion is therefore to simply include a "UTC" label right next to the "t" textfield in the Edit Event form.</p>


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  $ fossil merge trunk

  ADDED ...

  UPDATE ...

  MERGE ...

  RENAME include/GL/glfw3.h -> include/GLFW/glfw3.h

  fossil: cannot open "/Users/donny/Developer/wilderness/input_handler/include/GLFW/glfw3.h" for writing

  Rolling back prior filesystem changes...

  DELETE ...

  UNDO ...

  UNDO ...

  NEW ...

  NEW ...

  DELETE include/GLFW/glfw3.h

  $


  In the trunk I renamed <b>include/GL/glfw3.h</b> to <b>include/GLFW/glfw3.h</b> using <b>fossil mv</b> followed by a commit. In one of my branches I tried to merge the trunk into it. The file <b>include/GL/glfw3.h</b> exists in the branch, and there is no <b>include/GLFW/</b> directory. So when fossil merges with the trunk, it tries to move/rename <b>include/GL/glfw3.h</b> to <b>include/GLFW/glfw3.h</b>, but fails because no directory named GLFW exists. If I go and manually create an empty GLFW folder (include/GLFW/), fossil merge works correctly.

  This occured on Mac OS X 10.8.


login: nobody
username: Donny
mimetype: text/x-fossil-wiki
icomment:
  This also fails on Ubuntu 12.04. I have narrowed the issue to here: [http://www.fossil-scm.org/fossil/artifact/6fc0771be17cc7f5fa3162a630c6bfd0d3c9f7b4?ln=364,365]

  It appears to me that fossil_fopen will fail if an intermediate directory does not exist. I believe the solution would be to generate intermediate directories, but I do not possess enough knowledge of the codebase to introduce an elegant solution to recursively create any parent directories that are missing.


login: nobody
mimetype: text/plain
icomment:
  Markdown tables are not currently able to be styled with CSS (without styling every table in the "content" div) because they do not identify themselves with a CSS class.

  Adding a class to markdown_html.c for the table tag is a basic fix.  A better fix would be to allow the user to name the table for applying CSS, or provide inline CSS (if it can be done safely)


login: nobody
mimetype: text/x-fossil-plain
icomment:
  $ fossil help settings
   ...
     case-sensitive   If TRUE, the files whose names differ only in case
                      care considered distinct.  If FALSE files whose names
                      differ only in case are the same file.  Defaults to
                      TRUE for unix and FALSE for Cygwin, Mac and Windows.
   ...

  Is 'care' suppose to be 'are'?


login: mistachkin
mimetype: text/x-fossil-plain
icomment:
  When using a 'fossil all' command, such as 'fossil all pull' that ends up needing
  to modify a configuration setting (e.g. "always trust this SSL certificate"), it
  fails with a "database is locked" error, presumably because the parent Fossil
  process is holding a lock on it.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  While it's perfectly OK for software to start enumerating from 0, human calendar tradition starts calendaring at 1. I suspect that in the future (if not already) there could be small confusion with humans referring to week N of year Y when in fact current version refers to week N-1 of year Y. 

  Example: /timeline?yw=2013-00&n=2000 shows week 0 of year 2013, which for a human corresponds to the first week of year 2013.

  If it does not break current codebase, my suggestion is that this is resolved in favor of usual human interpretation (i.e. first week of the year is numeral 1, not 0).


login: stephan
mimetype: text/x-fossil-plain
icomment:
  The reason for this (admittedly confusing) behaviour is because the week number is calculated by sqlite3. Rather that "fudge" that calculation, it seems less problematic to use whatever sqlite3 feeds us.

  The /reports and /timeline pages share this data (it's generated by /reports and consumed by /timeline), which means that any fudging of the result would have to be done in two places.


login: stephan
mimetype: text/x-fossil-plain
icomment:
  Addenda: it's also intuitive to us (insofar as ANYTHING about our calendar can be considered intuitive!) that a year has 52 weeks, but it's possible for a calendar week to have the value 53 even though the counting starts at 0. For example:

  http://www.fossil-scm.org/fossil/reports?view=byweek&y=2007

  There is no week 0 because fossil started in the middle of the year, but there is a week #53.

  i'm not condoning this behaviour, just reporting it ;).


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Hello,

  There is a bug making it impossible to commit anything into a newly created repository.

  Here are the steps to reproduce it:

    fossil create test.fossil
    mkdir test
    cd test
    fossil open ../test.fossil
    echo "test" >testfile
    fossil add testfile
    fossil commit -m"Test commit"

  This produces the following error:
  Could not find manifest for RID 1. Possible checkout/repo mismatch.

  This is apparently caused by [7557c3e03f]. I reverted that particular change and recompiled fossil, and the problem is not happening anymore.


login: nobody
mimetype: text/html
icomment:
  As Tcl development moves to adopt more of a fossil-based workflow, we're experimenting with no longer maintaining a separate <tt>ChangeLog</tt> file. This is <i>mostly</i> OK, but one issue is that where we have a change that is a potential incompatibility, which we would have previously highlighted so that we can explicitly warn people about it in our release notes, it now tends to get lost in the list of commits.
  <p>
  What we would like would be some way to make a tag (e.g., “<tt>potential incompatibility</tt>”) have some kind of extra visual indication associated with it so that when browsing the timeline, people (and especially our release engineer!) can spot at a glance that something has happened that has a potential impact on downstream programmers. Mere background color doesn't work too well, alas, especially when a lot of different branches are being committed to in quick succession, and getting the <a href="http://core.tcl.tk/tcl/timeline?t=potential+incompatibility">history of those commits with that tag directly</a> is currently somewhat uninformative as (usually) there's no timeline-context with the other commits around. Since I'm only looking for a tweak to rendering based off the existing data model, it shouldn't involve too much work. I hope. :-)
  <p>
  If it were possible to (ab)use the mechanism for other things (e.g., flagging major feature additions) that would be cool, but that's a much less important thing. (It could even be something that is configured on a per-repository basis; that would be quite sufficient for our use-case.) But we'd rather not do it through editing the commit comment to wedge more HTML fanciness in there; there's quite enough going on in that poor field right now.


login: jan.nijtmans
mimetype: text/x-fossil-wiki
icomment:
  Suggested implementation in [13ba9a50df].
  For Tcl it works when adding the following CSS (example: red line around it):
  <pre>
  /* the format for the timeline entry with "Potential Incompatibility" */
  tr.potential td.timelineTableCell {
    padding: .1em .2em;
    border: 2px solid #ff0000;
  }
  </pre>

  Handling of multiple tags is not correct yet.


login: nobody
mimetype: text/x-fossil-plain
icomment:
  [1050] removes line

  1185     db_open_repository(zRepo);

  and breaks the fossil server, resulting in a 'Not Found' page served to the browser when you go to 127.0.0.1:8080. Happened when running fossil as root on Debian 32bit.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  If you commit a .fossil-settings\empty-dir file with, say, a path like this:

  <verbatim>
  one\two\three
  </verbatim>

  the fresh checkout will fail with a message:

  <b><i>"couldn't create directory one\two\three as required by empty-dirs setting"</b></i>

  if the directories "one" and "two" are not already existing.

  However, if you provide three lines in .fossil-settings\.empty-dir file:

  <verbatim>
  one
  one\two
  one\two\three
  </verbatim>

  in this order, it will always work regardless. This happens on Windows, if it matters.

  This bug is of minor severity, but a major pain when maintaining deep directory structures that are to be filled in later (i.e. code scaffolding, project documentation & phases etc.). It looks like an easy fix as well.


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  Does it work when using forward slashes? I don't think that backward slashes should be permitted in the "empty-dirs" setting.


login: nobody
username: ss
mimetype: text/x-fossil-plain
icomment:
  No, it doesn't matter - forward or backward slashes, same result. 

  This has been noticed by other people too, see this thread:

  http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg08038.html


login: nobody
mimetype: text/x-fossil-plain
icomment:
  RCS keywords are dollar-sign delimited strings that a revision control system like CVS interprets and automatically expands if a file is committed. These keywords allow for example to insert into a file automatically the file name and revision number and date as well as a file history log.

  Some of the usefull RCS keywords:

  $Author: $ - The user responsible for a change.
  $Date: $ - Date and time of the change, in GMT.
  $Header: $ - A collection of information: full path to the RCS file, revision number, date/time of last change (GMT), author, state, and locker.
  $Id: $ - Like $Header: $, but without the path to the RCS file.
  $Log: $ - Inserts the cvs log message. This behaves differently than other tags in that it just inserts new information after the keyword. It doesn't replace the keyword or modify existing text.
  $RCSfile: $ - Name of the RCS file in the repository
  $Revision: $ - Revision number


login: nobody
mimetype: text/x-fossil-plain
icomment:
  after a clone operation which explicitely specifies a user, e.g.,

  fossil clone http://kirk@enterprise.us/path_to_project project.fossil
   
  it still is the user name of the local account doing the clone that is defining the initial "default user". it would seem wiser to automatically create and set the default user to "kirk" in this example (i.e. to the user name specified during the clone, if any (and only fall back to local user name if this is not the case). I presume the "kirk" user should also get "v" capability (in order to be able to actually checkin). otherwise, if I forget to do
   
  fossil user add kirk
  fossil user default kirk
   
  (and  at least `fossil user capabilities kirk v', I believe) the next checkin will unintentionally use my local user name (which I even might want not be broadcasted and ending up in the timeline display of the server repo).


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  on windows xp with fossil [dda5b18b0d] compiled using mingw32, the extras command produces an empty list, while the binary downloaded from the fossil website lists all the extra files.

  example:
  <pre>
  Z:\temp>fossil init example.fossil
  project-id: 99829a416ae1c70f95fb67dbe11e34789f2cd5ed
  server-id:  b1f13b7479b0b1b445dd5f8c6eb73358967b628e
  admin-user: luisduarte (initial password is "e05114")

  Z:\temp>mkdir example

  Z:\temp>cd example

  Z:\temp\example>fossil open ..\example.fossil

  Z:\temp\example>echo some text >file1.txt

  Z:\temp\example>fossil status
  repository:   Z:/temp/example/..\example.fossil
  local-root:   Z:/temp/example/
  config-db:    C:/Documents and Settings/luisduarte/Application Data/_fossil
  checkout:     4478a15ae3770b1e158990513ccc664901aa8040 2013-10-31 15:42:19 UTC
  tags:         trunk
  comment:      initial empty check-in (user: luisduarte)

  Z:\temp\example>fossil extra

  Z:\temp\example>fossil version
  This is fossil version 1.28 [dda5b18b0d] 2013-10-31 06:03:54 UTC

  Z:\temp\example>fossil_127 extra
  file1.txt

  Z:\temp\example>fossil_127 version
  This is fossil version 1.27 [13ad130920] 2013-09-11 11:43:49 UTC
  </pre>


login: nobody
mimetype: text/x-fossil-plain
icomment:
  I use mingw32 with gcc 4.8.1 from www.mingw.org, but I've compiled version-1.27 with it using the same options (TCL, TCL_STUBS and SSL) and the extras command works fine.


login: jan.nijtmans
mimetype: text/x-fossil-plain
icomment:
  Thanks! Yes, I can reproduce it (normally I use MinGW-w64, which works fine). This certainly is a bug in latest MinGW: The changes in MinGW break operation on Windows XP, that's why in fossil the compile flag -D_USE_32BIT_TIME_T was added. But apparently adding -D_USE_32BIT_TIME_T breaks MinGW's dirent.h functions.

  I will create a minimal example, and report it to the MinGW people. Now marked as External_Bug. Conclusion: If you need Windows XP compatibility and <dirent.h>, don't upgrade to MinGW-4.0, but either use MinGW-w64 or an earlier MinGW version....


login: jan.nijtmans
mimetype: text/x-fossil-wiki
icomment:
  A solution for this bug is committed to MinGW-4.0's GIT repository (2014-01-30). See: [https://sourceforge.net/p/mingw/mingw-org-wsl/ci/f70b9c84027bd3b1e3b7dc0df4827fafd23ecf9a/]


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Hi,

  I have tried to export the SQLite repository to git, where git crashed.
  Origin fossil repo info:
  ========================
  repository:   /home/ophirset/trees/sqlite.fossil.477e22
  local-root:   /home/ophirset/trees/sqlite-fossil/
  checkout:     49be646cd981f8ff0434cf90d2748afa30260017 2013-11-04 08:56:22 UTC
  parent:       42a11e7464ab1d97d603c7409f10710ad4f1f542 2013-11-02 11:34:58 UTC
  tags:         trunk
  comment:      Fix a bug preventing FTS from correctly processing bracket
                tokens that are immediately preceded by characters that are
                neither whitespace or token characters. (user: dan)

  Command:
  ========
  fossil export --git ../repo.fossil | git fast-import

  Git version:
  ============
  git version 1.7.9.5

  OS:
  ===
  Distributor ID:	Ubuntu
  Description:	Ubuntu 12.04.2 LTS
  Release:	12.04
  Codename:	precise

  Kernel:
  =======
  3.2.0-45-generic


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Bug exists also in version 1.27 which I compiled myself from source:
  This is fossil version 1.27 [13ad130920] 2013-09-11 11:43:49 UTC

  So, this is a different bug then:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693570


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Steps to reproduce

  cd ~
  mkdir temp
  cd temp
  fossil new temp.fossil
  fossil o temp.fossil
  echo hi>hi
  fossil add .
  fossil ci -m 'Initial commit'
  fossil ui

  Now goto Timeline and it will say something like 'invalid home directory: /root '.


login: nobody
mimetype: text/html
icomment:
  <p>When displaying weekly reports for tickets (<a href="/reports?view=byweek&y=2012&type=t">see example</a>), it would be more useful if weeks with zero counts were also shown, instead of jumping between weeks without counts.</p>
  <p>Example: from week 14 to week 29 (<i>note: week number starts from zero!...</i>) of year 2012 there are no tickets. Since the purpose of these reports is to show a plot for inspection, it's useful if different years have similar scales. It might be confusing if different years have time scales that don't match.</p>


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  It would be great to have the ability to update a fossil repo without having to open the repo first.

  usage:  fossil update repo.fossil


login: nobody
mimetype: text/plain
icomment:
  commands:
  git clone git://git.minix3.org/minix
  cd minix
  git fast-export --all | fossil import --git ~/minix.fossil

  Now the minix git repo is 187mb but for some reason the minix fossil repo grows up to 1gb and doesn't stop.


login: nobody
mimetype: text/plain
icomment:
  I know, it's not really an code defect, but...

  I mean, Fossil SCM is addressed potentially also to SVN users, who do not want GIT but the power of GIT. A direct import from SVN projects without GIT proxy would be nice. You would not have to bother with kurds GIT-stuff and version history would also look better.

  Yes, it's a mental thing, but a hurdle.

  Line breaks \n in the version history would perhaps also not a bad idea?

  Fossil is a really cool SCM, but the migration is not the easiest. :/

  Finally of course a thanks for this software. Future users can also make a detour around GIT hopefully soon.

  Sorry for my rude tone and bad English. :(


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  The changelog for version 1.26 claims "The markdown formatter is now available by default and can be used for tickets, wiki, and embedded documentation."

  This would appear to be true for the wiki, but it does not appear to be true for tickets (for example as I edit this ticket at [http://www.fossil-scm.org/fossil/tktnew] the list of format options is wiki/HTML/plain text/[links only] and this is also true of new repositories that I have created using version 1.27 on my local machine). So is the changelog wrong, or is some extra documentation needed to show how to enable markdown in the ticket editor?

  P.S. Some documentation about how to use markdown syntax to link to fossil entities would be gratefully received, but I realise that's a different bug.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  The fossil import command does not support being given an filename to take input from - it only supports taking input from stdin.

  I don't believe a windows equivalent of 'cat repo.fi | fossil import repo.fossil' exists, so it would be great if 'fossil import repo.fi repo.fossil' did what was expected. (You might need to make it 'fossil import --input repo.fi repo.fossil' or similar to avoid breaking existing scripts).

  Thanks!


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Refering to email discussion, e.g. this:

  [http://lists.fossil-scm.org:8080/pipermail/fossil-users/2013-February/011833.html]

  I suggest that this is implemented gradually. If nothing more, then the documentation could at least describ the current possibilities, even if it consists of nothing more than altering the menus in the Web UI.


login: stephan
mimetype: text/x-fossil-wiki
icomment:
  i18n of Fossil is not feasible without a complete and utter rewrite. Much of the text is interwoven with SQL code, and the current mechanism for generating parameterized text (printf-like functions) does not port 1-to-1 for many sorts of translations (e.g. where arguments need to have a different order). There's no practical way to do this in the current code base. That said, libfossil is being developed to allow (amongst other things) the creation of localized UIs: http://fossil.wanderinghorse.net/repos/libfossil/


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  Hi,

  Fedora has packaged it into official repo, however maintainer sometimes forgets the update so we invent a monitoring tool:

  https://fedoraproject.org/wiki/Upstream_release_monitoring

  However we can't track fossil's update since this project neither has a public download folder can be accessed from public nor has mentioned any tarball link on download page.

  The only link to tarball is fossil- , with a lot of numbers. I hope you can:

  1. Since the tarballs are stored in

  http://www.fossil-scm.org/download/

  like

  http://www.fossil-scm.org/download/fossil-src-20140127173344.tar.gz

  I hope you can make this dir

  http://www.fossil-scm.org/download/fossil-src-20140127173344.tar.gz

  public.

  2. Name the tarball in style:

  fossil-src-$(VERSION).tar.gz

  Okay?

  Thanks!


login: stephan
mimetype: text/x-fossil-wiki
icomment:
  You can construct the URL to pull the version you want, and to name the tar file how you like, by passing the right URL params. See:

  [http://www.fossil-scm.org/index.html/help?cmd=/tarball]

  e.g.

  /tar/fossil-trunk.tar.gz?uuid=trunk

  will cause the file fossil-trunk.tar.gz to be downloaded, and inside the tar the top-level dir will be named fossil-trunk.

  or:

  /tar/foo.tar.gz?uuid=trunk&name=fossil-trunk

  which will name the download foo.tar.gz but will (inside the tar) have a directory name of fossil-trunk.


login: anonymous
mimetype: text/x-fossil-wiki
icomment:
  The /reports page is accessible to any unauthorized user (aka nobody). I think this should be configurable like the access to any other page in fossil as well.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  Downloaded and built fossil 1.28 from source on Win7 64bit with JSON and openssl. Windows binary downloaded from the www.fossil-scm.org also does this.

  C:\Users\xxx\Desktop>fossil all rebuild <P>
  C:\oss\bin\fossil.exe rebuild C:/Users/xxx/fossil-repos/fossil.fossil <P>
    100.0% complete... <P>
  C:\oss\bin\fossil.exe rebuild C:/Users/xxx/fossil-repos/sqlite-docs.fossil <P>
    100.0% complete... <P>
  C:\oss\bin\fossil.exe rebuild C:/Users/xxx/fossil-repos/sqlite.fossil <P>
    100.0% complete... <P>
  C:\oss\bin\fossil.exe rebuild C:/users/xxx/fossil-repos/fossil.fossil <P>
    100.0% complete... <P>
  C:\oss\bin\fossil.exe rebuild C:/users/xxx/fossil-repos/sqlite-docs.fossil <P>
    100.0% complete... <P>
  C:\oss\bin\fossil.exe rebuild C:/users/xxx/fossil-repos/sqlite.fossil <P>
    100.0% complete... <P>

  C:\Users\xxx\Desktop>fossil version <P>
  This is fossil version 1.28 [3d49f04587] 2014-01-27 17:33:44 UTC <P>


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  RECONSTRUCT fails on Win7 (64-bit) with message "cannot open ??? for reading" where ??? is the filepath. Previous versions (1.27) work fine.


login: anonymous
mimetype: text/x-fossil-wiki
icomment:
  RECONSTRUCT fails on Win7 (32-bit & 64-bit) with message "cannot open ??? for reading" where ??? is the filepath. Previous versions (1.27) work fine.


login: jan.nijtmans
mimetype: text/x-fossil-wiki
icomment:
  Well, the "reconstruct" command, implemented in src/rebuild.c
  didn't change basically, I cannot reproduce neither explain it.
  Did you compile from source or are you using the downloaded .exe?
  How does your path look like? It it on an external drive?


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  I used the downloaded prebuilt EXE.

  The problem is there in all fossil files I have (about 6 of them, from 1 to 12MB each).  But since I cannot provide any of those, I'm trying to make a different one that shows the problem.

  I tried with a new file containing only a couple of files and it didn't show a problem.  So, I guess it has to be something more complex that triggers this.  Give me some time, and I'll come back with an example file.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  OK, rather than trying to come up with a test case, I tried with the SQLite fossil file, and the problem is there.  (I know it's not the smallest possible test case, but at least it shows the problem.)

  To reproduce the problem, run the following commands from the Win7 DOS prompt:

  -----------------------------------------------------------------

  fossil clone http://www.sqlite.org/cgi/src sample.fossil
  md somedir
  fossil dec somedir -R sample.fossil
  fossil rec new.fossil somedir

  -----------------------------------------------------------------

  The output from the above is:

  -----------------------------------------------------------------

  C:\Temp>fossil clone http://www.sqlite.org/cgi/src sample.fossil
  Round-trips: 6   Artifacts sent: 0  received: 49495
  Clone finished with 1469 bytes sent, 29081473 bytes received
  Rebuilding repository meta-data...
    100.0% complete...
  project-id: 2ab58778c2967968b94284e989e43dc11791f548
  admin-user: Tony (password is "8b2d69")

  C:\Temp>md somedir

  C:\Temp>fossil dec somedir -R sample.fossil
    100.0% complete...

  C:\Temp>fossil rec new.fossil somedir
  Reading files from directory "somedir"...
  205
  cannot open somedir/00 for reading

  C:\Temp>

  -----------------------------------------------------------------

  Hope this helps!


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  I don't know why the formatting was messed up.  Here are the commands again.

  fossil clone http://www.sqlite.org/cgi/src sample.fossil

  md somedir

  fossil dec somedir -R sample.fossil

  fossil rec new.fossil somedir


login: stephan
mimetype: text/x-fossil-wiki
icomment:
  Hi! There is a _potential_ fix in [8e110293edfa93c6b2da7f45bbc76f5f782ef728]. Please try that out and let us know. Thanks for your extremely detailed report - it made localizing that problem simple. That said, that fix might not have been the source of your specific woes (but it's at the same code spot) - we won't know until you can try it out.


login: stephan
mimetype: text/x-fossil-wiki
icomment:
  Author responded via email - problem is still happening :(. Looking at the code, i can see no reason for it.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  [I'm afraid I was misunderstood.  I did not say the problem is still there.  I said I cannot compile the version with the changes you proposed because the given build process is faulty, or does not work as given (on two different PCs I tried).  I suppose the actual Windows version available for download is produced from Linux by cross-compilation, and not compiled on a Windows PC, and so the makefiles are not tested in 'real life' from a Windows PC.

  Regarding compilation, I used the USE_WINDOWS conditional in the makefile.mingw32 but I still get the following error during compilation:

  gcc -o wbld/makeheaders src/makeheaders.c

  mingw32-make: *** No rule to make target 'src/../manifest.uuid', needed by 'wbld
  /VERSION.h'.  Stop.

  If anyone can help with get a clean AND working compilation from a Windows PC using MinGW, I'm all ears.  Sorry for the confusion.]

  Regarding this ticket, I noticed the original problem with the precompiled EXE but since I cannot recompile myself, I cannot test your changes.  My compilations always crash, irrespective of the bug fix being applied or not, simply because the compilation process does not produce a proper EXE.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  I tested the latest? [4adcd4f4f5] with a VC compiled copy (which -- unlike the MINGW makefile -- compiles without any problems) and both DEC and REC work great.  So, I consider this fix did the trick.


login: anonymous
mimetype: text/plain
icomment:
  Thank you for two great pieces of software. I've been using SQLite in projects of all sizes for the past eight years. When I discovered Fossil, I knew it would be the same; simple, powerful, correct!

  After starting a project in Fossil, in part due to the support for Unicode filenames, I discovered that the Windows version only supports some characters. I started on v1.27 and later upgraded to v1.28, which is equally affected. When trying to add files with an unacceptable character in the name, fossil says "not found: [filename]" although the files show up when I run fossil extra. After running out of other ideas, I booted into Linux to try the same files there. With my NTFS volume mounted in Linux, I was able to add to the repo the files with troublesome characters in their names with absolutely no hassle. Booted back into Windows, I was then able to retrieve those files from the repo. So, fossil on Windows can see the files (they appear in extras), it can create the files on disk if they exist in the repo, but it can't add the files to the repo if they only exist on disk.

  I am unsure what the exact problem is. Most files have only simple Latin characters without accents, but some have diacritic marks used in Slavic languages. Here is a summary of the accented characters encountered thus far in my project. Perhaps there is a pattern that is not obvious to me.
  Characters which are accepted include: é (e acute), í (i acute), š (s caron)
  Characters which are not accepted include: č (c caron), ě (e caron)

  I considered the possibility that the real problem is cmd.exe since it shows only the base letters without accent. I have been using ? or * in place of accented characters and that seemed to work fine for characters in the first list but not those in the second. I tried running Fossil under PowerShell only to see it's exactly the same (why am I unsurprised Microsoft wrote a new shell without proper Unicode support). I tried the Fuel GUI to try to take the CLI out of the picture but it's the same situation. Fuel shows the files as untracked but attempting to add any of them results in the not found message.

  I hope this report does not fall on deaf ears as threatened by the large red text. I attempted to discuss this on the mailing list before making the report, but was unable to do so. I sent a message to the list last night but as of this evening it still does not appear in the list archives. It is unclear if the list is moderated or completely closed to non-subscribers.


login: jan.nijtmans
mimetype: text/x-fossil-wiki
icomment:
  No, actually it's a problem in MinGW. See:
      [https://sourceforge.net/p/mingw/bugs/771/]
  If you compile with MinGW-w64 (32-bit or 64-bit) everything works fine.


login: anonymous
mimetype: text/plain
icomment:
  Thank you for the pointer to the bug in MinGW. On Linux I compiled from source, but on Windows I have been using the binaries provided. If the cause of the Unicode handling problem is the way those binaries are compiled, then it is not a defect in the source code, but still a defect in the distributed binary code. Is there some particular reason to not compile with the corrected MinGW?

  (Changing type from code_defect to build_problem in light of the information.)


login: jan.nijtmans
mimetype: text/x-fossil-wiki
icomment:
  Build instructions for Cross-compiling on Ubuntu (or any other OS which has a MinGW-w64 cross-compiler):
  <pre>
  sudo apt-get install mingw-w64
  cd <fossil>/compat
  tar xfz <path-to>/openssl-1.0.1f.tar.gz
  cd ..
  make -f win/Makefile.mingw.mistachkin PREFIX=i686-w64-mingw32- openssl fossil.exe
  i686-w64-mingw32-strip fossil.exe
  </pre>
  That's it. (be patient, the "make" line takes about 5-10 minutes depending on the speed of your machine/hard-disk)


login: jan.nijtmans
mimetype: text/x-fossil-wiki
icomment:
  Fossil (1.29) binaries in which this problem is fixed can be downloaded from:
      [http://sourceforge.net/projects/cyqlite/files/fossil/]
  both for win32 and win64.


login: jan.nijtmans
mimetype: text/x-fossil-wiki
icomment:
  Fossil binaries in which this problem is fixed can be downloaded from:
      [https://sourceforge.net/projects/cyqlite/files/fossil/]
  both for win32 and win64


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  I'm utilizing <b>th1-setup</b> for preparing some userland TH1
  functions, e.g. [http://fossil.include-once.org/fossil-skins/artifact/c045a209b62c207a6630e4e1792b871055364d26|th1x.tcl]

  Now it's usually multi-line when injected via <kbd>fossil setting th1-setup "$(cat th1)"</kbd>. In the fossil web UI it's displayed as <code>&lt;input type=text&gt;</code> however, where most browsers will turn linebreaks into spaces. Subsequently editing <em>any</em> setting via <kbd>fossil ui</kbd> will break th1-setup.

  Hence I'd prefer if it became a <code>&lt;textarea&gt;</code> input field as well (like <code>binary-glob</code> etc.), so it retains formatting and doesn't break the TH1 code due to comments or lack of semicolons.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  I'm using the pre-compiled Windows version on a Win7 machine.

  Here's the error message I got while doing a FOSSIL STASH DIFF command:

  "Assertion failed: (pBlob)->xRealloc==blobReallocMalloc || (pBlob)->xRealloc==blo
  bReallocStatic, file src/blob.c, line 187

  This application has requested the Runtime to terminate it in an unusual way.
  Please contact the application's support team for more information."

  And the contents of the stash as seen by the STASH LIST command:

  C:\temp>f stas l

      3: [69109aec500908] on 2014-02-18 10:55:49

         xxxxxx whatever xxxxxxx


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  On the Tk tracker at:
  [https://core.tcl.tk/tk]
  there were a new ticket to moderate.
  I wanted to delete the ticket as it was a duplicate.
  So check "Delete" and press "Ok". The procedure is ok but the shown page shows the following text:
  <verbatim>
  Last modified: no such variable: tkt_datetime
  </verbatim>


login: nobody
mimetype: text/plain
icomment:
  The "fossil stash" command does not seem to understand "fossil mv". When a stash is restored, the files are given their old names.


  $ fossil new test.fossil
  $ mkdir test
  $ cd test
  $ fossil open ../test.fossil
  $ echo moo > file
  $ fossil add file
  $ fossil commit -m add
  $ mv file file2
  $ fossil mv file file2
  $ fossil stash save -m rename
  $ fossil ls
  file
  $ fossil stash show
  CHANGED file2
  --- file2
  +++ file2
  $ fossil stash pop
  UPDATE file2
  $ fossil changes
  MISSING    file
  $ fossil extras
  file2

  (Originally reported to the mailing list 17 March 2014, though there have been no replies as of today.  Reference http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg14953.html)


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  If you have, say, *.zip in ignore-blob, and have
  xxx.zip (lowercase) and YYY.ZIP (uppercase) then only xxx.zip is ignored.


login: nobody
mimetype: text/plain
icomment:
  Using the latest version gives problems on a network drive while the previous version works as expected. I've tested it 5 times with exact the same results. 

  fossil-1.28.exe init abc.fossil
  Fossil internal error: read permission denied for repository abc.fossil

  fossil-1.27.exe init def.fossil
  project-id: 53b1a51d67dc8197b1df73c5b221fb03dddf611a
  server-id:  a436da6767715b767a54[...]

  OS: virtual win8.1 (parallels)


login: jan.nijtmans
mimetype: text/plain
icomment:
  Two questions:
    - Doing "fossil-1.28.exe init abc.fossil", is the file "abc.fossil" actually created? If so, what rights does this file have? What rights does the directory have?
    - If you do "fossil-1.28.exe init abc.fossil" in another directory (C-drive), and then copy this file to your network drive. Does it work then?


login: nobody
mimetype: text/x-fossil-wiki
icomment:
    - Doing "fossil-1.28.exe init abc.fossil", is the file "abc.fossil" actually created? If so, what rights does this file have? What rights does the directory have?

  Its a windows share with no special 'chmod' rights. I'm the owner of the directory so i can read/write without problems. A file does get created. But if i use fossil ui abc.fossil, i again get a read permission denied. 

    - If you do "fossil-1.28.exe init abc.fossil" in another directory (C-drive), and then copy this file to your network drive. Does it work then?

  If i create a fossil on a local drive (where it works correctly) and copy it to a network drive, i again get a read permission denied error.


login: jan.nijtmans
mimetype: text/x-fossil-wiki
icomment:
  Possible fix in [969f0a2611]. My theory is that the AccessCheck() function call failes because in your situation there are more than one Privilege active. See [http://msdn.microsoft.com/en-us/library/windows/desktop/aa374815%28v=vs.85%29.aspx].

  Does this help?


login: nobody
username: kwizzz
mimetype: text/x-fossil-wiki
icomment:
  Got the same issue here.  Reason:

    *  Linux Samba share with its own local domain.
    *  cacls from windows states """<Account Domain not found>(special access:)""" for each account rights

  If I grant full access to Everyone, the error disappears (of course).


login: anonymous
mimetype: text/plain
icomment:
  The nowiki tag does not seem to work if it is the first line in a file.

  Moreover, multiple nowiki tags don't seem to work properly.
  For example, in the following WIKI+HTML, the first table is fine,
  but in the second the <hr> tag, Option" ends up with <p> tag in it
  which causes an the header to be very tall.

  BTW: fossil is great.

  Regards,
  Peter
  --------------------
  Some
  <nowiki>
  <table border='1'>
  <tr><th>Option</th><th>Description</th></tr>
  <tr><td>A</td><td>B</td></tr>
  </table>
  </nowiki>
  More

  <nowiki>
  <table border='1'>
  <tr><th>Option</th><th>Description</th></tr>
  <tr><td>A</td><td>B</td></tr>
  </table>
  </nowiki>

  ------------
  <p>Some

  <table border="1">
  <tr><th>Option</th><th>Description</th></tr>
  <tr><td>A</td><td>B</td></tr>
  </table>

  More 


  <table border="1">
  <tr><th><p>Option</th><th>Description</th></tr>
  <tr><td>A</td><td>B</td></tr>
  </table>
  --------------------


login: stephan
username: stephan
mimetype: text/x-fossil-wiki
icomment:
  NOWIKI does _not_ block normal HTML Tags, only wiki-specific markup (braces and such).

  i'll take a look at the no-effect-on-the-first-line bit this weekend (sounds like an off-by-one, but it might just be a misunderstanding of what nowiki is supposed to do). i use multiple NOWIKI tags in pages very often with no problems.


login: anonymous
username: peter
mimetype: text/plain
icomment:
  Thanks for the quick response.

  To clarify the 2nd problem: NOWIKI is not blocking HTML tags, but rather inserting a <p> tag in the <th>.

  Perhaps I misunderstand it's intent, but I thought NOWIKI was designed to not do any wiki processing on a block.

  There is no problem using multiple NOWIKI for simple cases. But there is with text nested between other tags.

  For most content, inserting <p> tags would not be a problem.
  But with tables, a <p> in the <th> causes the height to double.


login: stephan
mimetype: text/x-fossil-wiki
icomment:
  Hi, thanks for the feedback!

  i cannot reproduce a problem with NOWIKI on the first line. The problem regarding the P flag i am going to justify with the following semi-lame explanation: NOWIKI is not really intended to enclose whole block-level structures such as tables, and doing so may cause unwanted side-effects in conjunction with block-level constructs which the parser takes a substantial interest in. i do not have a definitive list of which tags that might be, but i know (e.g.) that PRE inside NOWIKI works fine, while you have demonstrated that a TABLE block (or the TH inside it) is apparently not side-effect-free (in that it generates a spurious P tag).

  Here is an example of a page which uses multiple NOWIKI PRE /PRE /NOWIKI blocks without any problems:

  [http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/artifact/582cf57813cf8864a636f686d84b29839764cd65]

  i'll leave this open for the time being, as the spurious P "really shouldn't" be generated, but any changes to the wiki parser, in particular for edge cases, are not likely to get much priority.


login: anonymous
username: Peter
mimetype: text/plain
icomment:
  Ok. Not really looking for problems to be fixed, though. Mostly I opened the bug for the benefit of future fossil wiki users experiencing similar problems

  The language in the documentation could perhaps be softened, to wit:

    The <nowiki> tag disables all wiki formatting rules through the matching </nowiki> element

  Irregardless, I've found another problem with NOWIKI (below) which (maybe) sheds some light on the first bug. Essentially, it turns out a missing </a> tag for a label is causing the parser go get confused.  The wiki does not recognize the self closing tag (which is fair) but instead reads forward to the other <a> end tag.

  Regards, and hope this helps.

  ------------------------------------------
  <nowiki>
  <b>START</b>
  <a name="MYLAB" />

  <table border='1'>
  <tr><td>A</td><td>1</td></tr>
  <tr><td><a href='#MYLAB'>B</a></td><td>2</td></tr>
  <tr><td>C</td><td>3</td></tr>
  </table>

  <b>END</b>.
  </nowiki>
  -----------------------------------------
  <p><b>START</b>
  <a name="MYLAB">

  <table border="1">
  <tr><td>A</td><td>1</td></tr>
  <tr><td></td></tr></table></a><a href="#MYLAB">B</a>2
  C3


  <b>END</b>.
  -----------------------------------------


login: anonymous
mimetype: text/x-fossil-wiki
icomment:
  In generating the debian package of fossil 1.29, the build system coughed up the following warning:

  dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/fossil/usr/bin/fossil was not linked against libreadline.so.6 (it uses none of the library's symbols)

  dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/fossil/usr/bin/fossil was not linked against libdl.so.2 (it uses none of the library's symbols)

  I manually invoked the linking command with -lreadline -ldl removed, and by gum it was right!

  Either I'm missing some options I should be passing ./configure or something unnecessary is going on.

  Cheers,

  --Barak.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  I need fossil binaries for IBM AIX Machine. How can i download and complile it. Please help me on getting Binaries for IBM AIX.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  <h2>"fossil pull; fossil update --latest" won't advance to remote latest check-in (trunk)</h2>

   <b>Environment:</b>
    *  <b>fossil:</b> 1.29
    *  <b>repository server:</b> freebsd 9.3
    *  <b>Workstations:</b> Windows 7

  <b>Repository purpose:</b><br />
    *  Fossil's repository used for synchronization of configuration files between workstations. 


  <h3>Workflow:</h3>


  ### <b>1.</b> Initialization on the server:
  <verbatim>
      fossil new --admin-user "root" "/var/db/repo/configs.fossil"
      fossil server --port 8123 "/var/db/repo/configs.fossil" &
  </verbatim>


  ### <b>2.</b> Workstation #1 autosync:on
  <verbatim>
      fossil clone http://remote.server:8123/configs /path/localrepo.fossil
      cd workdir-with-files
      fossil open /path/localrepo.fossil
      fossil add .
      fossil commit -m "Initial commit"
  </verbatim>


  ### <b>3.</b> Workstation #2 autosync:on
  <verbatim>
      fossil clone http://remote.server:8123/configs /path/localrepo.fossil
      cd workdir-with-files
      fossil open /path/localrepo.fossil
  </verbatim>
  make changes to files then 
  <verbatim>
      fossil addremove .
      fossil commit -m "changes"
  </verbatim>
  timeline on the server updated as it should to the latest commit from Workstation#2



  ### <b>4.</b>Workstation #1 autosync:on
  <verbatim>
      fossil update --latest
  </verbatim>
  timeline stuck on previous stage and won't pick up changes pushed to server from Workstation#1

  attempt update manually  will fail too
  <verbatim>
      fossil pull
      fossil update --latest 
  </verbatim>


  <b># Workstation#1 can't see latest changes in remote repository</b>
  and <code>fossil update --latest</code> wrongly report: "Already up-to-date"
  <verbatim>
      fossil branch
  </verbatim> 
  does not show any new branches neither on server or workstations


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  Two points.

   * The `help` command (short version) should list the commands obviously associated to the ones it list. Ex. `fossil help` list `open` but does not list `close` which is only listed by `help -a`. That's confusing.

   * Alternatively, the `help` command (short version) could be aware of the local state. Ex. in a directory which is not that of an opened repository, it could list `open` only, and list `close` (and not `open` any‑more) from the directory of an opened directory.


login: wyoung
mimetype: text/x-fossil-wiki
icomment:
  The second point sounds good, but doing that will probably not allow us to remove as many commands as you'd think due to the <tt>-R</tt> flag.

  For example, a <tt>fossil conf sync skin</tt> command will fail if you're not in a checkout directory, but you can add <tt>-R /path/to/repo.fossil</tt> to tell it which repo's skin you want synchronized.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  I'm running fossil through the following CGI script, and everything works as expected:

  <code>#!/var/webs/www.example.com/public_html/cgi-bin/fossil<br>
  directory: /var/webs/www.example.com/public_html/fossil/<br>
  #repository: /var/webs/www.example.com/public_html/fossil/PROJECT.fossil<br>
  notfound: http://example.com/fossil-notfound.html</code>

  However, when navigating to the CGI script without indicating a repository name in the URL (i.e. just <code>http://example.com/cgi-bin/fossil.cgi</code> instead of <code>http://example.com/cgi-bin/fossil.cgi/REPOSITORY</code>), I get a website with the following error:

  <code>Server Error (500): Premature end of script headers: fossil.cgi</code>

  A <code>fossil.core</code> dump file is created, and the following error is logged to the webserver error log:

  <code>[Tue Aug 01 01:01:01 2014] [error] [client 000.000.000.000] Assertion failed: (fossil_strcmp(&zRepo[j], ".fossil")==0), function process_one_web_page, file ./src/main.c, line 1324., referer: http://example.com/cgi-bin/</code>

  Redirection to the error page works fine if the repository was not found, or the repository file is invalid, so I feel there should be similar error handling for the case when the repository name is omitted.


login: bharder
mimetype: text/x-fossil-wiki
icomment:
  working w/ local git repo branch of vendor support-code, "fossil rm" was silent, unfunctional when attempting to remove newly non-existent files. "fossil chan | grep ^MISSING" repeated indicated files were missing, "fossil rm", "fossil delete" would not remove them.


login: bharder
mimetype: text/plain
icomment:
  Reference transcription
  =======================

  kamloops$ fossil chan
  kamloops$ fossil ls  |grep Smake
  Smakefile
  kamloops$ rm Smakefile
  kamloops$ fossil chan
  MISSING    Smakefile
  kamloops$ fossil rm Smakefile
  DELETED Smakefile
  kamloops$ fossil chan
  MISSING    Smakefile
  kamloops$ fossil version
  This is fossil version 1.30 [90e75800c1] 2014-09-10 11:22:21 UTC
  kamloops$ fossil rm Smakefile
  kamloops$ fossil rm Smakefile
  kamloops$ fossil rm Smakefile
  kamloops$ fossil chan
  MISSING    Smakefile
  kamloops$ fossil ci
  missing file: Smakefile
  aborting due to prior errors
  kamloops$


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  Line 87 of the "Shadow boxes & Rounded Corners" (No. 5) skin default CSS looks like:

  <code>div.sectionmenu>a.button:link, div.sectinmenu>a.button:visited {</code>

  It should probably be changed to:

  <code>div.sectionmenu>a.button:link, div.secti<u>o</u>nmenu>a.button:visited {</code>


login: baruch
mimetype: text/x-fossil-wiki
icomment:
  When a file was checked in 2 different times (for example: artifact [http://www.fossil-scm.org/index.html/artifact/e1b4641cbf24acca1e88f45bba80fe9f1154bf73|e1b4641cb] was checked in here [http://www.fossil-scm.org/index.html/ci/1eb438d61a6db40db32dc700a0ea7e90e59861a5|1eb438d61a] and merged to trunk at [http://www.fossil-scm.org/index.html/info/ec81aee9156f43f45021592062d70d2829f43703|ec81aee915], and a second time here [http://www.fossil-scm.org/index.html/info/77f53423aec1d2ebe8d2912822224aef2d664215|77f53423ae]) we can end up with a wrong timeline, like this: [http://www.fossil-scm.org/index.html/finfo?name=src/import.c&a=2013-10-06&b=2014-08-16]

  In that timeline, there is a fork in the trunk based at ec81aee915, while in fact the correct sequence of events was that the same file was checked in again between the two "heads" of the trunk (at 77f53423ae).
  Both the second checkin of the file and the linearity of the trunk timeline are missing from that page.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  Currently, the message:
  "REMINDER: this was a dry run - no file were actually changed."
  will show up for "merge" dryrun option.
  This is very helpful.

  Request to add this message on "update" when dryrun option is set.


login: anonymous
mimetype: text/x-fossil-wiki
icomment:
  The main Fossil branch is called "trunk", while the main git branch is called "master".  After you've exported your FOSSIL repo to git, you won't see any files and gitk will complain about a missing "HEAD".  You can resolve this problem by merging "trunk" with "master" (first verify using <code>git status</code> that you are on the "master" branch): <code>git merge trunk</code>


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  WHEN I use commit -M file .If the File was code in UTF-8 and with Chinese.
  Then in Timeline page the Chinese was Garbled.
  I think it's need to check commit message File ,if it was UTF-8 then do not convert.


login: jan.nijtmans
mimetype: text/x-fossil-wiki
icomment:
  Fossil checks whether the file contains a BOM (for either UTF-8 or UTF-16) and does the appropriate conversion then. If the file does not contain a BOM, it assumes CP1252. On Windows, it is customary to start a file with the UTF-8 BOM, otherwise editors like Notepad will interpret the data wrong as well.

  Regards,
        Jan Nijtmans


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  Batch file contents to reproduce problem on a Win7 machine.

  <verbatim>
  @echo off
  echo Reproduce fossil issue with read-only overwrite failure consequences
  echo (where f = fossil)
  f ver -v
  f new sample.fossil
  md xxx
  dir > xxx\aaa
  cd xxx
  f o ..\sample.fossil
  f add aaa
  f com -m "Initial"
  f close
  echo Make some changes to our file
  dir ../s > aaa
  attrib +r aaa
  echo Answer Y or A(ll)
  f o ..\sample.fossil
  echo Failed to update.  Let's remove the read-only status, and see...
  attrib -r aaa
  f cha
  f rev
  f com
  echo Nothing shown here.  But, if we close and re-open the repo.
  f close
  echo Answer N
  f o ..\sample.fossil
  f cha
  echo Obviously, there are changes!!!
  </verbatim>


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  auto.def adds $tclconfig(TCL_INCLUDE_SPEC) to EXTRA_CFLAGS, and in this case that include directory happened to contain a config.h file, causing the fossil build to fail. directories in the fossil distribution that contain header files should always be included before any EXTRA_CFLAGS that may get set to cope with the platform.  

  In this case, the workaround was:

  CC = "$CC -I. -I./src


login: bharder
mimetype: text/plain
icomment:
  kamloops$ mkdir jnkjnk
  kamloops$ cd jnkjnk/
  kamloops$ ../fossil/fossil clone http://core.tcl.tk/tcl ./myrepo.fsl
  Round-trips: 23   Artifacts sent: 0  received: 36622
  SQLITE_CORRUPT: database corruption at line 53693 of [4461bf045d]
  SQLITE_CORRUPT: statement aborts at 21: [UPDATE blob SET rcvid=1,
  size=167, content=:data WHERE rid=39319]
  ../fossil/fossil: SQL error: database disk image is malformed

  If you have recently updated your fossil executable, you might
  need to run "fossil all rebuild" to bring the repository
  schemas up to date.

  kamloops$ ../fossil/fossil version
  This is fossil version 1.30 [156ef9ec06] 2014-11-26 14:53:41 UTC


  This does _not_ happen w/ release 1.29


login: bharder
mimetype: text/x-fossil-wiki
icomment:
  drh confirmed the bad behaviour and bisected, apparently identifying [6b2f0b209f9988153cfaf0ac5d5930bfa8d139fe] ("Update to 3.8.8 alpha of SQLite...") as culprit.


login: anonymous
mimetype: text/plain
icomment:
  As discussed here: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg18203.html

  --
  The repository contains a directory "b" full of files, and a directory
  "a" containing about 256 nested directories, with a single file at the
  deepest point.

  On Windows 7, if I'm at:

    c:\cygwin64\home\someone\fossil\fossil-pathbug

  (Don't let the name fool you, I'm using the latest fossil binary from
  fossil-scm.org and am running it under the ordinary cmd.exe, not
  cygwin).

  ... and I attempt to "open" the fossil-pathbug.fossil repository:

  c:\...\fossil-pathbug> fossil open ..\fossil-pathbug.fossil
  unable to create directory 
  c:/cygwin64/home/someone/fossil/fossil-pathbug/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a...

  (Extra 'a's omitted as cmd.exe doesn't seem to allow copying and pasting).

  This would be fine, except that it seems like it leaves the working copy in 
  some sort of inconsistent state: A listing of the directory shows no "b" 
  directory, a "fossil stat" shows no missing files. None of the commands 
  such as "fossil update" will check out the remaining files (the commands 
  will silently return success, apparently).

  I'm using fossil 1.29 from the site (3e5ebe2b90).
  --

  See attached repository.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  The rename command documentation is too vague, it seems to suggest that fossil mv is enough to do a rename. It states clearly that fossil won't alter the filesystem to do the actual rename/move operations, but the fact is that the operations are expected to be done *before* requesting it to fossil, or the request is not going to be honoured.

  Reference to the documentation:

  http://www.fossil-scm.org/index.html/help?cmd=rename

  I don't know if this is the source for the manpage and other authoritative documentation. The problem should be fixed on the authoritative documentation.

  I found some parts of this discussion useful to understand what was going on:

  http://stackoverflow.com/questions/1907837/renaming-directories-with-the-fossil-dvcs


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  <b>Prerequisite:</b><br>
  Usage of fossil under Microsoft Windows, where case sensitivity is disabled by default.

  <b>Problem description:</b><br>
  When the name of a directory is changed by just altering some characters from lowercase to uppercase (or vice versa), the outputs of the timeline and files listings look strange, showing a wild mix of files in a directory with the old name and in a directory with the new name. Both directory names may show up several times in an alternating manner which is not only confusing to the user but does not reflect the actual situation in the file system itself.
  This is valid even when looking at just a single check-in, e.g. trunk, not the "all" files link.

  It appears that fossil is (at least partially) aware of both the old and the new names and differentiates them internally where it shouldn't do so (or where it should use just the new name), leading to the mangled output. Assumption(!): the actual files are simply listed alphabetically, but as some of them "belong" to the previous directory name, and others are linked to the new name, both names are unnecessarily inserted as hierarchy elements on each switch between both. 

  <b>More information:</b><br>
    *  The issue was originally discussed here: [http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg18217.html|message on mailing list]
    *  A "minimum example" repository which demonstrates the problem is available here: [http://ge.tt/2FYa9K52/v/0|demo repository]
    
  <b>Problem recreation:</b><br>
  The following code (save as a batch file under Windows, with ".cmd" file extension) creates the repository linked above.
  <code>
  <verbatim>
  @echo off
  rem The following script was provided by Ross Berteig. Thanks!

  rem Run this in an empty folder where it is safe to create and use a
  rem fossil repository.
  fossil new abc.fossil
  fossil open abc.fossil
  mkdir A
  cd A
  echo a >a.txt
  echo c >c.txt
  echo e >e.txt
  echo g >g.txt
  echo i >i.txt
  fossil add *
  fossil ci --no-warnings -m "Uppercase A" --tag "UPPERCASE"
  cd ..

  rem Rename "A" to "a" via an intermediate name since batch files
  rem apparently can't do that in one step.
  move A b
  move b a

  rem Attempt to simply tell fossil about the name change. This fails.
  fossil rename A a

  cd a
  echo b >b.txt
  echo d >d.txt
  echo f >f.txt
  echo h >h.txt
  echo i >i.txt

  fossil add *
  fossil ci --no-warnings -m "Lowercase A" --tag "lowercase"
  cd ..

  echo Note that both "A" and "a" are present
  fossil ls

  echo Now look at the Timeline and Files pages
  fossil ui
  pause
  </verbatim>
  </code>


login: drh
mimetype: text/x-fossil-wiki
icomment:
  I don't have any idea how to fix this on Windows without simultaneously breaking
  it on Unix.  My advice:  always use the same capitalization on Windows.


login: anonymous
mimetype: text/html
icomment:
  There is a typing error in the search.c archive in the line 163:

  <b>conts char **azDoc;</b>

  must be changed to:

  <b>const char **azDoc;</b>


  :) very simple but the project do not compile.


login: nobody
mimetype: text/plain
icomment:
  Request: Add a command line switch to deconstruct to tell fossil to ignore/skip pre-existing files already present. For the purposes of explanation below I'll call the switch "--keep" to match other existing options already available.

  The problem:

  When using "fossil deconstruct" currently fossil will create new files of the entire repository and will overwrite any old files. This works fine but creates two problems.

  1) For large projects it takes a long time to deconstruct.
  2) Backup program see all the files as new and needlessly backup everything again.

  What would be nicer is to have an option to tell fossil to skip files that are already present (and not alter the date modified). Then the above two problems can be eased because 1) only new entries in the repository are written to disk so the process is faster, and 2) backup programs only need to makes copies of the new files, not the entire set.

  Since all the file names are the SHA1 hash of the contents, and are immutable, we are guaranteed that the contents have not changed and thus don't need rewriting. Naturally if the user decides to edit such a file that is their responsibility, and their problem, if they alter things. And they can always do a full rebuild again later by deconstructing without the --keep switch.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  I found that the following small change to rebuild.c will successfully skip existing files during deconstruction.<br><br>But presently the command line option "--keep" isn't read so it is currently always active:<br><br>
  File src/rebuild.c<br>
  <pre><span class="diffln">   216    216  </span> */
  <span class="diffln">   217    217  </span> static void rebuild_step(int rid, int size, Blob *pBase){
  <span class="diffln">   218    218  </span>   static Stmt q1;
  <span class="diffln">   219    219  </span>   Bag children;

  <span class="diffln">   220    220  </span>   Blob copy;
  <span class="diffln">   221    221  </span>   Blob *pUse;
  <span class="diffln">   222    222  </span>   int nChild, i, cid;
  <span class="diffln">          223  </span>+<span class="diffadd">  FILE *out;</span>

  <span class="diffln">   223    224  </span>
  <span class="diffln">   224    225  </span>   while( rid&gt;0 ){
  <span class="diffln">   225    226  </span>
  <span class="diffln">   226    227  </span>     /* Fix up the "blob.size" field if needed. */
  <span class="diffln">   227    228  </span>     if( size!=blob_size(pBase) ){

  <span class="diffln">   228    229  </span>       db_multi_exec(
  <span class="diffln">   229    230  </span>          "UPDATE blob SET size=%d WHERE rid=%d", blob_size(pBase), rid
  <span class="diffhr">................................................................................</span>
  <span id="chunk2"></span><span class="diffln">   254    255  </span>       /* We are doing "fossil rebuild" */
  <span class="diffln">   255    256  </span>       manifest_crosslink(rid, pUse, MC_NONE);

  <span class="diffln">   256    257  </span>     }else{
  <span class="diffln">   257    258  </span>       /* We are doing "fossil deconstruct" */
  <span class="diffln">   258    259  </span>       char *zUuid = db_text(0, "SELECT uuid FROM blob WHERE rid=%d", rid);
  <span class="diffln">   259    260  </span>       char *zFile = mprintf(zFNameFormat /*works-like:"%s:%s"*/,
  <span class="diffln">   260    261  </span>                             zUuid, zUuid+prefixLength);

  <span class="diffln">   261         </span>-<span class="diffrm">      blob_write_to_file(pUse,zFile);</span>
  <span class="diffln">          262  </span>+<span class="diffadd">      out = fopen(zFile, "r");</span>
  <span class="diffln">          263  </span>+<span class="diffadd">      fclose(out);</span>

  <span class="diffln">          264  </span>+<span class="diffadd">      if( out==0 ){</span>
  <span class="diffln">          265  </span>+<span class="diffadd">        blob_write_to_file(pUse,zFile);</span>
  <span class="diffln">          266  </span>+<span class="diffadd">      }</span>

  <span class="diffln">   262    267  </span>       free(zFile);
  <span class="diffln">   263    268  </span>       free(zUuid);
  <span class="diffln">   264    269  </span>       blob_reset(pUse);
  <span class="diffln">   265    270  </span>     }
  <span class="diffln">   266    271  </span>     assert( blob_is_reset(pUse) );

  <span class="diffln">   267    272  </span>     rebuild_step_done(rid);
  <span class="diffln">   268    273  </span></pre>


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  I get this:
  astro-2:Downloads joe$ lst fossil*
  -rwxr-xr-x@ 1 joe  staff   1.6M Jun 12  2014 fossil
  -rw-r-----@ 1 joe  staff   710K Jan 15 21:23 fossil-macosx-x86-20140612172556.zip
  astro-2:Downloads joe$ /usr/bin/openssl sha1 fossil
  SHA1(fossil)= 32feb43c0b86c7ecb2195542d30dc07ad18c85b2

  website says it should be:
  bbf3d57ba15d0ed0e9b30819d89a50d294175113  fossil-macosx-x86-20140612172556.zip

  Thanks,
  Joe
  Thanks


login: drh
mimetype: text/x-fossil-wiki
icomment:
  The SHA1 sum refers to the original ZIP archive, not the fossil binary that gets unpacked (apparently automatically by your mac).


login: nobody
mimetype: text/x-fossil-plain
icomment:
  Minor/cosmetic issue. (I've never really noticed prior discovering it in the new sitemap.)
  Live example on [http://fossil-scm.org/index.html/attachlist] :)

  The /attachview and /attachdownload links in attachlist are absolute paths.
  Therefore they'll generate 404s on most public setups.

  Another simple %R prefix in attach.c seems to work.

      @ <br><a href="%R/attachview?%s(zUrlTail)">%h(zFilename)</a>
      @ [<a href="%R/attachdownload/%t(zFilename)?%s(zUrlTail)">download</a>]<br />


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  The Special Logins part of /setup_uedit says, "To disable universal access to the repository, make sure no user named 'nobody' exists or that the nobody user has no capabilities enabled." This sent me (a newbie) on a hunt for how to delete 'nobody', and eventually landing on the user docs: "Users can never be deleted..."

  I adjusted the permissions instead and everything is fine, but I think the text about making sure a user doesn't exist should be removed, given that said user is created automatically and can't be deleted without low-level sqlite commands.


login: bharder
mimetype: text/plain
icomment:
  kamloops$ ls -ld ../fossils/re2.fsl
  ls: ../fossils/re2.fsl: No such file or directory
  kamloops$ touch ../fossils/re2.fsl
  kamloops$ file ../fossils/re2.fsl
  ../fossils/re2.fsl: empty
  kamloops$ fossil new ../fossils/re2.fsl
  project-id: edf5ba355b8b496b71badd2a16fc0ba178018b59
  server-id:  80334132ba58383783495f24bfb31607ffe7ed41
  admin-user: bch (initial password is "553f2f")
  kamloops$ file ../fossils/re2.fsl
  ../fossils/re2.fsl: Fossil repository - SQLite3 database


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  [bb15d408a4d68f8ab853e] is *much* too low-level --- thinking move that code to ea. of clone and new...


login: bharder
mimetype: text/x-fossil-wiki
icomment:
  Would be nicer (necessary?) to use fossil_stat() rather than stat directly but in my tests it doesn't come to db.c and clone.c gently.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  I have set up syntax highlighting for the <code>[http://www.fossil-scm.org/index.html/help?cmd=/artifact|/artifact]</code> pages as described in the fossil wiki <nowiki>[</nowiki>[http://www.hwaci.com/cgi-bin/fossil/wiki?name=shjs|0]<nowiki>]</nowiki>.

  The new line number toggle option <nowiki>[</nowiki>[http://www.fossil-scm.org/index.html/info/a5b1bef9cfd605df57788c5459252fa02f4dc18b|1]<nowiki>]</nowiki> does not work seamlessly with syntax highlighting, as the new option causes URLs to change from <code>[http://www.fossil-scm.org/index.html/help?cmd=/artifact|/artifact]</code> to <code>[http://www.fossil-scm.org/index.html/help?cmd=/info|/info]</code> pages. Of course one might argue that the visible line numbers will mess up syntax highlighting anyway, but nonetheless I'd like to make a request to change the line number toggle option not to switch between <code>[http://www.fossil-scm.org/index.html/help?cmd=/artifact|/artifact]</code> and <code>[http://www.fossil-scm.org/index.html/help?cmd=/info|/info]</code> pages.

  [0] [http://www.hwaci.com/cgi-bin/fossil/wiki?name=shjs] <br>
  [1] [http://www.fossil-scm.org/index.html/info/a5b1bef9cfd605df57788c5459252fa02f4dc18b]


login: bharder
mimetype: text/x-fossil-wiki
icomment:
  I've bisected to [32f8da0ce785b63ad8a53fa851] as what appears to be first version breaking handling of "http_proxy" environment variable.

  There is no sign that fossil (tries to) use this at all, which is an error.


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  Files added (not yet committed) and deleted outside fossil are reported by 'fossil status' and 'fossil changes' as MISSING, while 'fossil ls -v' shows them as ADDED.

  I think 'fossil ls' gets it wrong.

  The difference originates in checkin.c -- 'status' and 'changes' call status_report() while 'ls' calls ls_cmd(). 
  Both functions do almost the same but in a different sequence:

  <em>status_report()</em>

  <pre>...
      if( isDeleted ){
      ...
      }else if( !file_wd_isfile_or_link(zFullName) ){
      ...
      }else if( isNew ){
      ...
      }else if( isChnged ){
  ...</pre>

  <em>ls_cmd()</em>

  <pre>...
      if( isNew ){
      ...
      }else if( isDeleted ){
      ...
      }else if( !file_wd_isfile_or_link(zFullName) ){
      ...
      }else if( chnged ){
  ...</pre>

  The "isNew"-Check really should be done <strong>after</strong> file_wd_isfile_or_link()


login: nobody
mimetype: text/x-fossil-wiki
icomment:
  json_page_status() has -- besides of a different wording/casefolding -- yet another sequence of checking:

    #  isDeleted
    #  isNew
    #  isRenamed
    #  file exists
    #  isChanged

  I think a MISSING file needs attention and really should be on position #2 in all three reporting functions.


login: dave.vines
mimetype: text/x-fossil-wiki
icomment:
  Having used to IBM's Rational Team Concert, I like having my personal project's milestone builds saved in the SCM system. To do that I'd like those build to be able to create tech notes and then save the build artifacts as attachments to that tech note. This can be subdivided into three aspects:
    
    #   Command line support for tech notes 
    #   Support for tech notes to have attachments
    #   Command line support for attachments


