[fossil-users] Compilation failure on osx 10.10 for fossil and sqlite shell

[Marcel Graf]

Hello

I tried to compile actual tip of trunk (c409f828) on OS X 10.10.5

It fails when on the linking stage:
Undefined symbols for architecture x86_64:
  "_utimensat", referenced from:
  _writeFile in shell.o
ld: symbol(s) not found for architecture x86_64

On compiling shell.c there was a warning already:
cc -I. -I./src -Ibld -Wall -DFOSSIL_DYNAMIC_BUILD=1
-Wdeprecated-declarations -DFOSSIL_HAVE_FUSEFS  -g -O2 -DHAVE_AUTOCONFIG_H
-D_HAVE_SQLITE_CONFIG_H  -Dmain=sqlite3_shell -DSQLITE_SHELL_IS_UTF8=1
-DSQLITE_OMIT_LOAD_EXTENSION=1 -DUSE_SYSTEM_SQLITE=0
-DSQLITE_SHELL_DBNAME_PROC=fossil_open   -DHAVE_LINENOISE -c ./src/shell.c
-o bld/shell.o
./src/shell.c:2338:9: warning: implicit declaration of function 'utimensat'
is invalid in C99 [-Wimplicit-function-declaration]
if( utimensat(AT_FDCWD, zFile, times, AT_SYMLINK_NOFOLLOW) ){

$ cc --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

Bisecting shows that the problem starts with check-in
http://www.fossil-scm.org/index.html/info/5b558bc76bb9fb5f


This also happens on sqlite itself, offending checkin on trunk:
http://sqlite.org/src/info/148b8aee78e40cab or sqlar-shell-support
respectively: http://sqlite.org/src/info/0cc699d14adfe8c7

Marcel
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Missing links on artifact & finfo pages

[Marcel Graf]

Hello,

I noticed a missing entry on the /artifact page for a content, that existed
twice under the same filename in the past:

http://fossil-scm.org/index.html/artifact/026da23219df1dd8 shows only
File .fossil-settings/ignore-glob — part of check-in [cc828822] at
2016-05-28 02:37:13 on branch trunk
although it was recently "reverted" to the exact same content be checkin
dc9ac1d7 (2016-11-08).

Both checkins cc828822 and dc9ac1d7 link to artefact 026da232 as file
.fossil-settings/ignore-glob
http://fossil-scm.org/index.html/info/dc9ac1d7cb57cd18
http://fossil-scm.org/index.html/info/cc828822c52a918d

But on the history for .fossil-settings/ignore-glob (
http://fossil-scm.org/index.html/finfo?name=.fossil-settings/ignore-glob),
the change from commit dc9ac1d7 (2016-11-08) is completely missing, too.


Regards,
Marcel
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Time to release Fossil version 1.34?

[Marcel Graf]

On Sun, Oct 18, 2015 at 10:38 PM, Joe Mistachkin 
wrote:

>
> There seems to be a timeline issue:
>
> https://system.data.sqlite.org/index.html/timeline?n=50=all=1
>
> The [2c6bdf20ea] merge check-in has two entries for each of the modified
> files.
>

The are also duplicate entries in the Changes-section of the Check-In page
https://system.data.sqlite.org/index.html/info/2c6bdf20ea066691, even after
the fix http://fossil-scm.org/index.html/info/22e0427b1048534e to fossil.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Marcel Graf]

On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp d...@sqlite.org wrote:

 On 3/20/15, Martin S. Weber ephae...@gmx.net wrote:
 ...

 in itself). So you end up with intermingled changes which one would
  like to split cleanly.
 
 The way I deal with this in SQLite is:
 ...

(2) On the occasions when I mess up and accidentally put unrelated
 changes into the same check-out, I have been known to stash the whole
 thing, then reapply one set of changes, test, commit, then reapply the
 other set of changes, test, and commit again.


This (2) might be easier with something like a
partial/selective/interactive stash as mentioned by the OP in the bottom
part of his email.
So (2a) would look like: selectively stash the second set of changes,
test (thus including the first set of changes), commit, stash pop/apply
second, test, commit

Imho, the missing piece would be stash having means to do partial
stashing (finer than on file-by-file base). This the would allow to do
these splittings of a mixed up check-outs a bit easier (including testing
before committing, no need for partial commit then), wouldn't it?

Regards
Marcel
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Marcel Graf]

