Re: [fossil-users] Fossil ui File [check-ins using] bug

[Martin Gagnon]

The equivalent to finfo command is not the “checking using” link. You
should click on the file name just before the comment which will give you
this:

https://jsish.org/fossil/jsi/finfo?name=lib/Jsi_Debug.jsi=a7810a6e571b0823

Regards

—
Martin G.


Le mer. 26 sept. 2018 à 18:28, Peter MacDonald  a
écrit :

> In fossil-ui (2.6 and 2.7 at least), I navigate to Files, then pick a
> file, then click on [check ins using] and it tells me there are 8
> checkins, and then dumps the latest 8 checkins for the repo. eg:
>
>   https://jsish.org/fossil/jsi/timeline?n=all=a7810a6e571b0823
>
> Funny enough "fossil finfo"  dumps the correct info, eg:
>
> # fossil finfo lib/Jsi_Debug.jsi
> History of lib/Jsi_Debug.jsi
> 2018-09-21 [2491e4ac65] Fix LogDebug... not being evaled at correct
> level. Add templates. Rename Debug to Debugger. Cleanups. (user:
> pmacdona, artifact: [a7810a6e57], branch: trunk)
> 2018-09-17 [8db496b951] Release "2.4.88". Consolidate varios globals
> into jsiIntData struct. Expose retValue in Interp. Various websocket
> cleanups. Add noConfig option in more places. Fix
>blacklist bug. (user: pmacdona, artifact: [2bb50c20c7],
> branch: trunk)
> 2018-09-16 [a972405f39] More rework of Safe interp. Add custom type
> for parent interp func. Start rework of NameLookup (user: pmacdona,
> artifact: [d71625a453], branch: trunk)
> 2018-09-14 [3ddd9e08f5] Release "2.4.86". Cleanup Safe interp options.
> (user: pmacdona, artifact: [5010e7252d], branch: trunk)
> 2018-08-31 [2f1c8788bd] Release "2.4.76". Fix blob support. Fix Wget.
> Add string versions, and function module support for provide/require.
> Cleanup help. Fix cur dir delete causing crash.
>Zvfs: add inflate/deflate commands. Vfs: add support for
> mounting .sqlar files. Fix memory leak in Sqlite create error. (user:
> pmacdona, artifact: [e3d1ce986c], branch: trunk)
> 2018-08-28 [ee1c71af8c] Reorg moving jsi up a directory and moving
> Ledger to its own repo (jsiapp) (user: pmacdona, artifact:
> [7b04f6ff80], branch: trunk)
>
> Peter
> ___
> 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 gdiff" doesn't launch WinMerge; fossil.exe with autocompletion?

[Martin Gagnon]

Le sam. 4 août 2018 à 11:17, Stephan Beal  a écrit :

> If it was that common we would have realized the problem sooner ;).
>
> The problem with generating output for "no changes" is that we potentially
> break any automation which relies on an empty diff to mean "no changes".
>

That is what stderr is for.

—
Martin G.
___
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 gdiff" doesn't launch WinMerge; fossil.exe with autocompletion?

[Martin Gagnon]

On Sat, Aug 04, 2018 at 04:25:28PM +0200, Gilles wrote:
> On 04/08/2018 15:51, Gilles wrote:
> >d:\Temp>fossil gdiff test.html
> >
> >Nothing.
> 
> I don't know if it means anything, but incidently, "fossil diff" doesn't
> return anything either:
> 
> d:\Temp>fossil diff test.html
> 
> d:\Temp>fossil finfo test.html
> History of test.html
> 2018-08-04 [6517de2577] Blah (user: fred, artifact: [e123cf7827], branch:
> trunk)
> 2018-08-04 [e711051a5a] Original files (user: fred, artifact: [7d257c6ae4],
> branch: trunk)

If you don't have any local changes, it's normal that it shows nothing.
If "fossil changes" return nothing, it will be the same for "diff" or
"gdiff".

Fossil will not try to run the gdiff-command if there's no change.

Try again after modifying the file.

-- 
Martin G.
___
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 gdiff" doesn't launch WinMerge; fossil.exe with autocompletion?

[Martin Gagnon]

On Sat, Aug 04, 2018 at 01:16:29PM +0200, Gilles wrote:
> Hello,
> 
> I have a couple of questions:
> 
> 1. Although fossil.exe is configured with…
> 
> fossil settings > gdiff-command    (global) "C:\Program
> Files\WinMerge\WinMergeU.exe"
> 
> … nothing happens when I run "fossil gdiff myfile.txt".

You can try to add "C:\Program Files\WinMerge" to your PATH environment
variable.

Then start a cmd window and try if it works by just typing winmergeu.

If it's works, this should works

   fossil set gdiff-command winmergeu
   fossil gdiff myfile.txt

-- 
Martin G.
___
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] Can't believe --branchcolor would be platform-specific

[Martin Gagnon]

On Sat, Jul 07, 2018 at 02:39:52PM +0200, Francois Vogel wrote:
> Many thanks for your answers. I'm always impressed how members of this
> list are helpful and reply quickly.

Bienvenue

-- 
Martin G.
___
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] Can't believe --branchcolor would be platform-specific

[Martin Gagnon]

My guess is that on a bash shell, # is the symbol for comments. Try to put
it in double quotes;
   e.g.:—branchcolor "#f0a0a0"

Regards,
(Sorry for top posting and brevity, I’m on mobile)

—
Martin G.

Le sam. 7 juill. 2018 à 07:30, Francois Vogel  a écrit :

> Hi all,
>
> I'm experiencing the following error on macOS and Linux:
>
> $ f commit -m "Fix bug" --branch mybranch --branchcolor #f0a0a0
> unrecognized command-line option, or missing argument: --branchcolor
> $ fossil version
> This is fossil version 2.6 [9718f3b078] 2018-05-04 12:56:42 UTC
> $ f commit -m "Fix bug" --branch mybranch
> New_Version:   
>
> The same command with --branchcolor, succeeds on Windows (but here I'm
> using fossil-2.1).
>
> Any thoughts on this perhaps? Couldn't find the light reading the
> documentation, I can't see why the --branchcolor option would be
> platform-specific. Or is it that this option got removed since 2.1
> ?'fossil help commit' still documents it however.
>
> Thanks!
> Francois
>
> ___
> 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] build without zlib doesn't works anymore (using --with-miniz)

[Martin Gagnon]

On Fri, Jun 29, 2018 at 03:41:58PM -0400, Martin Gagnon wrote:
> Hi,
> 
> I use to be able to build fossil for some embedded arm linux without the
> need to have zlib available on my cross-compiler toolchain by using
> ./configure --with-miniz.
> 
> This doesn't works anymore because it seems that now, shell.c include
> zlib.h and links against zlib.
> 

Looks like this checkin is the culprit:
   http://www.fossil-scm.org/index.html/info/5b558bc76bb9fb5f
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] build without zlib doesn't works anymore (using --with-miniz)

[Martin Gagnon]

Hi,

I use to be able to build fossil for some embedded arm linux without the
need to have zlib available on my cross-compiler toolchain by using
./configure --with-miniz.

This doesn't works anymore because it seems that now, shell.c include
zlib.h and links against zlib.

Thanks,

-- 
Martin G.
___
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] smtp.c build failures

[Martin Gagnon]

On Thu, Jun 28, 2018 at 03:26:42PM -0400, Richard Hipp wrote:
> On 6/28/18, Martin Gagnon  wrote:
> >
> > To use the ns_* function, you needs to install libbind from packages:
> > pkg_add -r libbind.
> >
> 
> I'm thinking I will probably end up having to write my own DNS query
> response parser
> 

Ok, that's would be ideal I guess (for portability).

But still, FYI: I just manage to compile and link it successfully with
libbind on OpenBSD.

I don't know how to configure autosetup to detect it automatically, but
I just had to edit the Makefile manually after the "./configure" as
the following:

- addition to CFLAGS variable:
-I/usr/local/include/bind

- addition to LIB variable:  
-L/usr/local/lib/libbind -lbind

-- 
Martin G.
___
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] smtp.c build failures

[Martin Gagnon]

On Thu, Jun 28, 2018 at 11:58:55AM -0700, jungle Boogie wrote:
> On 28 June 2018 at 11:42, Richard Hipp  wrote:
> > On 6/28/18, jungle Boogie  wrote:
> >> Hi All,
> >>
> >> I know it's still very early on to make use of the new smtp logic, but
> >> I thought I'd report these issues. Is anyone else experiencing issues
> >> with compiling?
> >
> > Did you rerun ./configure?
> >
> > fossil clean -x
> > ./configure
> > make
> >
> 
> The build took place in a separate directory, outside my trunk version
> of Fossil.
> 
> > If you still get errors then, please let me know.  But first, figure
> > out what library OpenBSD wants to link against in order to pick up the
> > DNS parsing routines.
> 
> Does this help?
> http://man.openbsd.org/man3/getrrsetbyname.3

To use the ns_* function, you needs to install libbind from packages:
pkg_add -r libbind.

Then, I guess we will needs to modify our autosetup script, so it detect
if libbind is installed. If it's the case, it needs to add:
- /usr/local/include/bind to include path
- /usr/local/lib/bind to lib path
- add -lbind to link agains libbind.

I got it to compile, I still have an issue with the linking
part.

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

Re: [fossil-users] Change textarea for textnotes to placeholder text

[Martin Gagnon]

On Sun, Jun 17, 2018 at 06:26:06AM -0700, Zack Scholl wrote:
> 
> I made this change in a forked copy of fossil (simply change are line 544
> of event.src to add the placeholder [2] and delete "Insert new content
> here..." from line 474) ...  
> 
> [2]:
> https://www.fossil-scm.org/index.html/artifact?udc=1=on=5d4a12252f765b5a

Hi Zack, 

Here's a Useful trick when passing link to source on fossil repo, you
can specify lines to highlight. (in your case, for 2 separate lines, you
can edit the url and change "ln=on" to "ln=474+544" like this [1]

See all the options for the /artifact page here: [2]

[1]: 
https://www.fossil-scm.org/index.html/artifact?udc=1=474+544=5d4a12252f765b5a

[2]: https://www.fossil-scm.org/index.html/help?cmd=/artifact

Regards, 

-- 
Martin G.
___
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] Mailing list shutting down...

[Martin Gagnon]

Just brainstorming here: May be a kind of  "mailing list" and/or "forum"
feature could be added to Fossil itself ?

Fossil would become even more an alternative to github+git.

Of course this would be a long-term work.

This is just a random thought, it might be a bad idea, I’m not sure what to
think about it.

  (Sorry for top posting and brevity, on mobile)

—
Martin G.

Le mer. 13 juin 2018 à 07:28, Richard Hipp  a écrit :

> Unfortunately, I'm going to need to shut down this mailing list due to
> robot harassment.  I am working to come up with a fix or an
> alternative now.  Your suggestions are welcomed.
>
> This mailing list has operated for many years using GNU MailMan.
> Unfortunately, that software is not able to cope with modern robot
> spammers, even with the latest updates.  And the source code for
> MailMan is sufficiently opaque that I am unable to work on it.
>
> The most recent problem is that robots are visiting the subscription
> page and entering innocent user's email addresses and names.  This
> causes a confirmation email to be sent to that user.  If it were just
> single confirmation email that the user could ignore, that would be
> fine.  But apparently MailMan sends one email for each subscription
> request.  The robots have figured this out and are putting in hundreds
> of subscription requests for the same individual, apparently to harass
> them.
>
> I have already suspended new subscriptions.  Existing subscribers will
> be able to continue using this list until I come up with a replacement
> (or a fix to the current problem) but no new subscribers will be
> accepted.
>
> --
> 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] Amendments don't always survive rebuilds

[Martin Gagnon]

On Mon, Jun 11, 2018 at 02:24:48PM -0400, Richard Hipp wrote:
> On 6/9/18, Andy Goth  wrote:
> > Some amendments don't consistently survive rebuilds and syncs.  I've
> > noticed this with date changes and reparenting.  Possibly it affects
> > other types of amendments as well, but those are the two I've spotted.
> >
> > This has been plaguing me for years, but finally I have a repeatable
> > test case.
> >
> > Repository before rebuild:
> > https://drive.google.com/open?id=1-Ahs91NVigBX7uMk88wIBjClQj1yxGnm

> 
> Download does not work.  
If it can help, The download works for me, but the repo are compressed
with xz (without the the ".xz" extension). So, before to be able to use
it, you have to rename from the files from .fossil to
.fossil.xz.  Then xz -d .fossil.xz.

> There were errors coming from your script such that the "f amend"
> commands were failing.
> 
For the script, there's a few line warp in the email that cause the
error.  Per example, the newline between the "05" and the "24" on
the following line:

id=1; for day in 15 13 16 12 17 11 18 10 19 09 20 08 21 07 22 06 23 05 
24 04 25 03 26 02 27 01; do f commit -f -m "$id" -tag "$id"

Here's my re-indented version of the script that should works
(if the email client doesn't break it)

--%<--
#!/bin/bash

fossil new test.fossil -admin-user username -date-override 2018-05-31

mkdir test
cd test

fossil open ../test.fossil
fossil user default username

id=1
for day in 15 13 16 12 17 11 18 10 19 09 20 08 21 07 22 06 23 05 \
   24 04 25 03 26 02 27 01; 
do 
fossil commit -f -m "$id" -tag "$id" -date-override "2018-06-$day"
((++id))
done

for id in $(seq 1 26); 
do 
fossil amend -date "$(printf 2018-06-%02d "$id")" "$id"
done
--%<--

Regards,

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

Re: [fossil-users] How to rename a directory

[Martin Gagnon]

Fossil mv *can* take a directory as argument and it will move every
files inside recursively. But the semantic is not exactly like the unix
"mv" command and it doesn't works with the "--hard" option (probably a
bug).

Example, if you have a directory "dir" and want to move it inside a new
directory "subdir", this will works.

$ mkdir subdir
$ mv dir subdir/
$ fossil mv dir subdir/dir


   ** Note: You have to "subdir/dir" for the destination argument.
Otherwise it will not do what you what, it will move all
files that is inside dir directly in subdir. (so it doesn't
use the same semantic as the unix "mv" command).

If you want to skip the unix "mv" command part and use "--hard", it will
move the directory on the filesystem, but the fossil part of the move
will fail.

Regards,

-- 
Martin G.

On Sun, May 06, 2018 at 03:33:28PM +, Dewey Hylton wrote:
> Like Andy, I'm sure I've read that file names are what gets
> tracked - and wasn't even aware anyone had worked on a
> directory rename function ... At times when a project
> grows, I do tend to create new subproject directories and
> move existing files to those directories - and a directory
> rename function in fossil which was basically a wrapper
> around file renames would certainly make those operations
> easier.
> 
> I've always just used this method:
> 
> for F in file1 file2 file3 ; do
>   move="mv dir1/${F} dir2/${F}"
>   $move && fossil $move
> done
> 
> Looping around output from 'find' can be used for larger
> numbers of files or those in several subdirectories.
> 
> When I'm working on one of my own boxes that get my own
> environment setup, I use a shell function called "fmv"
> which does this for me.
> 
> The end result appears to be what OP is looking for,
> though of course the hard work is performed in the shell.
> 
> On Sun, May 6, 2018 at 12:40 AM Andy Bradford 
> wrote:
> 
> > Thus said Dingyuan Wang on Sun, 06 May 2018 00:37:23 +0800:
> >
> > > The fossil mv command seems can't rename a directory.
> >
> > I  thought Fossil  only  tracked  files (which  is  their complete  path
> > relative  to  the  repository  checkout) and  does  not  actually  track
> > directories by themselves.
> >
> > For example, this works fine:
> >
> > $ mkdir first
> > $ touch first/file
> > $ ./fossil add first/file
> > ADDED  first/file
> > $ ./fossil ci -m go
> > New_Version:
> > 600ce3e31ee64a3ff98a9af360b50d5ca24323acac04ee25d26eee82de78fa58
> > $ ./fossil mv --hard first/file second/file
> > RENAME first/file second/file
> > MOVED_FILE /tmp/first/file
> > $ ./fossil ci -m again
> > New_Version:
> > 5107ce9a7299518f44799149094ace083f7cec994578d429ca94897e3b09e395
> > $ ls first
> > $ ls second
> > file
> >
> > Andy
> > --
> > TAI64 timestamp: 40005aee8760
> >
> >
> > ___
> > fossil-users mailing list
> > fossil-users@lists.fossil-scm.org
> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> >

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

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

