Re: [fossil-users] Rejected JSON tests

2016-05-31 Thread Kain Abel 
Hi Stephan,

again, I beg your pardon. My work ate all the time.

I've slightly modified your line from the top:
lm@um:~/src/fossil$ gcc -c -pedantic -I./src -Wall -Werror -fPIC
-Wstrict-aliasing -g -Wno-long-long -std=c89 ./src/cson_amalgamation.c
-DFOSSIL_ENABLE_JSON -Og
lm@um:~/src/fossil$ gcc -c -pedantic -I./src -Wall -Werror -fPIC
-Wstrict-aliasing -g -Wno-long-long -std=c89 ./src/cson_amalgamation.c
-DFOSSIL_ENABLE_JSON -O1
lm@um:~/src/fossil$ gcc -c -pedantic -I./src -Wall -Werror -fPIC
-Wstrict-aliasing -g -Wno-long-long -std=c89 ./src/cson_amalgamation.c
-DFOSSIL_ENABLE_JSON -O2
./src/cson_amalgamation.c: In function ‘cson_value_new_integer’:
./src/cson_amalgamation.c:2863:13: error: dereferencing type-punned
pointer will break strict-aliasing rules [-Werror=strict-aliasing]
 *CSON_INT(c) = v;
 ^
cc1: all warnings being treated as errors
lm@um:~/src/fossil$ gcc -c -pedantic -I./src -Wall -Werror -fPIC
-Wstrict-aliasing -g -Wno-long-long -std=c89 ./src/cson_amalgamation.c
-DFOSSIL_ENABLE_JSON -Os
./src/cson_amalgamation.c: In function ‘cson_value_new_integer’:
./src/cson_amalgamation.c:2863:13: error: dereferencing type-punned
pointer will break strict-aliasing rules [-Werror=strict-aliasing]
 *CSON_INT(c) = v;
 ^
cc1: all warnings being treated as errors

The same thing happens with a GCC 4.8 by the switching of the
optimizer flags (or to -std=c99).

lm@um:~/src/fossil$ uname -a
Linux um 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
lm@um:~/src/fossil$ gcc --version
gcc (Ubuntu 5.3.1-14ubuntu2.1) 5.3.1 20160413
lm@um:~/src/fossil$ $ gcc-4.8 --version
gcc-4.8 (Ubuntu 4.8.5-4ubuntu2) 4.8.5

With best regards,
Kain
___
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] Rejected JSON tests

2016-05-31 Thread Kain Abel 
Hi Ross,

sorry for the late reply. My day job ate all the time.

Thanks for the tip.
'apt-get install tcllib' solved the problem.

Best regards and thanks,
Kain

2016-05-27 22:52 GMT+02:00 Ross Berteig :
> The issue here is that you don't have the json package installed in your
> copy of Tcl with which you are running the test harness.
>
> There is a comment in json.test that has the reminder of which json library
> I used. Specifically, I used the one from tcllib, as packaged and delivered
> by ActiveTcl's teacup utility.
>
> https://www.fossil-scm.org/index.html/artifact/65f8333164e4?txt=1=33-38
___
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 cross-contamination between two fossil repositories (and not even talking to server!)

2016-05-31 Thread Ron W 
On Mon, May 30, 2016 at 4:39 PM, John P. Rouillard  wrote:
>
> In message <38334f96-17cf-e32a-e758-2d15ce5fd...@cheshireeng.com>,
> Ross Berteig writes:
> >One of the hooks is "command_hook" which is invoked for every
> >fossil command. That name can raise an error (or call break or
> >continue) to prevent the fossil command from executing.
> >
> >Since the hook is called early, it knows the command name, its
> >arguments, its flags, and not a lot lse.
>
> Well if the hook was executed, I could use it to reject a
> --no-th-hooks, but ironically it would never see it 8-).


On any distributed VCS, hooks are like training wheels. They help the user
follow process, but a determined user can take them off.

I hadn't seen documentation on command_hook, but it does get executed
before the list of files with changes is "calculated" so would have to
(somehow) duplicate that functionality.

However I would expect the server would run the hook on an
> incoming commit.
>
> Hmm, now that I think about it, are all the hooks defined in the
> "transfer"(xfersetup) admin page, so they are only run on the
> client?


I think the receiving server also runs hooks, but I don't know.

I don't see where to configure the command_hook on any of the admin pages,
but I'm using the 1.34 released version, not the latest development version.

>The fossil -no-th-hooks option will skip all hooks for that
> >command.  Depending on what else you do in a hook, that might be
> >more than you wanted.
>
> Yup. The embedded codeword allowed fine grain tuning of the
> checks and also recorded whet the developer requested so s/he was
> accountable for the bypass. If any client can disable hooks on
> the remote central repo without any logging/accountability this
> is all moot.


Hooks can only be disabled locally.

Of course, Fossil will have a record of the commit and who did it. So, you
use an assumption of "bypassed unless proven otherwise".

>>Is there some similar way to inspect the transferred artifacts
> >>and file contents and roll back the commit?
> >
> >Nope. And there can't be. Nothing is transferred until well
> >after the whole collection of artifacts that make up the commit
> >have been created and safely stowed in the local
> >repository. There is no "roll back" from that.
>
> Err, that's unfortunate. I was expecting that the order of operations
> for a commit on the server (or a local repo) would be:
>
>   open connection to client (or in the case of local file access,
> just open the sqlite file)
>

When you run "fossil commit", Fossil is directly updating the database
residing on you PC.

If "auto-sync" is turned on, Fossil will automatically pull from the remote
server before processing the commit, then automatically push to the remote
server after processing the commit, but the commit process itself is local
only.