On Fri, Mar 20, 2015 at 7:14 PM, Ron W ronw.m...@gmail.com wrote:

 On Fri, Mar 20, 2015 at 1:30 PM, Marcel Graf graf.m.ml+sbf...@gmail.com
 wrote:

 On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp d...@sqlite.org wrote:

 On 3/20/15, Martin S. Weber ephae...@gmx.net wrote:
 ...

  in itself). So you end up with intermingled changes which one would
  like to split cleanly.
 
 The way I deal with this in SQLite is:
 ...

 (2) On the occasions when I mess up and accidentally put unrelated
 changes into the same check-out, I have been known to stash the whole
 thing, then reapply one set of changes, test, commit, then reapply the
 other set of changes, test, and commit again.


 This (2) might be easier with something like a
 partial/selective/interactive stash as mentioned by the OP in the bottom
 part of his email.
 So (2a) would look like: selectively stash the second set of changes,
 test (thus including the first set of changes), commit, stash pop/apply
 second, test, commit


 I suppose this would make sense if there are fewer changes to undo in
 the edited code than to re do in the reverted code.



 You can achieve the same result with fossil snapshot (which skips the
 automatic revert), then fossil gdiff to selectively undo changes. Then
 edit/build/test/commit what remains. After that, fossil stash gdiff to
 selectively re-apply more changes. Repeat as needed


I assume you mean fossil stash snapshot. This will still take the whole
thing (or a selection of entire files) and whatever diff-merge-gui I use
for fossil gdiff will hopefully allow me to efficiently undo the changes
of the second modification. Yes, that will do!
And as you said, doing it forward or backward depends on the number of
changes in the first vs the second modification. Or even split is up in
one stash save for all files with only second modifications, one stash
snapshot for the mixed ones and undo  the parts from the second.
Test/commit, stash apply 2 and stash apply 1, test/commit.

I was more thinking about a command line only version of stash/snapshot
--interactive asking for each file if i want it entirely or split and in
case of the latter, letting me select each chunk without the use of an
external gui (I vaguely remember mercurial's record extension doing
something like this). But might not be worth it and/or induce to many
options to stash ...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] missing initial empty check-in repository from import

[Marcel Graf]

On Fri, Mar 13, 2015 at 4:28 PM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:

 2015-03-13 15:56 GMT+01:00 Marcel Graf graf.m.ml+sbf...@gmail.com:
  Well, to kind of answer my own question: I tried it, and yes, it happens
  too. Only using fossil version 1.27!

 Interesting. Thanks!

 Another way to trigger the 'problem' is using fossil reconstruct.
 This function reconstructs the repository from artifacts on disk,
 it is very unlikely that the initial empty checkin is encountered as
 first artifact and given rid=1.

 So, if the requirement is that rid=1 must contain the manifest
 of the initial empty check-in, the fossil reconstruct command
 builds an incompatible repository by design :-)


Talking about reconstruct: I tried it on my little test-case (git
fast-export dump). It results in only 2 blobs, the one-and-only check-in
manifest and one file. It happens to be that the sha1 of the file is
lexicographically after the one of the manifest, so doing a
deconstruct/reconstruct cycle should swap rid=1 and rid=2.

Let's see:
$ fossil-1.27 import git-one.fossil  git-one.dump
$ mkdir bag-of-blobs
$ fossil-1.27 deconstruct -R git-one.fossil bag-of-blobs/
$ fossil-1.27 reconstruct git-one-reconstructed.fossil bag-of-blobs/
$ echo SELECT rid,uuid,type,comment FROM blob, event WHERE rid = objid
ORDER BY rid; | fossil-1.27 sql -R git-one.fossil
2|5f10a7565281c4990391d84cfd2041d110e7ebda|ci|One-and-only checkin

$ echo SELECT rid,uuid,type,comment FROM blob, event WHERE rid = objid
ORDER BY rid; | fossil-1.27 sql -R git-one-reconstructed.fossil
1|5f10a7565281c4990391d84cfd2041d110e7ebda|ci|One-and-only checkin