Re: [fossil-users] configuration fossil generic to all fossil checkouts

[Martin Gagnon]

On Mon, Mar 26, 2018 at 06:02:47PM +, Agrawal, Ritika wrote:
> Is there a settings file similar to .gitconfig in git that can be
> stored in user's home directory and overrides settings for all the
> fossil clones performed by the user. 
> 

The global settings are saved in ~/.fossil, which is a sqlite
database.

The "fossil set" command can be used with the --global options to set or
modify global settings. If a setting is not set in the repo, the global
setting will be use.

If you type "fossil set" from within a checkout, you will see the list
of possible settings. Options set on the repo will indicate "(local)",
the ones set globally will indicate "(global)".

Type "fossil help set" for more details.

Regards,

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

Re: [fossil-users] How to fix an SQLite warning on the /tagtimeline page?

[Martin Gagnon]

On Fri, Mar 23, 2018 at 01:02:47PM +0200, Svyatoslav Mishyn wrote:
> Hi,
> 
> how to fix an SQLite warning on the /tagtimeline page?
> 
> On all my publicly available repositories I have such error on that page:
> SQLITE_WARNING: automatic index on tagxref(tagtype)
> 

I have the exact same problem in all my repo. 

I didn't notice it before, probably because I didn't look at this page
for a while.

  Fossil Version on Server (OpenBSD i386):
Fossil 2.5 [188a0e2904] 2018-02-07 18:48:14


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

Re: [fossil-users] Strange error. How to workaround.

[Martin Gagnon]

On Thu, Feb 01, 2018 at 08:13:54PM +0200, John Found wrote:
> On Thu, 1 Feb 2018 12:03:13 -0500
> Richard Hipp <d...@sqlite.org> wrote:
> 
> > On 2/1/18, Martin Gagnon <eme...@gmail.com> wrote:
> > >
> > > I could reproduce it. I didn't have much time to investigate it for now
> > > but I have attached a simple shell script that reproduce the problem
> > > starting from scratch.
> > >
> > > Just put the shell script on an empty directory and execute it.
> > 
> > Thanks for the repro script.
> > 
> > If found that it does work if your break up the operation into two
> > distinct steps.
> > 
> > (1) "fossil rm" the old files that will be changed into symlinks.
> > Then "fossil commit".
> > 
> > (2) "fossil add" the new symlinks.  Then "fossil commit" again.
> > 
> > The revised script that works is attached.
> > 
> > It would be great if it worked in a single step.  But this is an
> > obscure case for which there is (now) a work-around, so it is of lower
> > priority for the moment.
> > 
> > -- 
> > D. Richard Hipp
> > d...@sqlite.org
> 
> Yes, thanks, I was able to commit this way. Hope, the bug will not be hard to 
> fix.
> 
> Anyway, another obscure case is when the symlink points to a directory. In 
> this
> case fossil adds the files of the directory twice - from the original 
> directory and from
> the symlink. I was not able to make fossil to add to the repository only the 
> symlink itself.

If you do: "fossil set allow-symlink 1" on the opened checkout, it
should works and add only the symlink.

But you will have same problem as with the symlink to file if you try to
replace the directory by a symlink in one single step. You need to do it
in 2 commits.

So the same work around apply:
  
   0. be sure allow-symlink is ON
$ fossil set allow-symlink 1

   1. remove directory and all it content:
