Re: [fossil-users] TH1: string sub-sommands (first, last)

2014-01-15 Thread Joe Mistachkin 

Sergei Gavrikov wrote:
>
> I found some inconsistencies on this (below is a delta for reference).
>

All the issues should be fixed now:


https://www.fossil-scm.org/index.html/vdiff?from=d0d7ca17a46a0832&to=f61958b
183db741b&sbs=1

Thanks again.

--
Joe Mistachkin

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

[fossil-users] fossil import --git --incremental regression?

2014-01-15 Thread Sergei Gavrikov 
Hi

After this http://fossil-scm.org/index.html/info/1aef260f4c check-in I
cannot do incremental import anymore (I get the second dup trunk).  An
imported git project is simple and has 'master' branch only. After that
I did revert this check-in the latest Fossil build does incremental
import for the same git repository great. What a reason could be? Can
anybody confirm this?

Sergei
___
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] Odd permissions issue

2014-01-15 Thread Richard Hipp 
On Wed, Jan 15, 2014 at 11:36 AM, Ron Wilson  wrote:

> On Wed, Jan 15, 2014 at 7:58 AM, Richard Hipp  wrote:
>
>> Under Admin/Access the "Public Pages" entry box allows you to specify a
>> comma-separated list of GLOB patterns for file that will be visible to the
>> public even if the source code access is turned off.  This is used, for
>> example, to make the SQLite Encryption Extension documentation files in the
>> www/ directory visible (
>> http://www.sqlite.org/see/doc/trunk/www/readme.wiki) without making the
>> source code visible to non-licensees.
>>
>
> Just for clarification,I noticed the description of the "Public Pages"
> settings only talks about "anonymous" and not-logged-in users. I assume
> this setting also applies in the case of a "named, logged-in" user who
> otherwise lacks "check out" permission,
>

The "Public Page" GLOB pattern means that any file that matches one of the
patterns (and note that you can identify individual files as part of the
list) can be accessed by anyone as if that person had the permissions
specified in  the "Default privileges" box a little further down the page.

"Anyone" means anyone, logged in or otherwise.



-- 
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

Re: [fossil-users] Odd permissions issue

2014-01-15 Thread Ron Wilson 
On Wed, Jan 15, 2014 at 7:58 AM, Richard Hipp  wrote:

> Under Admin/Access the "Public Pages" entry box allows you to specify a
> comma-separated list of GLOB patterns for file that will be visible to the
> public even if the source code access is turned off.  This is used, for
> example, to make the SQLite Encryption Extension documentation files in the
> www/ directory visible (
> http://www.sqlite.org/see/doc/trunk/www/readme.wiki) without making the
> source code visible to non-licensees.
>

Just for clarification,I noticed the description of the "Public Pages"
settings only talks about "anonymous" and not-logged-in users. I assume
this setting also applies in the case of a "named, logged-in" user who
otherwise lacks "check out" permission,

(I also assume the repository owner should also remove clone permission
from the defaults (at least in 1.27, "nobody" has "g" (clone) permission by
default).)
___
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] Odd permissions issue

2014-01-15 Thread Ron Wilson 
On Wed, Jan 15, 2014 at 8:04 AM, Ron Aaron  wrote:

> Yes, thanks; I know about that, but that's too coarse-grained for my needs.
>
> In this case, I have a project I want to be *non-public* altogether, but
> I also don't want some people to have access to everything, and I can't
> put everything in the wiki.
>

/doc/ is not just for wiki (or markdown) pages, you can put other types of
files there as well.

Also, the "Public Pages" GLOB can potentially specify individual files


>
> On 01/15/2014 02:58 PM, Richard Hipp wrote:
> > Under Admin/Access the "Public Pages" entry box allows you to specify
> > a comma-separated list of GLOB patterns for file that will be visible
> > to the public even if the source code access is turned off.
>
___
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] Odd permissions issue

2014-01-15 Thread Ron Wilson 
On Wed, Jan 15, 2014 at 6:54 AM, Ron Aaron  wrote:

>  As of now, a "reader" has the capabilities "bcfhjkmnoprtw"
>
> I guess you are right about the security difference, but I would like to
> have a more fine-grained ability to allow access to (say) documents in a
> certain folder to "readers", but no access to the source code (or whatever).
>

If you run Fossil as a CGI behind a web server, I think that the URL based
access rules will also work on the path information passed to CGI scripts.
___
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] Odd permissions issue

2014-01-15 Thread Ron Wilson 
On Wed, Jan 15, 2014 at 6:44 AM, Ron Aaron  wrote:

> I set up the "reader" user so that (I thought) it could access things
> needing "read" access.
>
> When I put a link to "./doc/tip..." something on my main repo page, I
> found that having "hyperlinks" permission was not enough, but "check
> out" permission was also required.
>
> Is this correct behavior? It seems odd to me.
>

"check out" permission is read permission for files. There are also read
permission settings for (internal) wiki pages and for tickets, "hyperlink"
"permission" is just whether the links are shown.


In theory, it would make sense for the wiki read permission to apply to
embedded documents accessed via /doc/, but since they are otherwise
"files", they are currently covered by the check out permission.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] TH1: string sub-sommands (first, last)

2014-01-15 Thread Sergei Gavrikov 
FYI

  % fossil test-th-eval "string first match match"
  -1
  % fossil test-th-eval "string last match match"
  -1

Below is a simple test case in Tcl on TH1 string {first,last} sub-commands

  set test {
{string first {} {}}
{string first {needle} {}}
{string first {} {haystack}}
{string first {match} {match}}
{string last {} {}}
{string last {needle} {}}
{string last {} {haystack}}
{string last {match} {match}}
  }
  foreach {expr} $test {
set tcl [eval $expr]
set th1 [exec fossil test-th-eval $expr]
if {$tcl ne $th1} {
  puts "TH1 eval \"$expr\" to $th1 (Tcl expect $tcl)"
}
  }

which outputs

  TH1 eval "string first {} {haystack}" to 0 (Tcl expect -1)
  TH1 eval "string first {match} {match}" to -1 (Tcl expect 0)
  TH1 eval "string last {} {haystack}" to 7 (Tcl expect -1)
  TH1 eval "string last {match} {match}" to -1 (Tcl expect 0)

I found some inconsistencies on this (below is a delta for reference).


Sergei


--- src/th_lang.c
+++ src/th_lang.c
@@ -666,11 +666,15 @@
   zNeedle = argv[2];
   nNeedle = argl[2];
   zHaystack = argv[3];
   nHaystack = argl[3];
 