When a remote Fossil server receives a commit from your local repo, it
could run its own commit hook. I don't know if does. Right now, as best I
can tell, only a post_commit hook is available.

I'm not sure all of the implications and collateral damage of a pre_commit
hook on a receiving server. Fossil's current approach is to block all
pushes from users not authorized to push. (Contributions from those users
can, however, be pulled, in which case, Fossil records both who made te
commit and who pulled the commit.)


>   start transaction in database

[...]

> commit transaction
>

Internally, "fossil commit" does this. It just doesn't have a hook just
before committing the database transaction.

However, on a receiving server, commit processing is much simpler.

Overall it sounds that wrapping tools are required to support
> process and validation with fossil rather than supporting the
> process within fossil.
>

At least for "fossil commit", a workable pending_commit hook could be
implemented. Though there is a complication: any commit that has a "base
line" manifest (as opposed to "delta manifest") will list all "current"
artifacts, not just those changed by the commit, so the hook would also
need a way to get a list of artifacts for just the changed files.
___
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] multiple open leaf on closed branches?

2016-05-31 Thread Luca Ferrari 
On Tue, May 31, 2016 at 2:26 PM, Joerg Sonnenberger  wrote:
> On Tue, May 31, 2016 at 01:50:01PM +0200, Luca Ferrari wrote:
>> So the branch 'feature-installazioni' is closed, and is merged.
>> I'm a little confused.
>
> A merge doesn't automatically close a branch, it must be instructed so.

The commit is marked as merged and the branch is shown in the closed
list, am I missing something?
What could happen if I try to reclose the open leaves?

Luca
___
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] multiple open leaf on closed branches?

2016-05-31 Thread Joerg Sonnenberger 
On Tue, May 31, 2016 at 01:50:01PM +0200, Luca Ferrari wrote:
> So the branch 'feature-installazioni' is closed, and is merged.
> I'm a little confused.

A merge doesn't automatically close a branch, it must be instructed so.

Joerg
___
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] multiple open leaf on closed branches?

2016-05-31 Thread Luca Ferrari 
On Tue, May 31, 2016 at 8:16 AM, Luca Ferrari  wrote:
> WARNING: multiple open leaf check-ins on trunk:
>   (1) 2016-05-30 15:25:09 [fc75337a99] (current)
>   (2) 2015-11-19 14:08:50 [aa9521ccd9]
>   (3) 2015-08-26 08:18:19 [c413c4592a]

I've tried to inspect one of the open leaf:

% fossil leaves -c | grep c413c4592a

and nothing is reported, so apparently this leaf is not closed.
However:

% fossil info  c413c4592a -v
uuid: c413c4592a084187b92b37a0ec000af5b9e09a8f 2015-08-26 08:18:19 UTC
parent:   d0fcfd18f5d1873bbe2175c81119ae8cb0353287 2015-08-25 09:03:40 UTC
merged-into:  f1fba691939b4323ad24771598713861c61c496e 2015-08-26 08:19:45 UTC
tags: TEST_03092015, trunk


% fossil info f1fba691939b4323ad24771598713861c61c496e
uuid: f1fba691939b4323ad24771598713861c61c496e 2015-08-26 08:19:45 UTC
parent:   4ff26c4d0c38dd5ea68cb31d5009249b72843824 2015-08-26 08:16:34 UTC
merged-from:  c413c4592a084187b92b37a0ec000af5b9e09a8f 2015-08-26 08:18:19 UTC
child:504ff067d3af42e5e179a48c61c21e41121b95db 2015-08-26 08:24:37 UTC
tags: feature-installazioni
% fossil branch list -c
...
  feature-installazioni

So the branch 'feature-installazioni' is closed, and is merged.
I'm a little confused.

Luca
___
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] --nosync option for merge, update, checkout when disconnected

2016-05-31 Thread Stephan Beal 
On Tue, May 31, 2016 at 11:14 AM, Scott Robison 
wrote:

> DRH: I suspect you never sleep.
>

fwiw, i have never seen him sleep.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"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

Re: [fossil-users] --nosync option for merge, update, checkout when disconnected

2016-05-31 Thread Scott Robison 
On Mon, May 30, 2016 at 2:47 PM, John P. Rouillard  wrote:

> In message

[fossil-users] winsymlink branch

2016-05-31 Thread Scott Robison 
Just an announcement in case anyone is using the winsymlink branch (which
seems unlikely to me).

I've merged the current trunk into winsymlink. The only functionality
exposed in the winsymlink branch, other than what's in trunk, is Windows
symbolic links.

Carry on.

-- 
Scott Robison
___
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] multiple open leaf on closed branches?

2016-05-31 Thread Luca Ferrari 
On Mon, May 30, 2016 at 6:12 PM, Joerg Sonnenberger  wrote:
>> Maybe the LEAF table in the database file is somehow out of sync.
>> Have you tried running "fossil rebuild" to see if that clears the
>> problem?
>
> Or the more light-weight "fossil leaves --recompute" for starters.

Nope!
I've done:

% fossil leaves --recompute
% fossil stat
...
WARNING: multiple open leaf check-ins on trunk:
  (1) 2016-05-30 15:25:09 [fc75337a99] (current)
  (2) 2015-11-19 14:08:50 [aa9521ccd9]
  (3) 2015-08-26 08:18:19 [c413c4592a]

% fossil rebuild
% fossil stat
...
WARNING: multiple open leaf check-ins on trunk:
  (1) 2016-05-30 15:25:09 [fc75337a99] (current)
  (2) 2015-11-19 14:08:50 [aa9521ccd9]
  (3) 2015-08-26 08:18:19 [c413c4592a]


I'm running 1.34 [62dcb00e68].
Am I missing something?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users