$ fossil rm a_dir
$ rm -rf a_dir

   2. commit the change (remove real dir and it's content)
$ fossil commit -m "remove dir a_dir and it's content"

   3. create the symlink, add the symlink and commit.
$ ln -s another_dir a_dir
$ fossil add a_dir

   4. commit the change (add symlink)
$ fossil commit -m "add symlink a_dir"


Regards,

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

Re: [fossil-users] Strange error. How to workaround.

[Martin Gagnon]

On Thu, Feb 01, 2018 at 12:03:13PM -0500, Richard Hipp wrote:
> On 2/1/18, Martin Gagnon <eme...@gmail.com> wrote:
> >
> > I could reproduce it. I didn't have much time to investigate it for now
> > but I have attached a simple shell script that reproduce the problem
> > starting from scratch.
> >
> > Just put the shell script on an empty directory and execute it.
> 
> Thanks for the repro script.
> 
> If found that it does work if your break up the operation into two
> distinct steps.
> 
> (1) "fossil rm" the old files that will be changed into symlinks.
> Then "fossil commit".
> 
> (2) "fossil add" the new symlinks.  Then "fossil commit" again.
> 
> The revised script that works is attached.
> 
> It would be great if it worked in a single step.  But this is an
> obscure case for which there is (now) a work-around, so it is of lower
> priority for the moment.
>

Agree, 

For the record:  I've Attached the original script and the revised one,
both slightly modified so the symlink actually works.. 

The same workaround is still valid, but the test is closer to the
reality.

Regards,

-- 
Martin G.


symlink_bug.sh
Description: Bourne shell script


symlink_bug_workaround.sh
Description: Bourne shell script
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Strange error. How to workaround.

[Martin Gagnon]

On Thu, Feb 01, 2018 at 07:00:31AM +0200, John Found wrote:
> On Wed, 31 Jan 2018 20:19:06 -0500
> Richard Hipp  wrote:
> 
> > On 1/31/18, John Found  wrote:
> > >
> > > "fossil chan" for these two files display:
> > >
> > > SYMLINKactivity0.tpl
> > > SYMLINKactivity1.tpl
> > >
> > > These two files are actually symlinks to "../Wasp/activity0.tpl" and
> > > "../Wasp/activity1.tpl".
> > >
> > > This way, I can't commit my work at all. Is it a bug? Or expected 
> > > behavior?
> > > How to commit now?
> > 
> > Try running "fossil changes --hash" and afterwards trying to commit
> > again.  It might help. (Or it might not, but it is worth a try.)
> > 
> > -- 
> > 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
> 
> No, unfortunately, no difference. :( I am attaching the full output of
> fossil in hope will be helpful. Also, the command created a bunch of
> "file-RANDOM_STRING" in the checkout.
> 

I could reproduce it. I didn't have much time to investigate it for now
but I have attached a simple shell script that reproduce the problem
starting from scratch.

Just put the shell script on an empty directory and execute it.

Regards

-- 
Martin G.


symlink_bug.sh
Description: Bourne shell script
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Wrong link in Download page

[Martin Gagnon]

Hi, 

I've noticed a typo in one of the link in the download page.

The date link (2017-11-03), following "Version 2.4", point to
version-2.3 insted of version-2.4.

Regards,

-- 
Martin G.
___
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] Errors in current trunk (24c2b99d) related to TIMESPEC

[Martin Gagnon]

On Mon, Jan 08, 2018 at 09:28:49PM -0500, Richard Hipp wrote:
> On 1/8/18, Martin Gagnon <eme...@gmail.com> wrote:
> >
> > Same warning for me. I'm using gcc 7.2.0 from msys2 under windows 10 [1].
> >
> 
> There is yet another update on trunk.  Please try again and report back.

Now I get:

--
gcc -Wall -Wdeclaration-after-statement -Os -Lsrc/../compat/zlib 
-Isrc/../compat/zlib -DBROKEN_MINGW_CMDLINE=1  -I. -Isrc -Dmain=sqlite3_shell 
-DSQLITE_SHELL_IS_UTF8=1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DUSE_SYSTEM_SQLITE= 
-DSQLITE_SHELL_DBNAME_PROC=fossil_open -Daccess=file_access 
-Dsystem=fossil_system -Dgetenv=fossil_getenv -Dfopen=fossil_fopen   -c 
src/shell.c -o wbld/shell.o
src/shell.c: In function 'fsdirNext':
src/shell.c:2505:30: warning: passing argument 2 of '_stat64i32' from 
incompatible pointer type [-Wincompatible-pointer-types]
   if( lstat(pCur->zPath, >sStat) ){
  ^
src/shell.c:2079:38: note: in definition of macro 'lstat'
 #  define lstat(path,buf) _stat(path,buf)
  ^~~
In file included from src/shell.c:108:0:
C:/msys64/mingw64/x86_64-w64-mingw32/include/sys/stat.h:101:28: note: expected 
'struct _stat64i32 *' but argument is of type 'struct _stat64 *'
   __CRT_INLINE int __cdecl _stat64i32(const char *_Name,struct _stat64i32 
*_Stat)
^~
src/shell.c: In function 'fsdirFilter':
src/shell.c:2639:26: warning: passing argument 2 of '_stat64i32' from 
incompatible pointer type [-Wincompatible-pointer-types]
   if( lstat(pCur->zPath, >sStat) ){
  ^
src/shell.c:2079:38: note: in definition of macro 'lstat'
 #  define lstat(path,buf) _stat(path,buf)
  ^~~
In file included from src/shell.c:108:0:
C:/msys64/mingw64/x86_64-w64-mingw32/include/sys/stat.h:101:28: note: expected 
'struct _stat64i32 *' but argument is of type 'struct _stat64 *'
   __CRT_INLINE int __cdecl _stat64i32(const char *_Name,struct _stat64i32 
*_Stat)
^~
--

It may be related with the fact that I have to specify "X64=1", I may
have a strange msys2 setup. 


-- 
Martin G.
___
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] Errors in current trunk (24c2b99d) related to TIMESPEC

[Martin Gagnon]

On Mon, Jan 08, 2018 at 10:53:02PM -0300, Marcelo Huerta wrote:
> Richard Hipp decía, en el mensaje "Re: [fossil-users] Errors in current trunk
> (24c2b99d) related to TIMESPEC" del 8/1/2018 21:57:35:
> 
> > There are changes on trunk that might fix these build problem.  But,
> > as nobody here has been able to reproduce them, we cannot be sure.
> > Therefore, please try the latest trunk check-in and see if it is
> > working better for you and report back.  Thanks.
> 
> There is still a warning:
> 
> src/shell.c:2075:0: warning: "stat" redefined
> 
> However, now the compilation finishes:
> 
> > fossil version
> This is fossil version 2.5 [218aa6cbdd] 2018-01-09 00:55:42 UTC
> 

Same warning for me. I'm using gcc 7.2.0 from msys2 under windows 10 [1].

On my setup, I have to add "X64=1" to win/Makefile.mingw in order to
make it compile.
  

[1]: --
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-7.2.0/configure --prefix=/mingw64 
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include 
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 
--with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada 
--enable-shared --enable-static --enable-libatomic --enable-threads=posix 
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes 
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check 
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release 
--disable-rpath --disable-win32-registry --disable-nls --disable-werror 
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 
--with-pkgversion='Rev1, Built by MSYS2 project' 
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 7.2.0 (Rev1, Built by MSYS2 project)

$ uname -a
MSYS_NT-10.0 mgx1 2.9.0(0.318/5/3) 2017-09-13 23:16 x86_64 Msys
--

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

Re: [fossil-users] How to find deleted files in web interface

[Martin Gagnon]

Le sam. 6 janv. 2018 à 22:01, Dingyuan Wang  a écrit :

> Hi,
>
> In the command line, fossil timeline -p somefile can show the commit
> when the file is deleted, while web interface /finfo?name=somefile
> can't. It also don't show merges.
>
> What's the web interface equivalence of `timeline` for a file, or how
> can I find when the file is deleted?


The equivalent of  "timeline -p" on cli is:

For one file:
  /timeline?chng=/path/to/file

Or for checkin affecting any files from a directory:
  /timeline?chng=/somepath/*

—
Martin G.
___
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] Older fossil archives are not rebuild-able

[Martin Gagnon]

What version of fossil are you using right now ? 
(Output of "fossil version")


-- 
Martin G.

> Le 12 déc. 2017 à 12:57, J Knight  a écrit :
> 
> Hello. I have some older fossil archives that report:
>  
> SQLITE_ERROR: table config has no column named mtime
> fossil: table config has no column named mtime: {REPLACE INTO 
> config(name,value,mtime) VALUES('hash-policy',1,now())}
>  
> issuing a ‘rebuild’ and a ‘rebuild –force’ gives the same error. Is there 
> some way to bring these up to date or somehow migrate?
>  
> thanks
>  
>  
> ___
> 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] Metadata in Timeline Verbose View

[Martin Gagnon]

On Tue, Dec 12, 2017 at 02:00:01PM +0100, Florian Balmer wrote:
  
  

> While talking about the views, please allow me some Compact View bashing:
> 
> Compact View looks plain and elegant, I agree. But whenever I view the
> timeline, I'd either like to SEE THE HASHES (to check-out or merge a
> specific version), or CLICK THE HASHES (to view the check-in details
> and diffs). I never just browse my comments ;-)

If it can helps, since recent timeline web ui refactoring, you can now
click on the "time" link on the left the check-in to access the check-in
details (and diffs). So no needs to expand the small "..." just to click
on the hash link.

Since I discover this, I don't miss the "Verbose view" anymore and
always stay in "Modern View", I don't have the hash on the way in front,
but it is always on a predictable place if I need it.

But I understand it might not be the case for everybody, that's why it's
nice to have 4 different views.


  
> 
> > It's mixing completely different things and levels ...
> 
> I don't think so. Adding the CSS to display the parenthesis means
> maintaining your own custom skin?

You've been heard, since it's now the default ;-)

  


-- 
Martin G.
___
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] Metadata in Timeline Verbose View

[Martin Gagnon]

On Mon, Dec 11, 2017 at 06:51:17PM +0100, Florian Balmer wrote:
> Thanks for the recent timeline changes.
> 
> Most of my check-in comments do not end with a dot. In the timeline
> web view, it used to look like this:
> 
> [xx] This is the check-in comment (user: username, tags: trunk)
> 
> For the current development version in Verbose View, it looks like this:
> 
> [xx] This is the check-in comment user: username, tags: trunk
> 
> I found it easier to distinguish metadata from comments in the first
> version. Even if check-in comments are terminated with a dot, there's
> not the same clear visual demarcation with lowercase letters.
> 
> So please allow me to vote for metadata being put in parenthesis,
> again, for the Timeline Verbose View.

+1

Just to clarify, you're request apply for the "Compact View" and the
"Verbose View" right ?

"Modern View" and "Columnar View" don't have the same problem and looks
better without the parenthesis I think.

-- 
Martin G.
___
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] Help improve the Fossil CSS

[Martin Gagnon]

On Mon, Dec 11, 2017 at 10:02:52AM -0500, Richard Hipp wrote:
> On 12/11/17, Martin Gagnon <eme...@gmail.com> wrote:
> >
> >> The llnk for draft1 is https://www.fossil-scm.org/fossil/draft1/timeline
> >
> > This one is by far my favorite one. Separate Checkins are well defined
> > and the overall still smooth on the eyes without the horizontal lines.
> >
> > If Same changes can be applied to the "Columnar View", this skin would
> > be complete.
> >
> > I would vote for this one as the default skin.
> 
> The "selected check-in" display is a little wonky on that skin:
> https://www.fossil-scm.org/fossil/draft1/timeline?c=9f9ed
>

I guess you mean this: 
https://www.fossil-scm.org/fossil/draft1/timeline?ss=m=200=ci=0=9f9ed

  (For some reason, when I click on your link, I got the "Verbose View",
  which have no difference with the original skin.)

I agree, I didn't notice that. May be it could be better with full
yellow background like on the original "Modern View" skin, but with
rounded corner instead of square ?. 

-- 
Martin G.
___
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] Help improve the Fossil CSS

[Martin Gagnon]

> On 4 Dec 2017, 11:07 AM +0800, Steve Landers , 
> wrote:
> > Draft1 omits the borders around checkins in the Modern View, and
> > adds a subtle background color for any commits that are not already
> > colored.
> >
> > The rationale is that horizontal lines are “visual noise” that draw
> > the eye from the content of the check-in.   Removing the horizontal
> > lines also gives a slightly better use of vertical space.

On Mon, Dec 04, 2017 at 11:08:59AM +0800, Steve Landers wrote:

> The llnk for draft1 is https://www.fossil-scm.org/fossil/draft1/timeline

This one is by far my favorite one. Separate Checkins are well defined
and the overall still smooth on the eyes without the horizontal lines.

If Same changes can be applied to the "Columnar View", this skin would
be complete.

I would vote for this one as the default skin.


Regards,

-- 
Martin G.
___
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] diff coloring missing?

[Martin Gagnon]

Do ctrl-f5 to force a full refresh. CSS is cached.

Le jeu. 30 nov. 2017 à 09:31, jungle Boogie  a
écrit :

> On Nov 30, 2017 3:35 AM, "Richard Hipp"  wrote:
> >
> > On 11/30/17, jungle Boogie  wrote:
> > >>
> > >> In previous builds, this commit would certainly have a number of green
> > >> lines, but that's not the case anymore.
> > >
> > > bisect complete
> > >   4 BAD 2017-11-29 19:18:45 5c9c51be5f033de2 CURRENT
> > >   3 GOOD2017-11-29 16:20:29 f9fc914eaef2c9e7
> > >   2 GOOD2017-11-29 16:06:09 5beb3614960f2c3e
> > >   1 GOOD2017-11-29 14:05:43 c94f6085489effe6
> >
> > Thanks for the bisect.  Should be working again, now.  Let me know if
> > you spot any other CSS issues.
> >
>
> Hmmm, I still don't see it working on the website, and it looks like
> you're running the latest code. I'll check more closely if my bisect was
> wrong.
>
> > --
> > 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] Weird behavior on Chisel, perhaps a version mismatch?

[Martin Gagnon]

On Wed, Nov 29, 2017 at 03:36:07PM -0700, Warren Young wrote:
> On Nov 29, 2017, at 3:10 PM, Joerg Sonnenberger  wrote:
> > 
> > On Wed, Nov 29, 2017 at 12:02:11PM -0500, Richard Hipp wrote:
> >> On 11/29/17, Jacob MacDonald  wrote:
> >>> Ah, I see. It seems strange to me that the policy didn't get set when I
> >>> cloned. How can I avoid the same thing in the future and is there any way
> >>> to change the artifacts in the local repository to SHA3?
> >> 
> >> There is no good way to change historical artifacts from SHA1 to SHA3.
> > 
> > There could be a loss-less one-time migration of the whole repo
> 
> We discussed that back around March when all of this was happening.
> The simple cases are easy and the hard cases are really hard.
> 
> For example, if checkin [1234abcd] has a comment that refers to ticket
> [bcdef522] which in turn refers to artifact ID [6543cfe], is the
> migration tool expected to chase and re-point  all those links when
> all the hashes change?

That's why, like drh said earlier in this thread, The best (and easiest)
solution is to simply keep old sha1 artifact as is and use sha3 for
future commits.  In order to do this, you only have to change the
hash-policy to sha3 on local clone and on the server.

As long as you set the hash-policy to "sha3" everywhere, everything will
works fine. It will accept old sha1 artifacts and use sha3 for new
artifacts.

Regards,

-- 
Martin G.
___
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] Weird behavior on Chisel, perhaps a version mismatch?

[Martin Gagnon]

On Wed, Nov 29, 2017 at 12:02:11PM -0500, Richard Hipp wrote:
> On 11/29/17, Jacob MacDonald  wrote:
> > Ah, I see. It seems strange to me that the policy didn't get set when I
> > cloned. How can I avoid the same thing in the future and is there any way
> > to change the artifacts in the local repository to SHA3?
> 
> There is no good way to change historical artifacts from SHA1 to SHA3.
> The best policy is to let sleeping dogs lay and move on using SHA3 in
> the future.  You can do that by running "fossil hash-policy sha3" on
> the local side, where you do your "fossil commit" commands.  That will
> cause all future check-ins to be SHA3.
> 
> I don't know how the server side got set to sha3-only.  That's never
> come up before.

Chisel have an option to upload a repository file, may be it was set to
shun-sha1 locally before to get uploaded to Chisel ?

Is that what happened Jacob ?

-- 
Martin G.
___
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] A-B comparison of proposed timeline changes

[Martin Gagnon]

On Wed, Nov 29, 2017 at 08:10:28AM -0700, Warren Young wrote:
> On Nov 29, 2017, at 7:53 AM, Martin Gagnon <eme...@gmail.com> wrote:
> > 
> > There's a small display glitch, the mouse cursor over the
> > Basic/Advanced button is set to "text selection" mode instead of the
> > usual "hand with the index finger up" for clickable links.
> 
> It can be fixed by adding href="#" into the  elements wrapping the
> Basic and Advanced text.  It would take a CSS geek with a bigger
> propeller than the one on my beanie to tell you why that fixes it,
> though.

Using "Inspect" on chrome, I found that adding:

   cursor: pointer;

inside "element.style" fix the problem. 

I'm not sure where I should add this to have a permanent fix.

-- 
Martin G.
___
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] A-B comparison of proposed timeline changes

[Martin Gagnon]

On Wed, Nov 29, 2017 at 09:26:57AM -0500, Richard Hipp wrote:
> The 4-view-modes timeline change is now on trunk and is the default on
> these sites:
> 
> https://sqlite.org/src/timeline
> https://www.fossil-scm.org/fossil/timeline
> http://mirror1.tcl.tk/tcl/timeline
> https://androwish.org/index.html/timeline
> 
> The "selected entry" highlighting, such as seen here:
> 
> https://www.fossil-scm.org/fossil/timeline?c=trunk
> 
> Still looks goofy in the Modern View, especially using Edge.  Your
> help in fixing that problem will be much appreciated.
>

Looks really nice, thanks. I like the Modern View with the right
justified extra check-in/user/tags informations and the vertical spacing
between commits.

There's a small display glitch, the mouse cursor over the
Basic/Advanced button is set to "text selection" mode instead of the
usual "hand with the index finger up" for clickable links.

Regards,

-- 
Martin G.
___
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] Weird behavior on Chisel, perhaps a version mismatch?

[Martin Gagnon]

On Tue, Nov 28, 2017 at 12:01:45PM -0500, Richard Hipp wrote:
> On 11/28/17, Jacob MacDonald  wrote:
> > On my end, I added a couple of local files in two commits. Then I ran
> > "fossil sync". The commits do not show up on Chisel even though the sync
> > command says it succeeds. Furthermore, opening a new clone of the
> > repository from Chisel seems to be corrupt: When I try to open it, it tells
> > me the manifest is bad and no files get put on the disk.
> 
> Obviously, I cannot test the syncing part because I don't have write
> access on your chisel repo.  But when I clone and open your repo, it
> seems to work fine and report no errors.
> 
> What version of Fossil are you running locally?  What does "fossil version" 
> say?
> 
> Try running:
> 
>  fossil sync --httptrace


If it can help, I've tried to clone the repo, and I notice that I got
an error on "fossil open" command. Also, there was no file on my
checkout. 

Then, I suspect problem with hash policy, since it involve version 2.1
and 2.4 where default hash-policy change. So here's what I got:

$ fossil hash-policy
shun-sha1

Since the repository on chisel use only sha1 hash, it's normal that I
get nothing.

So I change the hash-policy to "sha1", I did fossil up, and all file
appear.

I'm not sure if the problem is related and why the hash-policy after my
clone was set to "shun-sha1".

-- 
Martin G.
___
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] A-B comparison of proposed timeline changes

[Martin Gagnon]

On Fri, Nov 24, 2017 at 06:52:41PM +, Jacob MacDonald wrote:
> Seems like I'm in the minority, but I prefer the A version. I tend to like
> compact UIs and having all the relevant information close together and the
> commit hash prominently displayed is nice.

   

Same for me. 

With B version, checkin hash links are not aligned, so it's
not as natural when it's time to click on them, I have to find the link
at the end of the comment.

Moreover, when the comment wraps on multiple lines, a quick look make it
looks like 2 separate checkins. It's not the case with A version because
a new checkin start with the hash link.

Regards

-- 
Martin G.
___
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] Main repository moved from http to https?

[Martin Gagnon]

I believe it is not intentional, might be same problem that happens before:

https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg24067.html

—
Martin G.

Le mar. 7 nov. 2017 à 06:08, Stephan Beal  a écrit :

> On Tue, Nov 7, 2017 at 11:25 AM, Stefan Bellon  wrote:
>
>> Dear Fossil users,
>>
>> until recently a fossil remote of http://www.fossil-scm.org/ worked,
>> but now I get
>>
>> cannot connect to host www.fossil-scm.org:80
>>
>
> fwiw, that also happened to me when i typed "sqlite.org/src" into my
> browser's URL bar today. Only after saying to myself "wha!?!?" and googling
> did i get the https link and land on the site (at which point i realized
> that https was the missing puzzle piece).
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
> those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] New settings help change on trunk

[Martin Gagnon]

Hi,

I've notice a regression since checkin [f74f7014], there's no more help
text for each settings when doing "fossil help set" or "fossil set
--help".

Moreover, since mkindex can now extract individual help text from
settings, we could add individual settings help text from the CLI when
typing:  "fossil set  --help".

Regards,

-- 
Martin G.
___
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] src/blob.c : blob_read_from_file overflow int size

[Martin Gagnon]

On Tue, Jun 13, 2017 at 04:19:53PM +0900, kowlsd3pw...@yahoo.co.jp wrote:
> 
>  [837333fc] Fix the blob_read_from_file  
> thank you.

Actually, it is not completely fix because blob_read_from_file() call
blob_read_from_channel() which return a int. 

Anyway, since the internals of the Blob structure use "unsigned int" to
track size and all other functions that deal with Blobs expect "int" or
"unsigned int", it would require a lot more changes to really make it
works for really big files. 

The question is, Does it really worth it? Knowing that it would probably
slow down for 99.99% of the case, especially on older non 64bit
architectures.

However, I think the best types for Blob structure is probably size_t.
I'm not sure if it's okay to use size_t with C89, but fossil already use
it in some places (even in blob.c), so I guess it's not a problem.

Regards,

-- 
Martin G.
___
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 http" doubts

[Martin Gagnon]

> Le 7 juin 2017 à 02:48, Johan Kuuse  a écrit :
> 
>> On Tue, Jun 6, 2017 at 6:15 PM, Richard Hipp  wrote:
>>> On 6/6/17, Johan Kuuse  wrote:
>>> Hi,
>>> 
>>> Is there any way to access the Fossil built-in webpages using the "fossil
>>> http"?
>>> In the example below, I try to access the /setup page from localhost,
>>> but it seems I don't get authorized. Instead I get redirected to the
>>> /login page.
>> 
>> You have to log in as a user with "s" (superuser) permission in order
>> to access the /setup page.  If you try to access /setup without the
>> right permissions, you get redirected.
>> 
>> Log in first, then try again.
> 
> Maybe I did not make myself very clear.
> I am running "fossil http" from the command line.
> Is there a way to first "login" from the command line, and then access
> built-in pages such as "/setup", also from the command line?
> 
> My idea is to make a script which parses the output from all builtin pages.
> 

I'm not sure to understand what you want to do but you probably want to use: 
"fossil test-http" instead. 
  https://www.fossil-scm.org/index.html/help?cmd=test-http

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

Re: [fossil-users] Problem with: fossil revert -r xxx

[Martin Gagnon]

On Thu, May 11, 2017 at 09:14:43AM -0400, Richard Hipp wrote:
> On 5/10/17, Ron Aaron  wrote:
> > I tried to revert to a good revision 'xxx' using "fossil revert -r xxx"
> >
> > Despite the help stating "Revert all files if no file name is provided",
> > instead fossil told me, "the --revision option does not work for the
> > entire tree".
> 
> Amid all the confusion, I'm not sure this question was ever answered.
> So let me now try...
> 
> The "fossil revert" command is intended to undo edits to the local
> check-out and restore the content of files back to the last committed
> version.  For example, you start making some change and decide that
> your idea isn't really working out, so you type "fossil revert" to
> take you back to a pristine state.  Or you do "fossil revert
> $filename" to undo all of the local edits for a particular file while
> retaining the edits to other files.
> 
> The "fossil revert" command only affects the local check-out.  It
> makes no changes to the repository.
> 
> If you want to move your whole check-out to a different baseline,
> better to do so using:
> 
>  fossil revert
>  fossil update $newbaseline

Which is equivalent to:

 $ fossil co --force $newbaseline


For what I've understand from the Ron situation, I believe he needs to
revert to a previous version in trunk (6 or 7 commits ago in his case)
and continue development from there. 

That's what I've suggest on my previous post.  Exactly the same as what
you suggest above + a "checkin edit" on the web ui to move all the
checkins following the $newbaseline in another branch.

> 
> If you want to change a single file to be the same as it was several
> check-ins ago, better to do something like this:
> 
>  fossil artifact $hash >$filename

If you don't want to use the hash of the file, but the checkin hash (or
a tag name), the following will also works: 

 $ fossil revert $filename
 $ fossil up $newbaseline $filename

And may look more natural for people that are not used to do stdout
redirection to file.


my 2 cents...

Regards, 

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

Re: [fossil-users] Problem with: fossil revert -r xxx

[Martin Gagnon]

On Thu, May 11, 2017 at 12:17:44PM +0300, Ron Aaron wrote:
> Sorry, but I can't see how the terminology "... all files if no file
> name is provided" could mean anything but what I assumed.
> 
> It may not be used often, but in the event were one has decided, as I
> did, that a certain number of trunk changes (as in: the last 7) need to
> be reverted, it is what one would expect to be able to use.  That is,
> "revert not just one file, but all files, to a given revision".
> 
> Yes, I can "upd XXX" to get back to XXX.  But since I want the continued
> development to be from there on, but I don't want to branch, I have two
> options if 'revert' doesn't work:
> 
>  1. Do "merge --backout" in reverse order for each of the N revisions I
> want to remove, or
>  2. Do "upd XXX" and then "ci --allow-fork", than "upd trunk" and "merge
> that-branch" and then close that-branch
> 
> Neither is nearly as simple and intuitive as "revert".
> 
> No, I didn't want to update to that revision, I wanted to replace the
> tip with that revision.


In that case, it mean that all changes following XXX needs to become a
new branch that would will abandon or continue development later. This
happens often to me, here what I do normally:

   1. fossil co --force XXX  
(or "fossil up XXX" if you want to keep uncommited changes)

   2.  Edit the checkin following XXX (using fossil ui) and use "make
   this checkin the start of a new branch:", This way XXX will
   become the new tip of trunk.

I found this better than having revert to do what you want, because here
we know what's happens by looking the timeline.

If the commits following XXX was really a mistake, you can just name
this branch "mistake" and you can optionally hide it.


Regards,

-- 
Martin G.
___
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] Can Fossil preserve file timestamps when opening a repository ?

[Martin Gagnon]

It has been discuss a few times before. I think here is a good summary
about why it is like this now:

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

-- 
Martin G.
Le mer. 19 avr. 2017 à 19:41, Martin Irvine 
a écrit :

> Hi,
>
> This seems a pretty basic question but I can't seem to find an answer or
> explanation online...
>
> I am a fairly new Fossil user and I am surprised that when I open a
> repositiory (on Windows 7) all the extracted files seem to have their
> timestamp set to the date and time at which they were extracted (that is,
> the date and time at which I opened the repository).
>
> I would prefer that Fossil preserved the date and time stamp that the file
> had when it was most recently committed.
>
> In fact, it seems to me this resetting of the timestamps is a bad idea,
> unless someone can explain to me why this is a good idea ?
>
> More importantly, unless it really is a good idea that it doesn't, is
> there a way I can get Fossil to preserve the date and time stamps on the
> files it extracts from a repository ?
>
>
> I would appreciate any thoughts, clarification or guidance on this.
>
>
>
> Thanking you for your assistance,
>
>
>
>
>
> Martin Irvine.
>
> ___
> 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] Feature request: local .fossil-ignore

[Martin Gagnon]

On Wed, Apr 19, 2017 at 07:29:42AM +1000, rosscann...@fastmail.com wrote:
> @Barry: True, but it's clumsy, since you have to specify every path, in
> full, in the global ignore-glob file. If you move a subproject to a
> different location in the directory tree, you have to remember to update
> the ignore-glob file.
> 

That's true, but in some cases, the fossil ignore-glob is more useful.

Example:
*/obj/*
*.o
*.bak

Which will works for the whole repo.

I often do something like this to create or update my ignore-glob file: 

fossil extra >> .fossil-settings/ignore-glob

vim .fossil-settings/ignore-glob
   
   (cleanup the content added by "fossil extra" by replacing by the
   most general glob pattern possible to get rid the extras and
   keep some individual file from the list if needed, for the
   exceptions)


But I agree that the per directory ignore file have it's advantage in
some situations. 

> 
> This is something I miss from Subversion (and Git, too, apparently) -
> the ability to set an ignore list for *just this directory*, and have
> that ignore list move around with the directory automatically.
> 
> 
Also true for the venerable CVS (.cvsignore files).

   [snip]

-- 
Martin G.
___
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] Couple of beginner questions

[Martin Gagnon]

On Wed, Mar 29, 2017 at 03:47:32PM -0500, The Tick wrote:
> On 3/29/2017 3:04 PM, Stephan Beal wrote:
> >On Wed, Mar 29, 2017 at 9:52 PM,  >> wrote:
> >
> >Yes, change your text files to UTF-8 with BOM(unsure without BOM)
> >and Fossil respects °, ±, ©, ®, special characters.
> >
> >
> >Actually, UTF8 does not typically use a BOM because byte order is
> >meaningless with UTF8 (the standard allows a BOM but does not require it).
> >
> >https://en.wikipedia.org/wiki/Byte_order_mark
> >
> 
> I took my u.tcl file, removed the 'bom' and now both tclsh and wish work.
> 
> If I edit the file, of course the utf-8 copyright symbol is garbled.
> Furthermore, there is no way I can insert a utf-8 character.

About gvim and UTF-8 files without BOM, my vim is set with 
  set encoding=utf-8
  set fileencoding=utf-8

and everything works like a charm.

Also, If I edit a ascii file that doesn't contain any special character,
it remain ascii.

 

-- 
Martin G.
___
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] Crash with this AMEND command

[Martin Gagnon]

FYI: the problem got fixed in trunk 2 days  ago.

  https://www.fossil-scm.org/index.html/info/8c22e1bbcd8ec048

-- 
Martin G.

Le lun. 20 mars 2017 à 13:22, Warren Young  a écrit :

> On Mar 18, 2017, at 11:59 PM, Andy Bradford 
> wrote:
> >
> > Thus said "Tony Papadimitriou" on Sat, 18 Mar 2017 01:59:21 +0200:
> >
> >> The  following  command  crashes  fossil  (older  and  up  to  current
> >> version).
> >
> > It doesn't crash for  me.
>
> It didn’t crash for me initially, either.  I initially tried doing it from
> outside of a Fossil checkout tree, assuming all that was needed was the
> cloned DB file, referred to by -R.  Then I cd’d to one of the checkouts for
> that repository referred to by -R, and it started happening here.
>
> The file and line number in my previous email comes from a GDB backtrace
> in a core file.  “print z” at the crash site says 0.
>
> > Can you be more specific  as to which version?
>
> This is fossil version 2.1 [f89e0d4a91] 2017-03-10 17:19:19 UTC
>
> That is, the 2.1 release version.
>
> > Also, which OS?
>
> I did this on CentOS 7, but I suspect Tony is on Windows, from past
> posts.  I do not believe this bug is OS-specific.
> ___
> 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] Non empty directories

[Martin Gagnon]

On Wed, Mar 15, 2017 at 09:05:28PM +1000, Dan Raymond wrote:
> Think I understand:
> 
> If a Folder is empty no add of folder (not sure why the "Character" folder
> wouldn't add when it was not empty). subsequent trials worked as supposed
> to.
> 
> So not sure what issue was. will play around more to see if I can replicate
> before committing to a real world scenario.
> 
> Is there any way to force adding empty directories??

No, fossil don't store directories, they are treated like a part of the
"full-name" of a file, they don't exist by themself inside a repository.

May be this discussion will interest you:
  http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg23675.html


Reards,

-- 
Martin G.
___
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] Non empty directories

[Martin Gagnon]

It should works, unless there's some information we don't know. Do you have
something in  "ignore-glob" (what is the output of : "fossil set
ignore-glob" ?

Can you paste here the transcript of your console when you try ?

Have you try same thing on a brand new repository? Is it the same ?


Regards,

-- 
Martin G.

Le mer. 15 mars 2017 à 06:24, Dan Raymond <d...@ecourban.com.au> a écrit :

> Martin,
>
> No they are normal names no dots.
>
> Dan
>
> Level 19 Waterfront Place, 1 Eagle Street Brisbane Qld 4000 Australia
> Mail:   PO Box 7815 Waterfront Place, Brisbane 4001
> Tel:+61 733 600 255
> Mob:  +61 400 551 920
> Fax:   +61 733 600 222
> Web:  http://ecourban.com.au
>
> On Wed, Mar 15, 2017 at 8:13 PM, Martin Gagnon <eme...@gmail.com> wrote:
>
> Does the directory name start with a dot ? The dot files (and dot
> directories) are ignored by default. So you can try:
>
>   fossil add --dotfiles .
>
>
> --
> Martin G.
>
> Le mer. 15 mars 2017 à 06:06, Dan Raymond <d...@ecourban.com.au> a écrit :
>
> Pietro,
>
> addremove Doesn't do it (version 2.10)
>
> add command doesn't pick up the folder even though there is a new file in
> it!
>
> AH!
>
> Dan
>
> Level 19 Waterfront Place, 1 Eagle Street Brisbane Qld 4000 Australia
> Mail:   PO Box 7815 Waterfront Place, Brisbane 4001
> Tel:+61 733 600 255
> Mob:  +61 400 551 920
> Fax:   +61 733 600 222
> Web:  http://ecourban.com.au
>
> On Wed, Mar 15, 2017 at 7:17 PM, Pietro Cerutti <g...@gahr.ch> wrote:
>
> On 2017-Mar-15, 19:03, Dan Raymond wrote:
> [-- Type: text/plain; charset=UTF-8, Encoding: 7bit, Size: 0.6K --]
> > How can I get the fossil add command to add new directories under the
> root
> > checkout when they have new files in them. I understand fossil doesn't
> > notice new empty directories when you use the add command, but these also
> > have new files.
> >
> > The fossil  add only adds files in the _FOSSIL_ directory. If I create
> new
> > folders below this with files in them they and their files are not added?
> >
> > What to do?
>
> fossil addremove?
>
> --
> Pietro Cerutti
> g...@gahr.ch
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Non empty directories

[Martin Gagnon]

Does the directory name start with a dot ? The dot files (and dot
directories) are ignored by default. So you can try:

  fossil add --dotfiles .


-- 
Martin G.

Le mer. 15 mars 2017 à 06:06, Dan Raymond  a écrit :

> Pietro,
>
> addremove Doesn't do it (version 2.10)
>
> add command doesn't pick up the folder even though there is a new file in
> it!
>
> AH!
>
> Dan
>
> Level 19 Waterfront Place, 1 Eagle Street Brisbane Qld 4000 Australia
> Mail:   PO Box 7815 Waterfront Place, Brisbane 4001
> Tel:+61 733 600 255
> Mob:  +61 400 551 920
> Fax:   +61 733 600 222
> Web:  http://ecourban.com.au
>
> On Wed, Mar 15, 2017 at 7:17 PM, Pietro Cerutti  wrote:
>
> On 2017-Mar-15, 19:03, Dan Raymond wrote:
> [-- Type: text/plain; charset=UTF-8, Encoding: 7bit, Size: 0.6K --]
> > How can I get the fossil add command to add new directories under the
> root
> > checkout when they have new files in them. I understand fossil doesn't
> > notice new empty directories when you use the add command, but these also
> > have new files.
> >
> > The fossil  add only adds files in the _FOSSIL_ directory. If I create
> new
> > folders below this with files in them they and their files are not added?
> >
> > What to do?
>
> fossil addremove?
>
> --
> Pietro Cerutti
> g...@gahr.ch
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Non empty directories

[Martin Gagnon]

fossil add NEWDIR
  or
fossil add .

 (Don't forget the "." on the latter., which will all everything under
current directory)

Regards

-- 
Martin G.

Le mer. 15 mars 2017 à 05:03, Dan Raymond  a écrit :

> How can I get the fossil add command to add new directories under the root
> checkout when they have new files in them. I understand fossil doesn't
> notice new empty directories when you use the add command, but these also
> have new files.
>
> The fossil  add only adds files in the _FOSSIL_ directory. If I create new
> folders below this with files in them they and their files are not added?
>
> What to do?
> Level 19 Waterfront Place, 1 Eagle Street Brisbane Qld 4000 Australia
> Mail:   PO Box 7815 Waterfront Place, Brisbane 4001
> Tel:+61 733 600 255
> Mob:  +61 400 551 920
> Fax:   +61 733 600 222
> Web:  http://ecourban.com.au
> ___
> 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 can not import its own git export

[Martin Gagnon]

On Tue, Mar 14, 2017 at 08:48:50PM -0500, Artur Shepilko wrote:
> Just tried the case of "file name contains a newline char" with git.
> Looks like git encodes such names with C-like characters ('\n' for x0A
> or '\r' for x0D).
> 
> Git fast-export outputs such files enquoted as follows:
> M 100644 :1 "newline\nfile.txt"
> 
> For the same case, fossil export does not encode the control chars and
> just outputs such names directly:
> M 100644 :4 newline
> file.txt
> 
> I guess an extra encoding/decoding step is needed in fossil
> export/import. Perhaps this is not for practical but at least for
> compatibilty reasons.

And by following this:
  https://git-scm.com/docs/git-fast-import#git-fast-import-Inlinedataformat

It should be pretty straight forward. Only \n, \\ and \" character needs
to be escaped and if 1 of them is present, the filename must be
surrounded by double-quotes. 

I'm very busy now, so if someone doesn't beat me on this, I might try
to implement this later.


Regards,

-- 
Martin G.
___
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 can not import its own git export

[Martin Gagnon]

On Fri, Mar 10, 2017 at 02:02:23PM -0600, Zakero wrote:
> In an effort to do some experimenting with the latest release of Fossil:
> 
> ./fossil-2.1 version
> This is fossil version 2.1 [83e3445f67] 2017-03-10 17:07:08 UT
> 
> I wanted to export the fossil repository to git.  Then import the "git
> file" back into fossil.  Being the first time to attempt this, there is a
> good chance I am doing something wrong.  Below are the 2 fossil commands:
> 
> ./fossil-2.1 export --git -R ./fossil-scm.fossil > ./fossil-scm.git
> ./fossil-2.1 import --git fossil-sha3.fossil ./fossil-scm.git
> 
> The import fails with an error: "bad fast-import line: [def.txt]"

It seems to be a problem with a weird filename (with a newline in it),
added in this checkin: 
  http://fossil-scm.org/index.html/info/ac1af2306b70c537

  (It's all what this checkin was about: to test how fossil can handle
  some weird filenames.)

One of the file in this checkin is: "abc\ndef.txt" (with a newline)

Looks like the export/import command doesn't support file with newline,
we can see the filename is truncated in the error message.

I even test using the version of fossil from branch: ticket-d17d6e5b17
(from 2013) that was made to fix some issues with filenames and I get
the same error when exporting/importing a test repository with a file
containing a newline in it.

  [snip]

Attached to this email (hopefully it will not get removed) is my test
script that I use to create a new repository with a file containing a
newline in it and trying to do an export/import cycle.

If you look at the resulting "test.git-export" file, you can see that
the newline on the filename produce a line with a part of the filename
in it, which is seen as garbage on the git-fastexport file.

I have no clue how to fix that.

Regards

-- 
Martin G.


test_file_with_newline.sh
Description: Bourne shell script
___
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] Progress report of Fossil 2.x

[Martin Gagnon]

On Sat, Mar 04, 2017 at 03:07:04PM +0200, Tony Papadimitriou wrote:
> -Original Message- From: Warren Young
> 
> > > (3) New repositories are initialized using SHA3
> > Maybe there should be a “fossil init --sha1” option for the
> > technologically conservative.
> 
> Or, for practical reasons.  So, I second that.
> 
> For example, creating a new repo locally to be hosted by chiselapp (which is
> still running 1.34 BTW) would fail.

In fact, it run 1.36 now (I got corrected recently when I made the same
statement). For some reason, the fossil version we see on the main page
is not the same as the one when you click on a public repository.

> Of course, there is the option of creating on chiselapp and then cloning and
> continuing from there, but it should be able to work both ways because one
> may discover the problem after having done too much work locally.

I'm pretty sure the chiselapp maintainer is on that list and it's
probably on his plan to upgrade to fossil-2.0.

If he does, problem solve, any version of fossil can sync with
chiselapp.

Regards,

-- 
Martin G.

___
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] Progress report of Fossil 2.x

[Martin Gagnon]

In my case, 

Warren, I agree with you...

-- 
Martin G.

On Wed, Mar 01, 2017 at 10:24:56AM -0700, Warren Young wrote:
> On Mar 1, 2017, at 2:03 AM, Tony Papadimitriou  wrote:
> > 
> > My 'prediction' is that two versions will end up in a similar mess to the 
> > Python 2.7 vs Python 3.x one.
> 
> Python 3 wouldn’t run a large subset of the available Python 2 code, on 
> purpose.  Fossil 2.x will fully use Fossil 1.x DBs.  If you stick to Fossil 
> 2.0, you can even continue to use Fossil 1.x with that same DB.  That doesn’t 
> sound like the Python situation to me at all.
> 
> Python 2 wouldn’t run any Python 3-specific code, but the same is true about 
> Python 2.6 and Python 2.7, which you don’t seem to be worried about.  Rather, 
> you seem to be waving the “disaster once occurred somewhere else under 
> entirely different circumstances” flag.  (I included that latter bit because 
> MD5 vs SHA1 vs SHA3 is not “under entirely different circumstances.”)
> 
> Python 2 to Python 3 was a huge jump in terms of removing old features and 
> such.  None of that is happening here.  Fossil 2 is about a *single feature*.
> 
> Which item in the following document looks like the Fossil 1 to 2 transition 
> to you?
> 
> https://docs.python.org/3/whatsnew/3.0.html
> 
> If you want to never change, never upgrade, stick with Fossil 1.  Fork it if 
> you like; you have that right under Fossil’s 2-clause BSD license.
> 
> > Also, Fossil 2.0 will not be able able to get any significant updates due 
> > to version collision with 2.1 (so, maybe 2.0 and 3.0 -- oops, more like 
> > Python!)
> 
> 2.0.1.
> 
> > And, having to remember which version to use depending on the other side 
> > being compatible or not, will be a practical nuisance.
> 
> drh has already said the new versions will warn you when you’re about to run 
> into a conflict.
> 
> > Would it not be possible to have a single version that simply keeps an 
> > extra table with the SHA3 and the presence of the table alone will 
> > determine which way to go?
> 
> Certainly.
> 
> But every binary configuration option potentially doubles the size of the 
> test space.  Every existing test has to run in all possible configurations.
> 
> So, who will do that work, and why?
> 
> I’m not asking why you want the work done, I’m asking why that person would 
> do it for you, if it is not you doing the work for your own benefit.  What 
> itch is that person scratching?
> ___
> 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] Google Security Blog: Announcing the first SHA1 collision

[Martin Gagnon]

On Thu, Feb 23, 2017 at 03:18:29PM -0800, bch wrote:

  [snip]
> 
> Or more correctly, "a *subsequent* file with the same sha1 hash..." If you
> happened to commit the Trojan file first, the "good" commit would have been
> the one to fail.
>

True, but if you pull from untrusted user (or give push access to
untrusted user), nothing prevent the trojan file to get in, even without
sha1 hash collision.

But at least, someone cannot replace a file you already have with a
malicious one with the same sha1 hash.

-- 
Martin G.
___
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] Google Security Blog: Announcing the first SHA1 collision

[Martin Gagnon]

On Thu, Feb 23, 2017 at 09:50:12AM -0800, Marc Simpson wrote:
> This may be of interest to some here, especially in light of previous
> SHA-1 related discussions on list:
> 
>   https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
> 

Also, Here's a related discussion from git mailing list:
  https://marc.info/?t=14878688461=1=2

Somebody tried those 2 colliding pdf's on a git repository:
  https://github.com/joeyh/supercollider

Seems that Git can store both of them, I beleive it calculate the sha1
on a combination of the filename and the content or something like that.

So I was curious and I tried to put them on a fossil repository.


  Here what I got (with repo-cksum enabled):
  --
$ ls
bad.pdf  good.pdf

$ sha1sum bad.pdf good.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  bad.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  good.pdf

$ fossil add bad.pdf
ADDED  bad.pdf

$ fossil add good.pdf
ADDED  good.pdf

$ fossil commit
[***] Current default user: mgagnon
vim "./ci-comment-A70B84D400D2.txt"
./bad.pdf contains binary data. Use --no-warnings or the "binary-glob" 
setting to disable this warning.
Commit anyhow (a=all/y/N)? a
New_Version: 510b26ef49be508003304840a9ea18894007ad51
ERROR: [good.pdf] is different on disk compared to the repository
NOTICE: Repository version of [good.pdf] stored in 
[file-3a8b62456795ffdb]
working checkout does not match what would have ended up in the 
repository:  2106b982989e5604ec91523ddd81c879 versus 
a388ff244a318ee5904ba276b754d84a
  -

Seems that repo-cksum give an extra protection against this kind of
collision. (but don't let the file goes in...)

Then, I tried with repo-cksum disabled. 

  1- I add good.pdf and commit.
  2- I add bad.pdf and commit (it succeed)
  3- I check with "fossil ui" and both files share the same content
 (good.pdf)

At least, if a file with a certain sha1 hash exist on a repo, a
malicious file with the same sha1 hash should never goes in.

I'm not an expert in encryption and security: I agree that the
possibility of sha1 collision is not a good thing, but it's probably not
the end of the world and it doesn't make fossil un-usable.

  side note: A collision is a lot easier to produce on a file like a pdf
 than on a source file. 

"That's why pdf's are the classic model for showing
these attacks: it's easy to insert garbage in the
middle of a pdf that is invisible."

-- git mailing list citation

Regards,

-- 
Martin G.
___
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] Unversioned files not accessible from Web interface

[Martin Gagnon]

 Sorry my bad,  I was confused because on the main page the footer of the
page shows 1.34,   but I just notice that when going inside one repository
it's 1.36.

-- 
Martin G.

Le mer. 22 févr. 2017 à 11:45, Roy Keene <fos...@rkeene.org> a écrit :

> ChiselApp runs Fossil 1.36 currently, not 1.34.
>
> On Wed, 22 Feb 2017, Martin Gagnon wrote:
>
> >
> > Le mer. 22 févr. 2017 à 03:33, Tony Papadimitriou <to...@acm.org> a
> écrit :
> >   I placed some unversioned file to a chiselapp repo I maintain and
> then from the Web UI tried to locate the file but without luck.
> > There isn?t even a hint that some unversioned file is in the repo, so
> that one can try to UNV SYNC from the command line (after cloning).
> >
> > Maybe the FILES tab should have an additional option (next to All,
> Tree-View, etc.) for Unversioned?  And from there process them (e.g.,
> download, hex) exactly the same.
> >
> >
> >
> > Hi Tony,
> >
> > To see the list of unversionned files on a repo, use the /uvlist page:
> >
> >  example: https://www.fossil-scm.org/index.html/uvlist
> >
> > But in your case, I'm afraid that Chiselapp use a too old version of
> fossil (1.34). unversionned files feature appear in 1.36.
> >
> > May be "unver sync" command could return an error in that case?
> >
> > Regards,
> >
> > --
> > Martin G.
> >
> >___
> 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] Unversioned files not accessible from Web interface

[Martin Gagnon]

Le mer. 22 févr. 2017 à 03:33, Tony Papadimitriou  a écrit :

> I placed some unversioned file to a chiselapp repo I maintain and then
> from the Web UI tried to locate the file but without luck.
> There isn’t even a hint that some unversioned file is in the repo, so that
> one can try to UNV SYNC from the command line (after cloning).
>
> Maybe the FILES tab should have an additional option (next to All,
> Tree-View, etc.) for Unversioned?  And from there process them (e.g.,
> download, hex) exactly the same.
>
>

Hi Tony,

To see the list of unversionned files on a repo, use the /uvlist page:

 example: https://www.fossil-scm.org/index.html/uvlist

But in your case, I'm afraid that Chiselapp use a too old version of fossil
(1.34). unversionned files feature appear in 1.36.

May be "unver sync" command could return an error in that case?

Regards,

-- 
Martin G.
___
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] Directory symlinks...

[Martin Gagnon]

On Tue, Feb 14, 2017 at 10:06:34AM -0800, Joe Mistachkin wrote:
> 
> Martin Gagnon wrote:
> >
> > I'm not sure if this protection is necessary, but if it is, it doesn't
> > get triggered if the symlink point directly to "../../dir3/other_ckout"
> > since the "top of a checkout" check only happens for the recursive call.
> > 
> 
> I believe this may be to protect against file system loops?
> 
I don't think so, all the check does is to look for a _FOSSIL_ or a
.fslckout file exist inside the specified directory.

> >
> > I don't know if the top of a checkout *must* be skipped or not, but
> > right now there's something inconsistent with this rule.  
> > 
> 
> I think it's by design.  It does not appear to be directly related to
> the symlinks issues.
> 
True, the same issue happens when doing the "add" on a real directory.
If a subdirectory inside is the top of a checkout, it will be *silently*
skipped.

I've also notice that the "extra" command ignore those "top of checkout"
directories, just like the "add" command.

So my understanding is that those "top of checkout" directory are
ignored during scan, unless they are explicitly specified from command
line. It does make sense to me now.

May be it would be useful to have a verbose mode (-v) on some commands
like "add" and "extra"? In verbose mode, those commands could print
why some files or directory got skipped. Just an idea...

Regards

-- 
Martin G.
___
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] Directory symlinks...

[Martin Gagnon]

On Mon, Feb 13, 2017 at 07:10:52PM -0800, Joe Mistachkin wrote:
> 
> Martin Gagnon wrote:
> > 
> > Strange, "fossil add a_dir_symlink" doesn't works for the case #2 on my
> > actual repository, but if I try to reproduce the problem on a brand new
> > repo, everything works.. Probably I hit a strange corner case. I will
> > try to investigate a bit more.. 
> > 
> 
> I've added the 'test-file-environment' command to Fossil to help with
> figuring this stuff out.  Also, it has an --open-config option which
> is useful.
> 

Thanks for this Joe,

I didn't find something wrong using test-file-environment, my real repo
and my test repo show same things.

However, I decide to debug using gdb, and I found the reason why the
"fossil add symlink_dir" fail in my real repo (with case #2). I was able
to reproduce the same on a new test repository.

It happens that the symlink point to a directory containing a directory
that is the top of a checkout:

  Example:

 /dir1/dir2/main_ckout/dir_symlink

 /dir1/dir2/dir3/other_ckout



 where: 
dir_symlink point to:  ../../dir3


Inside add_cmd, vfile_scan(...) is called with "dir_symlink" here:
  http://fossil-scm.org/index.html/artifact?ln=334=f23144d54a286503

Then, since vfile_scan() find "other_ckout" directory inside, it should
normally call himself recursively with "other_ckout" but in this case
"other_ckout" get skipped here:
  http://fossil-scm.org/index.html/artifact?ln=542=f2ac27cd86e8ff0c

 because it is the top of a checkout.

I'm not sure if this protection is necessary, but if it is, it doesn't
get triggered if the symlink point directly to "../../dir3/other_ckout"
since the "top of a checkout" check only happens for the recursive call.

I don't know if the top of a checkout *must* be skipped or not, but
right now there's something inconsistent with this rule. 


Regards

-- 
Martin G.
___
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] Directory symlinks...

[Martin Gagnon]

On Mon, Feb 13, 2017 at 02:29:58PM -0800, Joe Mistachkin wrote:
> 
> Martin Gagnon wrote:
> >
> > But if I do:
> >   $ fossil add a_dir_symlink/*
> >
> > It add the content.
> >
> > Actually, may be it was intended ?
> >
> 
> The way it should work (on the branch) is:
> 
>   1. With allowSymlinks ON, symlinks to both files and
>  directories are always treated as "normal" content
>  files.  In this case, the --no-dir-symlinks flag
>  has no effect because they are already disabled.
> 
>   2. With allowSymlinks OFF and WITHOUT the --no-dir-symlinks
>  flag, symlinks to files refer to the linked file and
>  symlinks to directories are traversed into.
> 
>   3. With allowSymlinks OFF and WITH the --no-dir-symlinks
>  flag, symlinks to files refer to the linked file and
>  symlinks to directories are NOT traversed into.
> 
> Given the above, my local testing seems to confirm that it
> works as intended, including the "add" command.
> 

Strange, "fossil add a_dir_symlink" doesn't works for the case #2 on my
actual repository, but if I try to reproduce the problem on a brand new
repo, everything works.. Probably I hit a strange corner case. I will
try to investigate a bit more..

Regards, 

-- 
Martin G.
___
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] Directory symlinks...

[Martin Gagnon]

On Mon, Feb 13, 2017 at 01:11:39PM -0800, Joe Mistachkin wrote:
> 
> Martin Gagnon wrote:
> >
> >   $ fossil add a_dir_symlink
> > 
> > Nothing happens... 
> > 
> 
> It was a bit more complex than I thought, made a couple more changes.
> 
> Hopefully, it will work better now.

Same result with [b3fc0a13].

Just to be clear, my working case works fine, it add the symlink as-is
in the repo by default if "allow-symlinks" is "on". The problem is for
the other case where one want to add the content of the directory
pointed by the symlink (when allow-symlinks is off).

But if I do:
  $ fossil add a_dir_symlink/* 

It add the content.


Actually, may be it was intended ?


-- 
Martin G.
___
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] Directory symlinks...

[Martin Gagnon]

On Mon, Feb 13, 2017 at 12:37:10PM -0800, Joe Mistachkin wrote:
> 
> Changes on the "symlinks" branch prevent directory symlinks
> from being traversed into if the "allow-symlinks" setting is
> enabled or the "--no-dir-symlinks" flag is specified.
> 
> Making this change work correctly also required removing the
> forced override of the cached "allow-symlinks" setting from
> the "clean" and "extras" command implementations.  This will
> probably increase the need for thorough testing.
> 

Hi Joe, thanks for the quick reply.

I just tried your new branch and for the case I described before, it
works (when I have "allow-symlinks" set to "ON"). 

However, I tried with "allow-symlinks" set to "off" to see how
transversal of directory symlink works and if I do something like this:

  $ fossil add a_dir_symlink

Nothing happens... 

but if I do this:

  $ fossil add a_dir_symlink/a_subdir


All the content of "a_subdir" get added.

Looks like when allow-symlinks is off, if the final target of the "add"
command is a symlink, it get ignored.

Regards,

-- 
Martin G.
___
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] Directory symlinks...

[Martin Gagnon]

On Fri, Sep 30, 2016 at 09:25:01PM -0700, Joe Mistachkin wrote:
> 
> Warren Young wrote:
> >
> > Well, that's a tricky one, innit?  Fossil manages files, not directories,
> > but Fossil's view of symlinks is file-like.  So is it an apple or an
> > orange?
> >
>  
> I've checked in a fix on the dirSymlinks branch that appears to completely
> fix the issue I personally encountered.
> 
> I would appreciate wider testing of it.
> 

Sorry if I'm late, but I just encounter some issues with the
"dirSymlinks" branch. (which is now merged on trunk).

I believe that it conflict with the "allow-symlinks" feature.
When I enable "allow-symlinks", I want *any* symlinks (file or
directory), to be stored in the repository as a special symlink file. I
don't want to add the file (or directory) that is pointed by the
symlink, I just want the same symlink to be created on a new checkout.

I saw that a new change recently get merged (from noSymlinks branch)
that address this issue by adding a "--no-symlinks" option to almost all
command that have to deal with symlinks. While it does what I need 
when using the "--no-symlinks" option, I think it should be the default
behavior (especially when "allow-symlinks" is enable).

I understand that the dirsymlinks feature can be useful, but it think it
needs a separate options in order to keep same default behavior as
before.

Any thought ?


Thanks

-- 
Martin G.
___
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] Adding binary files to fossil

[Martin Gagnon]

On Tue, Jan 03, 2017 at 10:08:40AM -0800, Scott Doctor wrote:
> I have a repository with typical C source text files (about 100
> files across several sub-folders). There are a few binary files that
> are needed to compile and use the program. The files are part of the
> program, but the contents need to stay as-is binary. What is the
> proper way to add binary files to a repository? I want the others to
> be able to simply unzip and have the full set of files without
> having to do a separate download and unzip for the binaries.
> 

There's nothing special to do, the binary files will always stay "as-is"
like regular text files. 

I often have some small binary "resources" files in my repositories and
I never had problem with them. If they are not too big and doesn't
change often, the size and speed of the repository should not be
affected.

Regards,

-- 
Martin G.
___
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] EXECUTABLE, and not really being added to updated repo

[Martin Gagnon]

On Wed, Dec 07, 2016 at 12:13:01PM -0500, Will Parsons wrote:
> On Tuesday,  6 Dec 2016  5:46 PM -0500, bch wrote:
> > I've got a collection of files who's apparently only change is the
> > EXECUTABLE bit set, but after a commit, they're still showing up in "f
> > chan"; I retried w/ a --sha1sum switch; still listed as changed
> > (despite the new commit showing up in the "f timel"). touch(1) all the
> > affected files to bump the timestamp, re-commit, STILL listed as
> > changed (but an entry in the timeline for that commit is listed).
> >
> > Haven't dug further into whats going on, but it looks like an error,
> > or at least non-intuitive.
> 
> What kind of filesystem?  Apparent dicrepancies in the executable bit
> can show up if the filesystem doesn't support proper permissions.
>

Also, might be slightly related. 

On windows (using binary from download page: mingw 32bit), the
EXECUTABLE bit seems to be ignore on the checkout and even if the
filesystem don't support permissions, "fossil change" doesn't see any
mismatch on the EXEC bit.

Probably because of those check:
  http://fossil-scm.org/index.html/artifact?ln=1550+1563=1913859177ca9012
  http://fossil-scm.org/index.html/artifact?ln=249+256=0cd782064e70a543


This check if current architecture support executable bits, but *not* if
the actual *filesystem* support it.

Moreover, it use _WIN32. So if I produce a 64bit windows executable
using mingw-w64 (from msys2: https://msys2.github.io/), _WIN32 is not
defined and "fossil change" always report a bunch of UNEXEC/EXEC
changes on NTFS or FAT filesystem.

I don't know if it's related with your problem, but I think there's
something to improve here, I'm not sure yet what is best way to handle
this ? 

May be a new setting to ignore permission can be useful, which can be
set differently on different checkout.


Regards,

-- 
Martin G.
___
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 amend comment

[Martin Gagnon]

Hi Arnold, 

On Sat, Nov 26, 2016 at 01:15:11PM +0100, arnoldemu wrote:
> Hi,
> 
> I submitted a change and made a mistake in the comment.
> I wanted to change the comment and fix it.
> 
> I did this:
> 
> fossil amend ba67fcd67c -m "fixed snapshot"
> 
> command reported the comment, tags and uuid.
> 
> fossil changes showed nothing.

Normal, the amend command works directly on the repository, not on the
checkout. So it's true that nothing have change on your checkout.

> 
> I looked at the server and there was no changes.
But on your local repository, if you do "fossil ui" or "fossil
timeline", you will see the changes.

> 
> I forced a submit with
> 
> fossil commit --allow-empty
> 
> and it appears to have worked.

Server get the change here, because the "commit" command does a "sync"
when autosync is enable (which is the default). 

> 
> I wish "fossil changes" would list this change (and changes like
> changing file type) because it's confusing that some changes are
> listed and some are not.
> I should then just be able to submit without forcing. The way I see it
> is I did make a change, so it should be listed and the commit is not
> empty.
> 

The command you should have done to send this change to the server is
"fossil sync" or "fossil push".

I agree that it can be confusing that the "amend" command doesn't
listen to the "autosync" setting, like "commit". But it would have been
the same if you had edited the comment from web interface using 
"fossil ui". I'm not sure if I want my "fossil ui" edit's to
automatically call sync. Especially when the edits is done in many
steps. I feel a little bit the same about the amend command.

Someone else have any thought about this ?

-- 
Martin G.
___
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] private branches

[Martin Gagnon]

Hi Scott,

On Mon, Nov 21, 2016 at 08:47:22PM -0800, Scott Doctor wrote:
> Reading through the fossil documentation about private branches. It
> states that There is no way to convert a private branch into a
> public branch. But all of the changes associated with the private
> branch are folded into the public branch and are hence visible to
> other users of the project.

Private branch use to be very limited in functionality. If I remember
well, it was possible to convert all the private branches at once, but
not a single branch.

But since the addition of the "bundle" functionality, it's now possible
to convert a private branch into a public branch easily using the
"publish" command.

see http://fossil-scm.org/index.html/help?cmd=publish

   [snip]


Regards

-- 
Martin G.
___
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] OpenSSL in the source tree

[Martin Gagnon]

On Wed, Nov 02, 2016 at 02:18:50AM -0400, Adam Jensen wrote:
> When compiling on CentOS-7, 'configure --with-openssl=auto' doesn't find
> what is needed. How can OpenSSL or LibreSSL source be placed in the
> 'fossil/compat' directory such that 'configure --with-openssl=tree' will
> work? I've tried both:
> 
> tar xzf openssl-1.1.0b.tar.gz -C ~/build/fossil/compat/
> cd ~/build/fossil/compat/
> mv openssl-1.1.0b openssl
>

Hi Adam, 

If you want to use openssl from your distro, you need to install the
development package of openssl.

I think it's "openssl-devel" on CentOS.

I'm not very familiar with CentOS but if you do:

  $ yum install openssl-devel

the configure script *should* find what it needs.


Regards,

-- 
Martin G.
___
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] features I'd like to have in fossil

[Martin Gagnon]

On Tue, Nov 01, 2016 at 01:08:47AM -0400, Ron W wrote:
>At the risk of wading in to a minefield, I have some thoughts.
>On Fri, Oct 21, 2016 at 2:14 PM,
><[1]fossil-users-requ...@lists.fossil-scm.org> wrote:
> 
>  From: Nikita Borodikhin <[2]elit...@gmail.com>
>  Date: Fri, 21 Oct 2016 16:02:33 +
> 
>  == combined log - history ananlysis ==
> 
>  The most unusual thing about Fossil is that it does not have "log"
>  command.  [...]  In Fossil, there is no easy command line way to get
>  the history of a subtree.

Fossil already have this, like at the "-p" option of the timeline
command.

  $ fossil timeline -p subdir/
 or
  $ fossil timeline -p .


  


-- 
Martin G.
___
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] export.c fail with MSVC

[Martin Gagnon]

On Fri, Oct 28, 2016 at 03:18:04PM -0700, jungle Boogie wrote:
> Hi All,
> 
> In my adventure to build fossil on windows with MSVC 2010, I
> encountered the error below:
> 
> cl /c /nologo /MT /O2  /I. /I..\src /I..\win\include
> /I..\compat\zlib /Fo.\export.obj -c export_.c
> export_.c
> ..\src\export.c(564) : error C2143: syntax error : missing ';' before 'const'
> ..\src\export.c(566) : error C2065: 'zPerm' : undeclared identifier
> ..\src\export.c(566) : warning C4047: '=' : 'int' differs in levels of
> indirection from 'char [7]'
> ..\src\export.c(567) : error C2065: 'zPerm' : undeclared identifier
> ..\src\export.c(567) : warning C4047: '=' : 'int' differs in levels of
> indirection from 'char [7]'
> ..\src\export.c(568) : error C2065: 'zPerm' : undeclared identifier
> ..\src\export.c(568) : warning C4047: '=' : 'int' differs in levels of
> indirection from 'char [7]'
> ..\src\export.c(570) : error C2065: 'zPerm' : undeclared identifier
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 10.0\VC\BIN\cl.EXE"' : return code '0x2'
> Stop.
> 

Should be fix now. (even 2 time since me and mistachkin commit the same
fix in the exact same time.) 

  ** The Fork is probably my fault, my autosync was set to "pullonly"
 and I had to push manually after my commit..

Regards

-- 
Martin G.
___
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] on sha1 as a hash

[Martin Gagnon]

> Le 20 oct. 2016 à 02:57, Luca Ferrari  a écrit :
> 
> On Wed, Oct 19, 2016 at 10:36 AM, Aldo Nicolas Bruno
>  wrote:
>> Better question can be, how fossil manage collisions?
> 
> Just a side note: according to v1.31
>  the repository
> can now show its own collisions, as in
> . As far as I understand
> the collision is simply kept and marked as ambiguos.
> 
> Luca
> 

Those are collisions of sha1 prefix, using different lengths. It has nothing to 
do with a collision of the integral hash.

-- 
Martin G.

___
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] Errors trying to compile

[Martin Gagnon]

I believe you can use the standard ./configure && make  in the Cygwin 
environment. But I never tried it personally. 

-- 
Martin

> Le 12 oct. 2016 à 21:38, Dan Raymond  a écrit :
> 
> Thanks.
> 
> What is best environment etc to compile under windows?
> 
> 
> 
> 
> Level 19 Waterfront Place, 1 Eagle Street Brisbane Qld 4000 Australia
> Mail:   PO Box 7815 Waterfront Place, Brisbane 4001
> Tel:+61 733 600 255
> Mob:  +61 400 551 920
> Fax:   +61 733 600 222
> Web:  http://ecourban.com.au
> 
>> On Thu, Oct 13, 2016 at 11:28 AM, Joe Mistachkin  
>> wrote:
>> 
>> Using that makefile with Cygwin is untested, unlikely to work, and 
>> unsupported.
>> 
>> Sent from my iPhone
>> https://urn.to/r/mistachkin
>> 
>>> On Oct 12, 2016, at 5:55 PM, Dan Raymond  wrote:
>>> 
>>> I am getting the following errors when trying to compile: What do I need to 
>>> do?
>>> 
>>> 
>>> 
>>> $ make -f win/Makefile.mingw
>>>   
>>> gcc -Wall -Os -Lsrc/../compat/zlib -Isrc/../compat/zlib 
>>> -DBROKEN_MINGW_CMDLINE=1 -c
>>>  -o src/../compat/zlib/match.o -DASMV 
>>> src/../compat/zlib/contrib/asm686/match.S
>>> match.S: Assembler messages:
>>>
>>> match.S:94: Error: invalid instruction suffix for `push'
>>>
>>> match.S:96: Error: bad register expression  
>>>
>>> match.S:97: Error: invalid instruction suffix for `push'
>>>
>>> match.S:99: Error: invalid instruction suffix for `push'
>>>
>>> match.S:101: Error: invalid instruction suffix for `push'   
>>>
>>> src/../compat/zlib/contrib/asm686/match.S:348: Error: invalid instruction 
>>> suffix fo
>>> r `pop' 
>>>   
>>> src/../compat/zlib/contrib/asm686/match.S:350: Error: invalid instruction 
>>> suffix fo
>>> r `pop' 
>>>   
>>> src/../compat/zlib/contrib/asm686/match.S:352: Error: invalid instruction 
>>> suffix fo
>>> r `pop' 
>>>   
>>> src/../compat/zlib/contrib/asm686/match.S:354: Error: invalid instruction 
>>> suffix fo
>>> r `pop' 
>>>   
>>> make: *** [win/Makefile.mingw:994: src/../compat/zlib/match.o] Error 1  
>>>
>>> 
>>> 
>>> 
>>> I am, trying to compile under CYGWIN on windows 
>>>  
>>> ___
>>> fossil-users mailing list
>>> fossil-users@lists.fossil-scm.org
>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>> 
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> 
> ___
> fossil-users 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] Files named "AUX" on Windows

[Martin Gagnon]

On Tue, Oct 04, 2016 at 01:40:59PM -0600, Andy Bradford wrote:
> Thus said Richard Hipp on Tue, 04 Oct 2016 12:15:58 -0400:
> 
> > Does anybody know of a reasonable work-around?
> 
> What  do other  VCS do?  Presumably  CVS, SVN,  Hg, Git,  etc. have  all
> Wsupported indows for a long time. Do they just return a sensible error?
> 

I just tried with git, seems not handled very well.

git version:
- Linux (debian 8): git version 1.9.1
- Windows: git version 2.7.4.windows.1 

Here's what I got on windows when cloning a repository from my linux
computer which contain a file named "aux.txt":

- It just clone the repository without showing any errors. 

- The aux.txt file never get created. 

- Command like "git diff" or "git status" tell me that "aux.txt"
  is missing.


- If I modify and commit aux.txt on the linux side. "git pull"
  on windows side tell me that aux.txt has change without
  reporting any errors but the file is still not created.


-- 
Martin G.
___
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] feature requests

[Martin Gagnon]

-- 
Martin
> Le 15 sept. 2016 à 03:45, Aldo Nicolas Bruno  a écrit 
> :
> 
> Il 14/09/2016 21:12, Richard Hipp ha scritto:
>> Anywhere you can put a SHA1 hash prefix for a version name, you can
>> also supply a branch name (which will resolve to the most recent
>> check-in on that branch) or a tag (which will resolved to whatever
>> check-in is tagged with that tag) or "tip" to mean the lastest
>> check-in.  There are other options too, like "trunk:2005-01-17" which
>> means the last checkin on the branch "trunk" before 2005-01-17.
>> 
>>> https://pizzahack.eu/fossil/thunderchez/?ci=trunk=cairo/cairo-functions.ss
>> Whether or not this works for a specific webpage depends on whether or
>> not that webpage lest you specify a version number.  Which webpage did
>> you have in mind?
> 
> By example here I see the source code of cairo/cairo-functions.ss
> 
> https://pizzahack.eu/fossil/thunderchez/artifact/e453a0dfb609ceee459fa2a14ca425f84a3944ee
> 
> I know there exists this link,
> https://pizzahack.eu/fossil/thunderchez/finfo?name=cairo/cairo-functions.ss=trunk
> 
> but I want to directly link to the artifact view like with the link
> above only that I specify the check-in
> 
> and file name instead of artifact id is this possible?
> 

Something like this ?

 
https://pizzahack.eu/fossil/thunderchez/artifact?filename=cairo/cairo-functions.ss=trunk


Hints: For all fossil web pages usage information, (and cli usage). You can go 
on the '/help' page of any fossil repo.

 E.g. https://pizzahack.eu/fossil/thunderchez/help

Regards, 

-- 
Martin G.___
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] Further mailing list configuration changes.

[Martin Gagnon]

> Le 30 juin 2016 à 20:47, Ron W  a écrit :
>  
> 
> 
> As for the From header, a newer version of the Mailman list manager would get 
> us the option to replace just the address in the From header.

  +1

> That would help mitigate the problem that Richard was trying to patch by 
> configuring the list to anonymize posts.
>  
>> but ask them for a poll about future of Fossil (mailing list included) then 
>> many will read, and some people just answer.
> 
> Maybe a poll could be done.
Here's my vote... (My $0,02 CAD)

> 
> 3 options I can think of right now, that I see as options in (a newer) 
> Mailman, are "replace From address", "anonymize" or "do nothing".
> 
> I like "replace From address".

Probably the best and simplest solution. (If there's no issues with  Mailman 
upgrade.)

>   


Regards

-- 
Martin G.___
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] Push to multiple remote urls at once

[Martin Gagnon]

> Le 22 mai 2016 à 07:23, Thomas Levine <_...@thomaslevine.com> a écrit :
> 
> Hi,
> 
> I want to keep two remote backups of my repository. Can I configure
> fossil to push to multiple URLs on "push"?  Or, is there a better way to
> make redundant backups of fossil repositories?
> 
> Tom

You can always make your multiple remote backups  to pull from your main repo.

If you absolutely want to push, you can specify the repo url every times and 
optionally use the "--once" option to don't remember the specified url.

Regards,

-- 
Martin G.
___
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 update --latest not working

[Martin Gagnon]

> Le 8 mars 2016 à 05:23, Stephan Beal  a écrit :
> 
>> On Tue, Mar 8, 2016 at 10:18 AM, John Regehr  wrote:
>> I have an extremely simply use case for fossil: I'm tracking the latest 
>> sqlite sources but I have some modifications in my local repository. Every 
>> few days I run "fossil update --latest".  This usually works, but every 
>> couple of weeks my local repository gets somehow stuck in a state where the 
>> remote changes appear to be pulled from the server, but then they are not 
>> applied to my local sources.  This has happened about 4 times.  When the 
>> problem occurs it is persistent and I need to save my patches off on the 
>> side and re-clone the sqlite archive.
> 
> Please try changing the update to a combination of (pull --verily) and 
> (update --latest). In the past (pull --verily) has helped work around similar 
> problems (AFAIK, the root of that particular problem has never been 
> discovered, but it crops up once in a while on the mailing list.)
> 

Please, before to do that, make a copy of your repository file in that state.

 Just in case someone from this list want it to find the root of the problem 
later.  This problem happens rarely and if I remember it use to be on private 
repository that couldn't be share. 

-- 
Martin G.___
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] ./src/delta.c:231: checksum: Assertion failed

[Martin Gagnon]

> Le 19 févr. 2016 à 20:53, Andy Bradford  a écrit :
> 
> Thus said Warren Young on Fri, 12 Feb 2016 09:45:34 -0700:
> 
>> #5  0x004237f6 in blob_delta_create (pOriginal=> out>, pTarget=0x7fffe330, pDelta=0x7fffe370) at ./src/deltacmd.c:40
> 
> I could be wrong, but those seem like extreme memory addresses...
> 
> Anyone?
> 

This is not usually stack addresses?

-- 
Martin G.
___
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] Compiling and running Fossil on old hardware

[Martin Gagnon]

On Fri, Feb 12, 2016 at 02:37:51PM -0500, Richard Hipp wrote:
> Just an FYI:  I use a circa-2002 iBook for testing SQLite on (32-bit
> big-endian) PPC.  The iBook is loaded with Mac OS 10.2.  20GB hard
> disk and 256MB of RAM.
> 
> Fossil still compiles and runs fine on that old dinosaur.  It syncs up
> with modern servers.  Performance is perky - not blistering fast, but
> fast enough.  A lot faster than gcc!

It seems those old iBook doesn't want to die.

I use a ClamShell iBook Firewire  (366Mhz G3, also big endian) from
1999-2000. It's my backup server where I push all my repositories.

I'm running OpenBSD-5.6 (macppc) and I use a recent OpenBSD on it since
8 years. So my test case is a bit different from yours since I use a
recent operating system with a relatively recent compiler.

Some info..
-
   $ uname -a
 OpenBSD macparrot.my.domain 5.6 GENERIC#0 macppc

   $ gcc -v
 Reading specs from
 /usr/lib/gcc-lib/powerpc-unknown-openbsd5.6/4.2.1/specs
 Target: powerpc-unknown-openbsd5.6
 Configured with: OpenBSD/powerpc system compiler
 Thread model: posix
 gcc version 4.2.1 20070719 

   $ fossil ver
 This is fossil version 1.31 [998af5b2a8] 2015-03-04 00:54:24 UTC
-

I just realize that I'm due to upgrade the OpenBSD and fossil here..

For syncing, it does the job, even for big repositories, but working on
a checkout of my biggest repository is pretty slow.


-- 
Martin G.
___
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] kudos to whoever did the "Blitz" skin

[Martin Gagnon]

On Thu, Jan 07, 2016 at 10:05:13PM +0100, Stephan Beal wrote:
>Hi, Fossilers,
>i was about to ask the list for fancy fossil skin suggestions when i found
>the new(?) "Blitz" skin.
>Kudos to whoever put that together! Very slick :).

Same for me, this skin is pretty neat. I use this skin on all my repos
since day 1 ;).

-- 
Martin G.
___
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] Is fossil export known to be broken?

[Martin Gagnon]

On Sun, Dec 13, 2015 at 02:12:01PM +0100, Piotr Orzechowski wrote:
> I've just looked at release notes for 1.34 and 1.33 and there was no
> straightforward note about need to rebuild repositories. Maybe it would
> be better to add such information to requiring release notes, or maybe
> even fossil would be able to suggest repo rebuilding itself?
> 

After bisecting, I found that this commit:
  http://www.fossil-scm.org/index.html/info/8e44cf6f4df4f9f0

Fix the problem. 

Since this fix is about mlink table and not on the export command
directly, updating fossil is not enought to solve the problem, but it
require a rebuild.

Probably a note could be added to the 1.34 release notes.

regards,

-- 
Martin G.
___
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] Is fossil export known to be broken?

[Martin Gagnon]

On Sat, Dec 12, 2015 at 02:47:59PM +, org.fossil-scm.fossil-us...@io7m.com 
wrote:
> On 2015-12-12T14:21:19 +
>  wrote:
> > 
> > Ideally, I'd be able to reproduce this with a somewhat smaller
> > repository...
> 
> Surprisingly, this turned out to be easier than expected!
> 
> http://waste.io7m.com/2015/12/12/fossilexport/
> 
> 1. Create fossil repository.
> 2. Add README.txt and commit in trunk.
> 3. Create branch 'b0' and switch to it.
> 4. Add README-b0.txt and commit in b0.
> 5. Switch to trunk.
> 6. Merge and commit 'b0'.
> 
  [snip]
> 
> Importing that results in no README-b0.txt existing in the 'trunk'
> branch of the created git repository.
> 
> I don't understand what's going wrong yet, but at least we now have
> a repro case.
> 

What version of git and fossil are you using ?

I cannot reproduce the problem using your repo case. After the merge,
the README-b0.txt file is present.

Here a script that reproduce your repo case, does it correspond to your
test case ?


regards,

-- 
Martin G.



ff.sh
Description: Bourne shell script
___
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] Is fossil export known to be broken?

[Martin Gagnon]

On Sat, Dec 12, 2015 at 09:18:12PM +, org.fossil-scm.fossil-us...@io7m.com 
wrote:
> On 2015-12-12T16:07:23 -0500
> Martin Gagnon <eme...@gmail.com> wrote:
> > 
> > What version of git and fossil are you using ?
> > 
> > I cannot reproduce the problem using your repo case. After the merge,
> > the README-b0.txt file is present.
> > 
> > Here a script that reproduce your repo case, does it correspond to your
> > test case ?
> 
> Hello!
> 
> $ fossil version
> This is fossil version 1.32 [715f88811a] 2015-05-02 21:11:26 UTC
> 
> $ git version
> git version 2.6.2
> 
> The script you've attached is exactly what I used to create the test
> case. Which versions are you using?

This is fossil version 1.34 [a4889252f1] 2015-12-07 18:19:28 UTC

git version 1.9.1


-- 
Martin G.
___
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] Is fossil export known to be broken?

[Martin Gagnon]

On Sat, Dec 12, 2015 at 10:09:26PM +, org.fossil-scm.fossil-us...@io7m.com 
wrote:
> On 2015-12-12T21:43:49 +
> <org.fossil-scm.fossil-us...@io7m.com> wrote:
> 
> > On 2015-12-12T16:21:14 -0500
> > Martin Gagnon <eme...@gmail.com> wrote:
> > > > 
> > > > The script you've attached is exactly what I used to create the test
> > > > case. Which versions are you using?
> > > 
> > > This is fossil version 1.34 [a4889252f1] 2015-12-07 18:19:28 UTC
> > > 
> > > git version 1.9.1
> 
> Fossil trunk produces an identical fast-import file to the older
> version. Could you verify that the fast-import file that your repo case
> produces is the same as:
> 
>   http://waste.io7m.com/2015/12/12/fossilexport/test.export
> 
> It probably won't be byte-for-byte identical, but I'd assume that the
> "mark" numbers would be the same, in addition to the order and number
> of commits.


For some reason, mine have an extra line at the end that look like this:

M 100644 :10 README-b0.txt

For the rest, it's pretty similar.

Regards,

-- 
Martin G.
___
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?

[Martin Gagnon]

> Le 20 oct. 2015 à 03:45, Jan Nijtmans  a écrit :
> 
> 2015-10-20 9:16 GMT+02:00 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.
> 
> It turns out that the cause of this problem is the following commit:
>
> so I backed it out. My local trunk build doesn't show the problem
> any more.
> 

Yes, this checkin was an attempt to fix another case where a single checkin 
modify files and does a merge in same time. In that case it would not show the 
files from the merge at all. Obviously, the fix was too simplistic.

Here is the discussion in fossil-dev ML where I tried to point out the problem.

https://www.mail-archive.com/fossil-dev@mailinglists.sqlite.org/msg00269.html

-- 
Martin G.

___
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] diff after update

[Martin Gagnon]

On Sat, Sep 12, 2015 at 01:10:28PM +0200, j. van den hoff wrote:
> On Sat, 12 Sep 2015 01:45:28 +0200, Johan Kuuse  wrote:
> 
> >fossil diff -before
> >
> >or
> >
> >fossil diff -before-commit
> 
> typo... I just wanted to propose another name for the requested
> option, and actually I meant "call it `diff --before' or `diff
> --before-update' which I for one would be able to memorize as
> "compute diff of current state vs. state before the preceding
> update". actually, considering the original posters `subject' line,
> one might also look at it the other way round and call it `diff
> --after-update' ;-)
> 
> personally, I find reference to the undo buffer a long way from
> being obvious to someone just using fossil as DVCS (rather than
> someone interested in in the details/internals of `fossil').

It depend what the feature really do. As it is implemented now (if I
understand it well) it make a diff against the undo buffer, doesn't
matter what was the previous command. 

So in that case, I think it should refer to the undo buffer somehow.

What if someone does :
--

  $ fossil update
 ...
  $ fossil stash 

# some hacking...
 
  $ fossil shash pop

  $ fossil diff --before-update(or fossil diff --undo)
--

In this case, it would be confusing if it doesn't really do the
diff with what was on disk before the update. Right now with the 
" fossil diff --undo" , it would make the diff from current file on disk with 
what it
was before the "fossil stash pop" command. 

> 
> >
> >?
> >El 12/9/2015 1:14, "Andy Bradford"  escribió:
> >
> >>Thus said Richard Hipp on Fri, 11 Sep 2015 10:11:30 -0400:
> >>
> >>> "fossil diff --versus-undo" maybe???
> >>
> >>What if instead of making this a  feature of ``fossil diff'' it became a
> >>feature of ``fossil undo?''
> >>
> >>fossil undo --diff


I think that "fossil diff --from undo" have the advantage to be clear
and represent what the command really does compare to let say:

  fossil undo --diff : might be interpret as it undo something

  fossil diff --undo : is less explicit than --from undo


-- 
Martin G.
___
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] Why Hash

[Martin Gagnon]

On Thu, Sep 10, 2015 at 03:29:24PM +0200, Michal Suchanek wrote:
> On 10 September 2015 at 15:17, j. van den hoff
>  wrote:
> > On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal 
> > wrote:
> >
> >> On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein 
> >> wrote:
> >>
> >>> On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff <
> >>> veedeeh...@googlemail.com> wrote:
> >>>
>  in a breach of promise to myself to never again argue in favour of this
>  functionality on the fossil mailing list (it came up a few times over
>  the
>  last years):
> >>>
> >>>
> >>> If I understand correctly, the way fossil is designed could cause the
> >>> numbers to change *even locally* upon a rebuild, or even just a sync.
> >>> This
> >>> would probably get confusing.
> >>>
> >>
> >> Correct. And if i'm not mistaken, if you rebuild with the --randomize
> >> option then the order could get even weirder.
> >
> >
> > well, I'm only talking about the ordinal numbers chronologically enumerating
> > the timeline checkin(!) entries. this enumeration will not change as a
> > consequence of rebuild, right? it might change after a sync against some
> > remote repo if there are incoming checkins chronologically interleaved with
> > my own, sure, but so what? the relative numbers would be just a (somewhat
> > "volatile") convenience measure _locally_. and I agree with another recent
> > post that this would primarily concern the CLI. what I mean: go ask some hg
> > users when they last did use sha1 hashes for specifying checkins in their
> > interaction with hg (which supports both the ordinals as well as the hashes
> > for doing so) and how often the presence of those numbers confused
> > communication with other developers in their project. I'm quite sure they
> > _never_ specify sha1 hashes to denote checkins in any small to medium-sized
> > project  below 10^4 checkins (currently
> > this still includes fossil itself). not so sure about the "communication"
> > issue if users forget the potentially 'volatile' nature of the relative
> > enumeration, but this just can't possibly be a big issue ...
> >
> > I therefore just maintain it would be "nice to have". it sure ain't a killer
> > feature, I admit ...
> >
> 
> Given that fossil does not support history rewriting by design the
> commit number on a particular branch counting from root is unique and
> stable per branch across all repos.
> 
> If you release from a single master branch you have a monotonous
> snapshot number.
> 
> When you use multiple branches you need to add branch name to have
> stable unique identifier.
> 
> This is not viable eg. for git with rebasing.

Even in fossil it could be a problem, it cannot re-write history but a
branch is just a tag that can change. The identifier will change
after moving checkins on a branch.

-- 
Martin G.
___
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] Why Hash

[Martin Gagnon]

On Thu, Sep 10, 2015 at 08:39:49PM +0300, Baruch Burstein wrote:
>On Thu, Sep 10, 2015 at 8:03 PM, j. van den hoff
><[1]veedeeh...@googlemail.com> wrote:
> 
>  and it really is just irrelevant for the simple envisaged convenience
>  measure: being able to use the ranks instead of the hashes for
>  identifying checkins in _my_ clone when interacting with fossil.
> 
>I am starting to agree. When I used hg, I didn't usually even remember the
>local numbers. I would usually look them up in the timeline of recent
>checkins, and then use them for diffs/branches/rollbacks/whatnot. It was
>just easier than hashes. So the renumbering would not be critical.

I agree, but the only *potential* problem would be when people blindly
use the sequential number when posting links on mailing list or forum.
It  could become confusing when the link point to another valid link,
but not the good one.

-- 
Martin G.
___
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] Files shared (and updated) between repos?

[Martin Gagnon]

On Fri, Aug 21, 2015 at 12:02:46PM +0200, Johan Kuuse wrote:
 Hi,
 
 Everytime I create a new repos, I use a few files which I would like
 to have access to in all my repos:
 
 - README.fossil.new.repo : My own notes about how to setup a new repo.
 - setup-fossil.sh : A script how to setup a new repo automatically.
 - fossil-config.txt: A common configure file I would like to apply to
 all my repos.
 
 I would like to share these files among all my repos, both to access
 them and to update/improve them when needed.
 Anyway, to avoid duplicates of these files, I would preferred to
 update them in one single place, so these files probably should be
 stored in their own repos, what I would called a shared repos.
 Is there a way to achieve this? Or otherwise, any other solutions or 
 workaround?
 

Hi, 

I'm not sure to understand what you mean by shared repos, but here
different things you can do. 

- Links in home page on each of your repos:

If you want to have access to those file from each repo web
interface (home page, wiki or embedded documentation). Just keep
those file you talk about in it's own repository like you said
and have a link that refer to it. 

This is useful for your documentation files, your script file
can be there as reference but you don't have it on your
checkout. 


- Open nested repository:
-
If you want something a little bit like git submodule where
you can see the files of this shared repo in the checkout of
all your repos, you could open this shared repo in a subdirectory of
your other repo checkout by doing: 

fossil open --nested /path/to/shared_repo.fossil

Note that you cannot open a nested repo in the checkout root of
another repo, it must be inside a subdirectory.

But this require that you open the shared repo manually and
since this repo seems to hold documentation, I don't see the
advantage of doing this over having a completely separate
checkout of a separate repo somewhere else in your filesystem.

I sometime use --nested option when I have some generic code
I share between different projects. I use a kind of bootstrap
script on the root of each repo. This script is responsible of
doing the necessary clone/open of my shared repos in the right
subdirectory. That way my different repo can use different
version or branch of the shared repo, useful when the shared
repo is in active development and I don't want to care much
about breaking compatibly on older projects that use it.

Hope this help.

-- 
Martin G.
___
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] bring back a deleted file; unsure of command syntax

[Martin Gagnon]

On Fri, Aug 14, 2015 at 10:20:24PM +0200, arnoldemu wrote:
 Hi,
 
 I did a merge, merging trunk into my sound branch. I submitted it
 and then I noticed that merge had caused fossil to delete some files
 (the files were in the sound branch but not in trunk).
 
 How can I go back to the previous revision of a specific file to
 restore it?
 
 on sound branch [3fc31bf75c] is previous and [66c97725ba] is new.
 
 in the changes for [66c97725ba] I see this in the fossil ui:
 
 Deleted src/arngui/BitmapFont.cpp version [128443f62f]. 
 
 How do I bring this file back?
 

From the root of your checkout that is on sound branch:

fossil up 3fc31bf75c src/arngui/BitmapFont.cpp

   or if you prefer

cd src/arngui
fossil up 3fc31bf75c BitmapFont.cpp

When you specify a file with fossil up, it doesn't switch your current
checkout the specified version, it just bring version of the file you
ask for. So on next commit, you will have your file back on your sound
branch.

Hope this help..

Regards.

-- 
Martin G.
___
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 set mv-rm-files' throws error no such setting: mv-rm-files in 1.33 [18fc492a95]

[Martin Gagnon]

On Sat, Jun 13, 2015 at 01:32:43PM +0200, j. van den hoff wrote:
 the new `mv-rm-files' setting is not working for me as per subject
 of this mail. what am I missing? do I need to use some compile time
 flag (wouldn't think so ...)?
 
 thx/j
 
 ps: if it matters, I see this on a macosx machine.
 

./configure --with-legacy-mv-rm 

should do the trick.

-- 
Martin G.
___
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] Version 1.33 - /reports failing

[Martin Gagnon]

There was a typo in my example..

But Ross Berteig gave a more clear explanation than this example.

On Tue, Jun 02, 2015 at 02:49:42PM -0400, Martin Gagnon wrote:
 
 
 But here, if I'm not mistaken the problem was more like:
 --
 
 char *g_foo[2] = {NULL, NULL};
 
 char *g_bar[2] = {hello, world};
 
 void foo(char *p)
 {
   g_foo[0] = p[0];  // this point to azView
   g_foo[1] = p[1];  // this point to azView

~~~^~~~ : Here should be g_bar
 }
 
 void foo2()
 {
 // do something with g_foo, which point to azView, which may not exist
 // anymore.
 }
 
 void func(void)
 {
   if (some condition) {
 char *azView[2];
 azView[0] = g_bar[0];
 azView[1] = g_bar[1];
 
 foo(azView);
   }
 
   foo2(); // use g_foo which point to inexistent azView
 }
 

-- 
Martin G.
___
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] Responsive UI?

[Martin Gagnon]

I didn't try the desktop version yet, but the mobile version is pretty
neat...

-- 
Martin G.

Le samedi 30 mai 2015, John Found johnfo...@asm32.info a écrit :

 It is wonderful! Simple and stylish.

 On Sat, 30 May 2015 14:05:35 -0300
 Camilo Polymeris cpolyme...@gmail.com javascript:; wrote:

  Hi,
 
  so been playing around trying to create a responsive skin for fossil-ui:
  https://chiselapp.com/user/polymeris/repository/pureskin/index
 
  The focus is on the ticket system and wiki, since that is the info one
  would be most likely to want to check from mobile.
 
  The results have not been very satisfactory, since the content relies
  heavily on tables, which I have to hack using JS for them to fit into a
  small screen.
 
  If anyone has suggestions or has made similar experiments, I'd appreciate
  your comments.
 
  Regards,
  Camilo


 --
 http://fresh.flatassembler.net
 http://asm32.info
 John Found johnfo...@asm32.info javascript:;
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org javascript:;
 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] workflow question

[Martin Gagnon]

On Wed, May 27, 2015 at 07:25:43AM -0400, Richard Hipp wrote:
 On 5/27/15, j. van den hoff veedeeh...@googlemail.com wrote:
  he wants to ensure that
  students can never mess up trunk, i.e. must technically not be able to
  merge anything into trunk.
 
  ...

 
 The other approach would be to deny push privileges to the students
 and force them to email in bundles that contain their changes, to be
 added back to the trunk administratively by the instructor.  That's a
 lot more work on the instructor's part, but it does guarantee that
 nothing he does not want gets into the trunk.
 

I wonder if it would be a good idea to implement a new feature that
would be half way between per-branch push permission and emailing
bundles ?

Example, we could add a command that would work exactly like a bundle,
(may be 'fossil bundle push' ?) but instead to generate a file locally
and email it, the user could push it to the remote and it could appear
like an attached bundle on the remote repository. That way, the
instructor could publish if he like the changes or purge it he doesn't.

What do you think ?

-- 
Martin G.
___
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] imported from git: a question about performances and about tags

[Martin Gagnon]

On Tue, May 26, 2015 at 06:57:18AM -0400, Richard Hipp wrote:
 On 5/26/15, Luca Ferrari fluca1...@infinito.it wrote:
  In the meantime I've tried to rebuild the repository:
 
  % fossil rebuild /sviluppo/fossil/myrepo.fossil --analyze --vacuum
 
  but it seems to me things are going worst:
 
  % time fossil commit -m ... # 1 file
  New_Version: 0001bcb31d7a9a982f8558e22e897afc648ee5ff
  fossil commit -m   24,43s user 6,36s system 71% cpu 43,103 total
 
 
 How long does this take:
 
 fossil commit --dryrun -f -m 'not a real commit'
 
 What if you first do:
 
fossil setting mtime-changes on
fossil setting repo-cksum off
 

On one of my repo: 
--
repository-size:   2233677824 bytes (2.2GB)
artifact-count:82970 (stored as 59462 full text and 23508 delta
blobs)
artifact-sizes:212412 average, 104499200 max, 17623462140 bytes
(17.6GB) total
compression-ratio: 7:1
check-ins: 941
files: 175842 across all branches
wiki-pages:2 (14 changes)
tickets:   9 (23 changes)
events:0
tag-changes:   39
latest-change: 2015-05-26 10:31:44 - about 0 days ago
project-age:   988 days or approximately 2.71 years.
project-id:20b326b473b08ee3115aeb5005ea65b5cd68e84b
schema-version:2011-04-25 19:50
fossil-version:2015-05-23 11:45:00 [bdc2f11d28] [1.33] (gcc-4.8.2)
sqlite-version:2015-05-20 18:17:19 [2ef4f3a5b1] (3.8.10.2)
database-stats:2181326 pages, 1024 bytes/pg, 4487 free pages, UTF-8, delete 
mode
-

I absolutely have to set mtime-changes on and repo-cksum off on this
repo to be usable.

To have an idea of the cost of repo-cksum, you can run the following
from your checkout.
$ time fossil status --sha1sum

It should take approx the same time as your commit.

To compare timing of what does repo-cksum with something else doing the
equivalent, you can try the following.

From the root of your checkout, using the following script.

repocksum.sh:
-
#!/bin/sh

fossil ls | tr \n \0 | xargs -0 openssl sha1  /dev/null
--

and doing the following:

$ time ./repocksum.sh

I get almost the same result as doing fossil status --sha1sum or a
fossil commit with repo-cksum set to on. 


Regards

-- 
Martin G.
___
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] Linux compilation problem (Ubuntu v14) and is rebuild needed?

[Martin Gagnon]

On Sat, May 23, 2015 at 04:27:31PM +0300, to...@acm.org wrote:
Q1: How do I solve this?  (I have already tried ./configure and didn’t
make any difference)
 
./bld/piechart.o: In function `piechart_render':
./src/piechart.c:176: undefined reference to `sincos'
./src/piechart.c:179: undefined reference to `sincos'
./src/piechart.c:191: undefined reference to `sincos'
collect2: error: ld returned 1 exit status
make: *** [fossil] Error 1

It works for me on ubuntu 14.04LTS. 

Seems that you have a linkage problem (not compilation), look like it
didn't link against libm. On the last line before the error (where you
see a bunch of .o files one after the other. Do you see -lm at the
end ?

 
Q2:  Do I need a rebuild after going to v1.33 from v1.32?
 
May be I'm a bit too parano, but every time I build from source after an
update I do a make clean and a ./configure. 

  $ fossil up
  $ make clean
  $ ./configure
  $ make


-- 
Martin G.
___
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 error fossil knows nothing about: C20131_IR_At7_OpSystem_ProjectFile.fossil

[Martin Gagnon]

May be you can set 'Gary_Gabriel_Dev' as the default user for this repo.

   $ fossil user default Gary_Gabriel_Dev

-- 
Martin G.
(From a mobile: Excuse brevity and top posting.)

Le mercredi 13 mai 2015, Gary_Gabriel gabrielrobert.qu...@googlemail.com
a écrit :

 Hi Warren,

 Thanks for your help and comments.  I tried your tip , and checked the
 user name again, the repo is installed on a PC with another user name.  But
 irregardless of what I tried; Fossil replies with no such user:
 Gary_Gabriel_Dev. The details follow.

  Fossil attempts to guess the correct user name from several environment
 variables: FOSSIL_USER, USER, LOGNAME, then USERNAME, in that order.  The
 first one that succeeds is used.

 If none of these is set correctly with respect to your Fossil user scheme
 (i.e. Fossil users and your local LDAP user names are different) you can
 override this guessing game with the “fossil user default” command.


 I added a new user with the current user name, but the same error(1)
 continues. Here are the console results after adding the new user with a
 current user name.

 First after using your suggestion; Fossil did not recognize the user:
 fossil user default Gary_Gabriel_Dev
 no such user: Gary_Gabriel_Dev

 Now checking to see if the new user entry was successful:
 fossil user list
 Gary Gabriel
 Gary_Gabriel_Dev
 anonymousAnon
 developerDev
 nobody   Nobody
 reader   Reader

 I do not understand the problem. Gary_Gabriel_Dev is the valid PC user
 name and is recognized by fossil user list. However the commit command
 fails and Fossil continues to reply no such user: Gary_Gabriel_Dev. Or-
 Fossil refuses the commit with the comment:
 Cannot figure out who you are!  Consider using the --user
 command line option, setting your USER environment variable,
 or setting a default user with fossil user default USER.


 For completeness I replied to your thoughtful tips.

  It is telling you that there is no file called
 C20131_IR_At7_OpSystem_ProjectFile.fossil in the current directory.


 But the file is there confirmed by fossil ls.


  You probably do not mean to be checking one Fossil repo into another
 Fossil repo anyway.  I’m guessing that you are passing that parameter by
 mistake, thinking that you are telling Fossil which repo to make the
 checkin on.

 If you want to make a checkin on a particular Fossil repo, you need to be
 making that checkin from within the directory where you said

 fossil open /path/to/C20131_IR_At7_OpSystem_ProjectFile.fossil


 Previous to the posted commands; I cd'ed to the correct directory where
 the repo is and checked repo file availability with fossil ls and fossil
 status. The console returned the confirmation of the open repo.

 You probably do not mean to be checking one Fossil repo into another
 Fossil repo anyway. I’m guessing that you are passing that parameter by
 mistake, thinking that you are telling Fossil which repo to make the
 checkin on. You're right. I thought the syntax was right. I have used this
 statement with success, what is the correct syntax?

  I get this error[1] with a commit:
 fossil commit -m 12.05.2015. C20131_IR_At7_OpSystem_ProjectFile.tcl.
 --tag C20131_IR_At7_OpSystem_ProjectFile --allow-empty
 C20131_IR_At7_OpSystem_ProjectFile.fossil


  Do you mean --allow-empty? What change is fossil not seeing? What does
 Fossil say when you try to “fossil diff” that file, or ask “fossil finfo”
 on it?


 Yes- that is the command posted above, assuming the syntax in the commit
 statement is correct. To workaround Fossil's refusal to commit; I made some
 more changes to the source and tried again. But even after the changes;
 Fossil did not detect the changes. But this is secondary to the problem.

  Fossil recognizes --user Gary Gabriel “?

 There is no such flag.


 This Fossil console comment refers to the flag --user.
 Cannot figure out who you are!  Consider using the --user
 command line option, setting your USER environment variable,
 or setting a default user with fossil user default USER.

 I appreciate your time and expertise, and it helped me along.

 - Gary Gabriel
 ___
 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] Two trunks?

[Martin Gagnon]

On Tue, Apr 07, 2015 at 11:19:46PM -0700, Matt Welland wrote:
On Tue, Apr 7, 2015 at 7:14 PM, Andy Bradford
[1]amb-fos...@bradfords.org wrote:
 
  Thus said Piotr Orzechowski on Tue, 07 Apr 2015 19:46:22 +0200:
   If they  can happen  when two  people push  to central  repository one
   after another,  then IMHO they  should be  blocked. Or at  least there
   should be a possibility to enable/disable some kind of lock mechanism.
 
  I wonder just what this means? What part of the sync should be blocked?
 
  If I'm not mistaken, Fossil's design prefers to have the fork than not.
   I agree  that good communication  is essential,  yet I also  think the
   best way is to make software  actively protecting us from making forks
   by accident.
 
  The software already warns users that  a fork is imminent. They have the
  choice to ignore the warning, or not.
 
If only this were true then this discussion would have been over
long ago.  Today I got to hear from a team that had a very near
serious QA escape due to an undetected fork. In my opinion Fossil
needs to either block a push that would result in a fork or on any
and every operation loudly complain about any forks lingering in
the timeline.

What are you supposed to do when you try to push (or pull) and it get
blocked because of a fork ? If there's a fork, it's too late. 

Fork's happens because autosync is off or because some commits was done
while the remote repo was not accessible. When it's not the case, if you
try to commit while you are not in sync with the remote repo, you get a
warning that it might create a FORK and fossil give you chance to do a
*up* before. Then you can figure out if there's some conflict, fix them
if necessary, have a discussion with the other developer if necessary
and commit again.

 
Forks add little value but have a potentially high cost because
they can be so confusing when they happen. To reiterate; An
adequate solution would be on every checkout or update loudly
inform the user that there is a fork in the timeline. A much better
solution is to block a push that creates a fork and inform the user
that they need to fix the fork and push again.

Sometimes, Fork are inevitable. User should understand the concept of a
distributed SCM. Fossil have a nice timeline graph that will show you
the FORK clearly. And the CLI timeline command tell you that there's a
FORK. (by adding *FORK* to the checkin entry):
   
http://www.fossil-scm.org/index.html/info/62b10da0e1fe8ee5fa8b1af9aa35696079bb48ee?txt=1ln=1825+1829


May be it could help if fossil status or fossil change command could
print a warning when the current checkin is part of a fork ?

Regards,

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

Re: [fossil-users] How to fix parallel timeline

[Martin Gagnon]

On Fri, Mar 13, 2015 at 11:53:10AM -0400, Martin Gagnon wrote:
 
 BTW, chiselapp.com still use version 1.25 release. The same problem
 could happens easily when using the Clone Repository option if the
 source repo is created without initial empty check-in. 
 

Sorry.. I just notice that it really use a recent version, it's only
the front end site that seems to be served by a old fossil version.

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

Re: [fossil-users] How to fix parallel timeline

[Martin Gagnon]

On Fri, Mar 13, 2015 at 10:59:26AM +0100, Jan Nijtmans wrote:
 2015-03-13 8:49 GMT+01:00 Stephan Beal sgb...@googlemail.com:
  Richard mentioned earlier that he will remove the no initial commit bits,
  which will (theoretically, at least) eliminate this problem for future
  versions. i would hate to see it go
 
 +1
 
  (not enough to raise a fuss about it),
  but it should never have ever been made the default, to avoid compatibility
  problems like this one. There was a long thread related to this on May 31st,
  2014:
 
  https://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg15871.html
 
 The source of this problem was the (past) assumption in the code that the
 initial commit has rowid=1 and it doesn't contain any files. This bug was
 fixed here (16 months ago, available since fossil 1.28):
   http://fossil-scm.org/index.html/info/6791ad1185f374dc
 
 If the initial commit contains files, Fossil 1.27 doesn't see that, and 
 nothing
 reveals they are really there. Therefore, those files look as they have been
 lost, but they really aren't: just upgrade to Fossil 1.28 or later and the 
 files
 will magically be back again. Therefore I respecfully disagree (based on what
 I read in this thread) with Richard's conclusion that work has been lost
 due to fossil, but David Mason should have the final word on that (the
 DELETE's in David's original story meant that those _unchanged_ files
 were removed from the working copy, but they still were in the
 repository even though they were invisible to the students).
 

BTW, chiselapp.com still use version 1.25 release. The same problem
could happens easily when using the Clone Repository option if the
source repo is created without initial empty check-in. 

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