-  for(i=0; i<(nHaystack-nNeedle); i++){
+  if( !nNeedle || !nHaystack || nNeedle>nHaystack ){
+return Th_SetResultInt(interp, iRes);
+  }
+
+  for(i=0; i<=(nHaystack-nNeedle); i++){
 if( 0==memcmp(zNeedle, &zHaystack[i], nNeedle) ){
   iRes = i;
   break;
 }
   }
@@ -719,19 +723,23 @@
   int nHaystack;
   int i;
   int iRes = -1;
 
   if( argc!=4 ){
-return Th_WrongNumArgs(interp, "string first needle haystack");
+return Th_WrongNumArgs(interp, "string last needle haystack");
   }
 
   zNeedle = argv[2];
   nNeedle = argl[2];
   zHaystack = argv[3];
   nHaystack = argl[3];
 
-  for(i=nHaystack-nNeedle-1; i>=0; i--){
+  if( !nNeedle || !nHaystack || nNeedle>nHaystack ){
+return Th_SetResultInt(interp, iRes);
+  }
+
+  for(i=nHaystack-nNeedle; i>=0; i--){
 if( 0==memcmp(zNeedle, &zHaystack[i], nNeedle) ){
   iRes = i;
   break;
 }
   }

___
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] Odd permissions issue

2014-01-15 Thread Ron Aaron 
Yes, thanks; I know about that, but that's too coarse-grained for my needs.

In this case, I have a project I want to be *non-public* altogether, but
I also don't want some people to have access to everything, and I can't
put everything in the wiki. 

The current permission system works well, but not for this kind of scenario.

On 01/15/2014 02:58 PM, Richard Hipp wrote:
>
>
> Under Admin/Access the "Public Pages" entry box allows you to specify
> a comma-separated list of GLOB patterns for file that will be visible
> to the public even if the source code access is turned off.  This is
> used, for example, to make the SQLite Encryption Extension
> documentation files in the www/ directory visible
> (http://www.sqlite.org/see/doc/trunk/www/readme.wiki) without making
> the source code visible to non-licensees.
>  
> 8080/cgi-bin/mailman/listinfo/fossil-users

-- 
For confidential messages, please use my GnuPG key
http://ronware.org/gpg_key.html




signature.asc
Description: OpenPGP digital signature
___
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] Odd permissions issue

2014-01-15 Thread Richard Hipp 
On Wed, Jan 15, 2014 at 6:54 AM, Ron Aaron  wrote:

>  As of now, a "reader" has the capabilities "bcfhjkmnoprtw"
>
> I guess you are right about the security difference, but I would like to
> have a more fine-grained ability to allow access to (say) documents in a
> certain folder to "readers", but no access to the source code (or whatever).
>

Under Admin/Access the "Public Pages" entry box allows you to specify a
comma-separated list of GLOB patterns for file that will be visible to the
public even if the source code access is turned off.  This is used, for
example, to make the SQLite Encryption Extension documentation files in the
www/ directory visible (http://www.sqlite.org/see/doc/trunk/www/readme.wiki)
without making the source code visible to non-licensees.


>
>
>
> On 01/15/2014 01:50 PM, Richard Hipp wrote:
>
>
>
>
> On Wed, Jan 15, 2014 at 6:44 AM, Ron Aaron  wrote:
>
>> I set up the "reader" user so that (I thought) it could access things
>> needing "read" access.
>>
>
>
>  What are the capability characters you have assigned to "reader".
>
> The "r" and "j" capabilities are for reading tickets and wiki,
> respectively.  For a user to see check-in content, they need "o"
> (check-out).
>
>  There really is no (security) difference between doing a checkout and
> viewing the content in a web page, after all.
>
>
>
>
>
>>
>> When I put a link to "./doc/tip..." something on my main repo page, I
>> found that having "hyperlinks" permission was not enough, but "check
>> out" permission was also required.
>>
>> Is this correct behavior? It seems odd to me.
>>
>> This is with the very latest trunk version of Fossil.
>>
>> Thanks!
>>
>> --
>> For confidential messages, please use my GnuPG key
>> http://ronware.org/gpg_key.html
>>
>>
>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
>
> ___
> fossil-users mailing 
> listfossil-users@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
> --
> For confidential messages, please use my GnuPG 
> keyhttp://ronware.org/gpg_key.html
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
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

Re: [fossil-users] Odd permissions issue

2014-01-15 Thread Ron Aaron 
As of now, a "reader" has the capabilities "bcfhjkmnoprtw"

I guess you are right about the security difference, but I would like to
have a more fine-grained ability to allow access to (say) documents in a
certain folder to "readers", but no access to the source code (or whatever).


On 01/15/2014 01:50 PM, Richard Hipp wrote:
>
>
>
> On Wed, Jan 15, 2014 at 6:44 AM, Ron Aaron  > wrote:
>
> I set up the "reader" user so that (I thought) it could access things
> needing "read" access.
>
>
>
> What are the capability characters you have assigned to "reader".
>
> The "r" and "j" capabilities are for reading tickets and wiki,
> respectively.  For a user to see check-in content, they need "o"
> (check-out).
>
> There really is no (security) difference between doing a checkout and
> viewing the content in a web page, after all.
>
>
>
>  
>
>
> When I put a link to "./doc/tip..." something on my main repo page, I
> found that having "hyperlinks" permission was not enough, but "check
> out" permission was also required.
>
> Is this correct behavior? It seems odd to me.
>
> This is with the very latest trunk version of Fossil.
>
> Thanks!
>
> --
> For confidential messages, please use my GnuPG key
> http://ronware.org/gpg_key.html
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> 
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
>
>
> -- 
> 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

-- 
For confidential messages, please use my GnuPG key
http://ronware.org/gpg_key.html



signature.asc
Description: OpenPGP digital signature
___
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] Odd permissions issue

2014-01-15 Thread Richard Hipp 
On Wed, Jan 15, 2014 at 6:44 AM, Ron Aaron  wrote:

> I set up the "reader" user so that (I thought) it could access things
> needing "read" access.
>


What are the capability characters you have assigned to "reader".

The "r" and "j" capabilities are for reading tickets and wiki,
respectively.  For a user to see check-in content, they need "o"
(check-out).

There really is no (security) difference between doing a checkout and
viewing the content in a web page, after all.





>
> When I put a link to "./doc/tip..." something on my main repo page, I
> found that having "hyperlinks" permission was not enough, but "check
> out" permission was also required.
>
> Is this correct behavior? It seems odd to me.
>
> This is with the very latest trunk version of Fossil.
>
> Thanks!
>
> --
> For confidential messages, please use my GnuPG key
> http://ronware.org/gpg_key.html
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
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

Re: [fossil-users] Database locked, but which?

2014-01-15 Thread Richard Hipp 
On Wed, Jan 15, 2014 at 6:37 AM, Richard Hipp  wrote:

>
>
>
> ...t there is some common cleanup code that runs at the end of any pull or
> push that does the UPDATE command above.  The UPDATE is a no-op in the case
> of a pull, but it runs nevertheless.  Probably we should fix that.
>

Fixed at http://www.fossil-scm.org/fossil/info/b4dffdac5e and recompiled on
the server.  You shouldn't encounter the problem again.


-- 
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] Odd permissions issue