Ok, swapped. Try the original
$ mkdir wd  cd wd
$ fossil-1.27 open ../git-one.fossil
$ ls
-- nothing
$ fossil-1.27 up
---
checkout: d6f7066dea999212dc6834e6eebab22b50965f8e
changes:  None. Already up-to-date
$ ls
-- still nothing, but d6f7066dea999212dc6834e6eebab22b50965f8e is the hash
of the file content
$ echo foo  bar.txt
$ fossil-1.27 add bar.txt
ADDED  bar.txt
$ fossil-1.27 ci -m some commit -nC some\scommit
D 2015-03-13T20:45:49.329
F bar.txt f1d2d2f924e986ac86fdf7b36c94bcdf32beec15
P d6f7066dea999212dc6834e6eebab22b50965f8e
R db8001820cefce732098cd62df1a5d76
U marcel
Z e41d91f888e731e0a23a829571f2fbe8
New_Version: 61bc5e03e1322f0c24d21f997abc0dd1627ca88b
-- BAD: the file is the parent of this commit. And creates the
disconnected check-in

Now try the reconstructed
$ mkdir wdr  cd wdr
$ fossil-1.27 open ../git-one-reconstructed.fossil
$ ls
-- nothing
$ fossil-1.27 upUPDATE a-file.txt
---
updated-to:   5f10a7565281c4990391d84cfd2041d110e7ebda 2015-03-13 14:12:38
UTC
tags: trunk
comment:  One-and-only checkin (user: mys...@me.com)
changes:  1 file modified.
 fossil undo is available to undo changes to the working checkout.
-- ok, needed an update, but file is there, parent hash is good
$ echo foo  bar.txt
$ fossil-1.27 add bar.txt
ADDED  bar.txt
$ fossil-1.27 ci -m some commit -nC some\scommit
D 2015-03-13T20:48:03.205
F a-file.txt d6f7066dea999212dc6834e6eebab22b50965f8e
F bar.txt f1d2d2f924e986ac86fdf7b36c94bcdf32beec15
P 5f10a7565281c4990391d84cfd2041d110e7ebda
R a77ec06fd6931041eab215d2061054ac
U marcel
Z 5b900413bded470209bd9c1243ce8687
New_Version: 02667c37bc607d0247726ff00475ace69555c52d
-- GOOD, parent is right

So having a valid check-in manifest on rid=1 and an update helped. The
same without the update:
$ mkdir wdr  cd wdr
$ fossil-1.27 open ../git-one-reconstructed.fossil
$ ls
-- nothing, lets add and commit anyway
$ echo foo  bar.txt
$ fossil-1.27 add bar.txt
ADDED  bar.txt
$ fossil-1.27 ci -m some commit -nC some\scommit
C some\scommit
D 2015-03-13T20:51:04.185
F bar.txt f1d2d2f924e986ac86fdf7b36c94bcdf32beec15
P 5f10a7565281c4990391d84cfd2041d110e7ebda
R db8001820cefce732098cd62df1a5d76
U marcel
Z d73b87e120a06d518c48605427deeef3
New_Version: 10450abbbd09b4b9e1dafb15c696a20a140fba6e
-- got the parent right, but is missing the first file (shows up as
deleted)
[image: Inline image 1]


which seems to match the entry in the release notes for 1.32: ...  by
having a valid manifest as RID 1.
Or, if you happen to get a non-manifest blob on rid=1 with reconstruct, it
might go bad. Although, doing the import with two git-commits, I got the
check-in manifest on rid=2 and rid=4 (1 and 3 being files) but everything
is ok there.

So it seems to be something like
   having only one check-in _and_ its manifest not on rid=1
is not handled right by fossil 1.27. And you can't get into that with an
initial empty checkin: As there you have either only exactly on blob (the
initial checkin) and reconstruct will still put in on rid=1 (no other
choice), or you have more check-ins (and files), but then it does no longer
matter ...

Which also explains why nobody noticed the problem by using import (other
than nobody using it at all

Re: [fossil-users] missing initial empty check-in repository from import

[Marcel Graf]

sorry, forgot to say what the image is about: its the timeline after the
swapped the check-in on rid=1 by reconstruct, but did not do update
before commit.

if anybody is interested, here is the git fast-export dump for a simple one
check-in:


git-one.dump
Description: Binary data
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] missing initial empty check-in repository from import

[Marcel Graf]

Hello everybody

If I understood correctly from the recent discussion about repositories
without initial check-ins (How to fix parallel timeline), the problem of
two disconnected DAGs (and seemingly lost files) is triggered if