2014-01-15 Thread Ron Aaron 
I set up the "reader" user so that (I thought) it could access things
needing "read" access.

When I put a link to "./doc/tip..." something on my main repo page, I
found that having "hyperlinks" permission was not enough, but "check
out" permission was also required.

Is this correct behavior? It seems odd to me. 

This is with the very latest trunk version of Fossil.

Thanks!

-- 
For confidential messages, please use my GnuPG key
http://ronware.org/gpg_key.html




signature.asc
Description: OpenPGP digital signature
___
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] Database locked, but which?

2014-01-15 Thread Richard Hipp 
On Tue, Jan 14, 2014 at 10:35 PM, Andy Bradford wrote:

> Hello,
>
> While attempting to pull the Fossil repository, I saw this error:
>
> $ fossil up
> Autosync:  https://www.fossil-scm.org/
> Round-trips: 2   Artifacts sent: 0  received: 0
> Error: Database error: database is locked: {UPDATE event SET mtime=(SELECT
> m1 FROM time_fudge WHERE mid=objid) WHERE objid IN (SELECT mid FROM
> time_fudge);}
> Round-trips: 2   Artifacts sent: 0  received: 0
> Pull finished with 1346 bytes sent, 1866 bytes received
> Autosync failed
>

The error came from the server, not your local machine.

You were not doing a push.  But there is some common cleanup code that runs
at the end of any pull or push that does the UPDATE command above.  The
UPDATE is a no-op in the case of a pull, but it runs nevertheless.
Probably we should fix that.


>
> Rerunning the  command was successful. Is  this normal? I have  no other
> fossil command running, so the error must have come from remote.
>
> $ fossil version
> This is fossil version 1.28 [4699f8d919] 2014-01-14 10:43:23 UTC
>
> Thanks,
>
> Andy
> --
> TAI64 timestamp: 400052d60237
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
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