A: fossil version 1.27 (or older) is used to open and work with a
B: repository without an initial empty check-in (as created by newer
versions of fossil)
C: already containing (exactly / at most / at least) one check-in with files

If I got that right, the problem might also appear with repositories
created by an import from git fast-export  (or from a subversion dump
with the new svn-import feature). Such repositories do not contain initial
empty check-ins, either.
And, regarding the other discussion about Google Code shutting down and
getting people to convert to fossil, that might lead to the same problem -
and a reputation damage ...

Regards,
Marcel
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] missing initial empty check-in repository from import

[Marcel Graf]

On Fri, Mar 13, 2015 at 3:35 PM, Marcel Graf graf.m.ml+sbf...@gmail.com
wrote:

 Hello everybody

 If I understood correctly from the recent discussion about repositories
 without initial check-ins (How to fix parallel timeline), the problem of
 two disconnected DAGs (and seemingly lost files) is triggered if

 A: fossil version 1.27 (or older) is used to open and work with a
 B: repository without an initial empty check-in (as created by newer
 versions of fossil)
 C: already containing (exactly / at most / at least) one check-in with
 files

 If I got that right, the problem might also appear with repositories
 created by an import from git fast-export  (or from a subversion dump
 with the new svn-import feature). Such repositories do not contain initial
 empty check-ins, either.
 And, regarding the other discussion about Google Code shutting down and
 getting people to convert to fossil, that might lead to the same problem -
 and a reputation damage ...

 Regards,
 Marcel


Well, to kind of answer my own question: I tried it, and yes, it happens
too. Only using fossil version 1.27!

1. Take any git repository and create the fast-export dump up to the first
check-in:
git fast-export --full-tree HASH-OF-THE-FIRST-GIT-CHECKIN  git.dump
2. Import it to a fossil repository
fossil import test.fossil  git.dump
3. Open that repository
fossil open test.fossil

As long as the the fossil in step 3 is 1.27, the working directory is
empty. fossil up does not do anything, fossil ui shows the check-in,
though. And fossil up HASH-FROM-THE-WEB-UI-FOR-THIS-CHECKIN would bring
it back.

It does not matter if in step 2 a newer fossil is used (it asks for rebuild
before doing almost anything - even for close, but only after the open
... ) or the same version 1.27 is used for the import.

It does not happen when there is more than 1 check-in imported (so point C
above should be exactly 1 check-in, probably).

So, in conclusion: the problem can be triggered using _only_ fossil version
1.27, using an import of a one-check-in git repository. Which is probably a
rare thing and not worth a repository conversion anyway. But indicates a
bug in version 1.27 rather then in the newer versions, imho. And another
reason not to use =1.27 anymore.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] repolist together with notfound

[Marcel Graf]

Hello,

I tried the new repolist feature of ui/server/cgi. Neat addition.

There is  a minor caveat, though: It does not work together with the
notfound setting. Trying to get the repository listing on / redirects
to the notfound URL, because this one is checked first. Wouldn't it be
better to change this order, like e.g. so?

Index: src/main.c
==
--- src/main.c
+++ src/main.c
@@ -1546,16 +1546,16 @@
 zRepo[j] = '.';
   }

   if( szFile1024 ){
 set_base_url(0);
-if( zNotFound ){
-  cgi_redirect(zNotFound);
-}else if( strcmp(zPathInfo,/)==0
+if( strcmp(zPathInfo,/)==0
allowRepoList
repo_list_page() ){
   /* Will return a list of repositories */
+}else if( zNotFound ){
+  cgi_redirect(zNotFound);
 }else{
 #ifdef FOSSIL_ENABLE_JSON
   if(g.json.isJsonMode){
 json_err(FSL_JSON_E_RESOURCE_NOT_FOUND,NULL,1);
 return;


It works for me, and allows even for setting it up to list the repositories
on a notfound by using a dot as URL notfound: .

Fossil version [3dbe76fca9] 2015-03-03 17:16:54

Regards,
Marcel
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil version 1.31 testing

[Marcel Graf]

On Mon, Feb 23, 2015 at 2:22 PM, Richard Hipp d...@sqlite.org wrote:

 On 2/22/15, Marcel Graf graf.m.ml+sbf...@gmail.com wrote:
  Hello,
 
  I noticed two problems in the web-ui of recent fossil versions:
 
  1. On the timeline, clicking on a tag used to show all checkins related
 to
  that tag/branch around that time - but now it only shows the checkins on
  and after that time, but no older checkins.
  Example from the fossil repository (svn-import link from
 c3bcab0f0505eb9a)
  is
 
 http://www.fossil-scm.org/index.html/timeline?r=svn-importndc=2015-02-22+12%3A00%3A49n=200
  only shows 5 checkins, using fossil 1.30 it shows about 90 checkins. The
  problem does not show if the selected branch is trunk or the n=200
  parameter is removed - then the checkins before and after are shown.
  This problem appears first with checkin
  45127a7236e4c34ecac670b6ee0645c1bcf77c20

 This problem appears to be resolved now.

Yes. Thank you.



 
  2. On the Files page, sometimes changing from Flat to Tree view and
  vice-versa, the references check-in/branch/tag is lost and All Files
  (Files from all XXX checkins) are shown. It does not happen if fossil ui
 is
  called inside a working directory or the repository is in the current
  directory when fossil ui repo.fossil is called (and probably the same for
  CGI). It does happen when calling fossil ui /abs/path/to/some/repo.fossil
  (or using CGI). Then, on the Files page (/dir?ci=tip) the Tab for
  Tree-View links to /dir?type=tree instead of /dir?ci=tiptype=tree
  This first appears with checkin 7478f9974c6320e4c942b7808ca393fa1540d871
 

 I was unable to recreate this problem.

Maybe I was not too clear in the description. But I was able to recreate it
with the following few lines, all using fossil version 1.31 [858dcc2c19]:

fossil init -A myself repo/tree-dir-test.fossil
mkdir tree-dir-test.fossil
cd tree-dir-test.fossil
fossil open ../repo/tree-dir-test.fossil
echo foo  a.txt
fossil add a.txt
fossil ci --user myself -m 'foo into a.txt'
mv a.txt b.txt
fossil mv a.txt b.txt
fossil ci --user myself -m 'rename a.txt to b.txt'
Viewing this by means of CGI like

#!/path/to/fossil
directory: /abs/path/to/repo-dir/
the Files Tab in the main menu links to /tree?ci=tip, once on that page
the [Tree-View]-button links to /dir?type=tree and shows all checkins and
files (a.txt and b.txt).
Changing the skin to San Francisco Modern, the Files Tab in the main
menu links to /dir?ci=tip, but again, once on that page the
[Tree-View]-button links to /dir?type=tree, missing something like ci=tip

If I use as CGI like

#!/path/to/fossil
directory: /abs/path/to/repo-dir/tree-dir-test.fossil
I have to check for fossil ui with that repository later on ... but the
first time I noticed the bad behavior was using fossil ui
/abs/path/to/repo.fossil

Marcel
--
D. Richard Hipp
d...@sqlite.org

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil version 1.31 testing

[Marcel Graf]

Hello,

I noticed two problems in the web-ui of recent fossil versions:

1. On the timeline, clicking on a tag used to show all checkins related to
that tag/branch around that time - but now it only shows the checkins on
and after that time, but no older checkins.
Example from the fossil repository (svn-import link from c3bcab0f0505eb9a)
is
http://www.fossil-scm.org/index.html/timeline?r=svn-importndc=2015-02-22+12%3A00%3A49n=200
only shows 5 checkins, using fossil 1.30 it shows about 90 checkins. The
problem does not show if the selected branch is trunk or the n=200
parameter is removed - then the checkins before and after are shown.
This problem appears first with checkin
45127a7236e4c34ecac670b6ee0645c1bcf77c20

2. On the Files page, sometimes changing from Flat to Tree view and
vice-versa, the references check-in/branch/tag is lost and All Files
(Files from all XXX checkins) are shown. It does not happen if fossil ui is
called inside a working directory or the repository is in the current
directory when fossil ui repo.fossil is called (and probably the same for
CGI). It does happen when calling fossil ui /abs/path/to/some/repo.fossil
(or using CGI). Then, on the Files page (/dir?ci=tip) the Tab for
Tree-View links to /dir?type=tree instead of /dir?ci=tiptype=tree
This first appears with checkin 7478f9974c6320e4c942b7808ca393fa1540d871
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users