Re: [fossil-users] Read-only access to files but not history?
Thus said Stephan Beal on Wed, 10 Sep 2014 08:38:06 +0200: > A separate (doc-specific) repo? Basically, yeah, but I don't want users to have access to the history of changes (e.g. no timeline, no diffs, etc...), only Wiki and Embedded Docs. And I don't want anonymous users---which means I cannot use the public pages glob feature. Also, I just realized the logic in that diff isn't exactly the best, but it worked at this late hour. :-) Andy -- TAI64 timestamp: 4000540ff3be ___ 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] Read-only access to files but not history?
A separate (doc-specific) repo?
- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity and
typos.
On Sep 10, 2014 8:26 AM, "Andy Bradford" wrote:
> Thus said "Andy Bradford" on 09 Sep 2014 22:22:43 -0600:
>
> > It seems like this should work, but I haven't found the right
> > combination of permissions yet.
>
> As it turns out, this just doesn't seem possible with Fossil currently.
> Would there be any interest in something like:
>
> $ f diff
> Index: src/doc.c
> ==
> --- src/doc.c
> +++ src/doc.c
> @@ -374,11 +374,11 @@
>int i;/* Loop counter */
>Blob filebody;/* Content of the documentation file
> */
>char zBaseline[UUID_SIZE+1]; /* Baseline UUID */
>
>login_check_credentials();
> - if( !g.perm.Read ){ login_needed(); return; }
> + if( !g.perm.Read && !g.perm.RdWiki ){ login_needed(); return; }
>zName = PD("name", "tip/index.wiki");
>for(i=0; zName[i] && zName[i]!='/'; i++){}
>if( zName[i]==0 || i>UUID_SIZE ){
> zName = "index.html";
> goto doc_not_found;
>
>
> Perhaps RdWiki is not the right permission for this (should it be
> separate)? Perhaps /doc is not the right page for this?
>
> Andy
> --
> TAI64 timestamp: 4000540fef27
>
>
> ___
> 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 DIFF --TK improvement
On 9-9-2014 8:28, Stephan Beal wrote: On Tue, Sep 9, 2014 at 8:25 AM, Tony Papadimitriou mailto:to...@acm.org>> wrote: So, I would like to see this improvement, if possible: Once launched, the window to come in front of other windows, and its position to be always centered. FWIW: if this change is made, i'd request that it only be made on Windows. Unix WM's, with "smart window placement," have always done the right thing for me in this regard. I actually have the same gripe (or the first half of it, anyway) on Mac OS X: the diff window always appears in the background. It would be really nice it that could be changed to foreground. The position is OK, however (though I always maximize it). -- Martijn Coppoolse ___ 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] Read-only access to files but not history?
Thus said "Andy Bradford" on 09 Sep 2014 22:22:43 -0600:
> It seems like this should work, but I haven't found the right
> combination of permissions yet.
As it turns out, this just doesn't seem possible with Fossil currently.
Would there be any interest in something like:
$ f diff
Index: src/doc.c
==
--- src/doc.c
+++ src/doc.c
@@ -374,11 +374,11 @@
int i;/* Loop counter */
Blob filebody;/* Content of the documentation file */
char zBaseline[UUID_SIZE+1]; /* Baseline UUID */
login_check_credentials();
- if( !g.perm.Read ){ login_needed(); return; }
+ if( !g.perm.Read && !g.perm.RdWiki ){ login_needed(); return; }
zName = PD("name", "tip/index.wiki");
for(i=0; zName[i] && zName[i]!='/'; i++){}
if( zName[i]==0 || i>UUID_SIZE ){
zName = "index.html";
goto doc_not_found;
Perhaps RdWiki is not the right permission for this (should it be
separate)? Perhaps /doc is not the right page for this?
Andy
--
TAI64 timestamp: 4000540fef27
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Read-only access to files but not history?
Hello, Is it possible to have login with read-only access to documentation pages and Wiki but not view the timeline history? Something similar to how the public pages glob works, but for an authenticated user? It seems like this should work, but I haven't found the right combination of permissions yet. Thanks, Andy -- TAI64 timestamp: 4000540fd236 ___ 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] branch colour (and documentation typo)
On Tue, Sep 9, 2014 at 9:17 PM, Will Parsons wrote: > I have a project in which I've created a number of branches (currently > six). Perhaps by bad luck, three of the branches received quite similar > varieties of blue/green as the background colour, and I'd like to have a > better visual distinction among the branches. I see that one can use > the --branchcolor option when creating the branch, but: > > 1) The documentation says that "The use of the --branchcolor option is >not recommend."* Why not? > Because experience has shown the most users do an awful job of choosing good colors. Better to let the color-based-on-a-hash-of-the-branch-name algorithm do it for you. Even if it sometimes picks colors that are more similar than you would like. Also, the automatic colors will automatically adapt when the page foreground/background changes. Hardcoded --branchcolor colors do not. > > 2) I think the only format for the colour is the hexadecimal >representation, which means it can be difficult to envision what >something like "#aad2c6" will actually look like. Is there a way >to preview how it will look before making the commit? > You can preview the automatically selected colors by entering candidate branch names here: http://www.fossil-scm.org/fossil/hash-color-test I think if you edit the branch color in the UI it gives you a preview before you commit the change. > > * sic - should be "recommended". > Fixed now. -- 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] branch colour (and documentation typo)
I have a project in which I've created a number of branches (currently six). Perhaps by bad luck, three of the branches received quite similar varieties of blue/green as the background colour, and I'd like to have a better visual distinction among the branches. I see that one can use the --branchcolor option when creating the branch, but: 1) The documentation says that "The use of the --branchcolor option is not recommend."* Why not? 2) I think the only format for the colour is the hexadecimal representation, which means it can be difficult to envision what something like "#aad2c6" will actually look like. Is there a way to preview how it will look before making the commit? * sic - should be "recommended". -- Will ___ 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] possible dynamicTh1Docs or th1ReInit branch interference
Petr Ferdus wrote: > > I have several "recent" versions of fossil statically compiled on Windows > with TCL support. The location of init.tcl and other TCL stuff is denoted by > environmental variable TCL_LIBRARY. On my system I set that variable globally > so all command windows have it correctly set now. My expectation is to be able > to execute fossil successfully from any command window, regardless of its > current working directory. > Yes, this should technically "work"; however, it's not the optimal Tcl runtime configuration on Windows. Ideally, you want the script library associated with the binaries to be used. If the directories are laid out correctly, it should automatically detect the necessary "init.tcl". > > For some reason I can't grasp now, since today I can sucessfuly run > fossil ver -v just from SOME directories. For many directories I receive error: > TCL (Tcl 8.6.0, loaded TH_ERROR: no such command: ) > How was Fossil compiled? Are there any custom modifications to it, especially to the Tcl integration subsystem? Can you share the complete output of "fossil version --verbose"? What are the values of the global Fossil settings matching "tcl*" and "th1*"? > > Only relevant change I am aware of was merging dynamicTh1Docs and th1ReInit > branches info my working fossil branch. I might be grossly overlooking > something but at the moment I am puzzled why I can't execute TCL enabled fossil > from any properly configured shell within any working directory. > The changes on those branches should not cause the behavior you are seeing. > > One thing I noted, those shells with "bad" current working directories had some > "_fossil_" file in them or somewhere up the path. > Basically, inside of an "open checkout". Are these directories on a network drive? > > Those "good" shells, were on path with one specific "_fossil_" file up or down > this path OR without any "_fossil_" file anywhere up or down the path. > I'm confused by this. It does not seem to work with the previous statement. Does the output of "fossil all list" and "fossil all list --ckout" make sense to you? -- Joe Mistachkin ___ 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] Comma separated lists
On Tue, Sep 9, 2014 at 6:06 PM, Tomek Kott wrote:
> As per my previous email about checkboxes, I realized that its much easier
> to work with comma delimited lists for what I needed. Here are some
> possibly useful TH1 scripts for checkboxes and comma delimited lists.
>
Thanks for contributing.
> proc list_to_clist l {
> set new_l ""
> for {set i 0} {$i < [llength $l] } {set i [expr $i+1]} {
> set new_l "$new_l[lindex $l $i], "
> }
> return [strip_last_comma $new_l]
> }
>
I think this could be rewritten, assuming TH1's for works like C's for.
proc list_to_clist l {
set new_l [lindex $l $i]
for {set i 1} {$i < [llength $l] } {set i [expr $i+1]} {
set new_l "$new_l, [lindex $l $i]"
}
return $new_l
}
Disclaimer: I'm no expert on TH1 / TCL.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Comma separated lists
As per my previous email about checkboxes, I realized that its much easier to
work with comma delimited lists for what I needed. Here are some possibly
useful TH1 scripts for checkboxes and comma delimited lists. Feel free to bug
me for more info (though I'm on digests, so won't answer right away).
clength and cindex are direct substitutions for llength and lindex that are
built in. I'm sure these could be improved. But they work for me.
proc strip_last_comma clist {
set clist [string range $clist 0 [expr [string length $clist]-3]]
return $clist
}
proc list_to_clist l {
set new_l ""
for {set i 0} {$i < [llength $l] } {set i [expr $i+1]} {
set new_l "$new_l[lindex $l $i], "
}
return [strip_last_comma $new_l]
}
proc clength clist {
if { [string length $clist] == 0 } {return 0}
set count 0
set cfirst 0
for {set i 0} { $i < [string length $clist] } {set i [expr $i+1]} {
set cfirst [string first ", " "$clist"]
if { $cfirst != -1 } {
set clist [string range $clist [expr $cfirst+2] [string length $clist]]
set count [expr $count+1]
} else {
break
}
}
if { $clist ne ", " } {
set count [expr $count+1]
}
return $count
}
proc cindex {clist idx} {
set count 0
set cfirst 0
set cfirst_prev $cfirst
set l($count) ""
for {set i 0} { $i < [string length $clist] } {set i [expr $i+1]} {
set cfirst [string first ", " "$clist"]
if { $cfirst != -1 } {
set l($count) [string range $clist $cfirst_prev [expr $cfirst-1]]
set clist [string range $clist [expr $cfirst+2] [string length $clist]]
set count [expr $count+1]
} else {
break
}
}
if { $clist ne ", " } {
set l($count) $clist
}
if { [info exists l($idx)] } {
return $l($idx)
} else {
return ""
}
}
---
To implement checkboxes:
set tags_regexp [cindex $tags 0]
for {set i 1} {$i < [clength $tags] } {set i [expr $i+1]} {
set tags_regexp "$tags_regexp|[cindex $tags $i]"
}
if
{ [string range $tags_regexp [string length $tags_regexp] [string
length $tags_regexp] ] eq "|" } { set tags_regexp
"$tags_regexp!!" }
if { [string length $tags_regexp] <= 0 } { set tags_regexp "!!"}
html ""
for {set i 0} {$i < [clength $tags_choices] } {set i [expr $i+1]} {
if { [expr $i%2] eq 0 } { html "" }
html "[cindex $tags_choices $i]"
if { [expr $i%2] eq 1 } { html "" }
}
html ""
if { [expr [clength $tags_choices]%2 ] eq 1 } {html "" }
html ""
---
$tags_choices are implemented as follows:
set tags_choices {X
"Y With Space"
ZZ}
--
Hope that helps someone sometime somewhere in the future
Tomek
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] possible dynamicTh1Docs or th1ReInit branch interference
I have several "recent" versions of fossil statically compiled on Windows with TCL support. The location of init.tcl and other TCL stuff is denoted by environmental variable TCL_LIBRARY. On my system I set that variable globally so all command windows have it correctly set now. My expectation is to be able to execute fossil successfully from any command window, regardless of its current working directory. For some reason I can't grasp now, since today I can sucessfuly run fossil ver -v just from SOME directories. For many directories I receive error: TCL (Tcl 8.6.0, loaded TH_ERROR: no such command: ) regardless if TCL_LIBRARY variable is set or not(if I unset TCL_LIBRARY variable in "good" shell, I get above error as well but re-setting TCL_LIBRARY to correct value make it work again) In "good" shells I can run any "recent" versions of fossil just fine. This had happened today. Before that I was able to execute different versions of fossil in shells with different current directories whenever I set proper value to TCL_LIBRARY variable. Only relevant change I am aware of was merging dynamicTh1Docs and th1ReInit branches info my working fossil branch. I might be grossly overlooking something but at the moment I am puzzled why I can't execute TCL enabled fossil from any properly configured shell within any working directory. One thing I noted, those shells with "bad" current working directories had some "_fossil_" file in them or somewhere up the path. Those "good" shells, were on path with one specific "_fossil_" file up or down this path OR without any "_fossil_" file anywhere up or down the path. Any clue? Thanks Peter ___ 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-dev] Several branches ready for trunk?
2014-09-08 18:50 GMT+02:00 Joe Mistachkin : > > I would appreciate reviews of the following branches for inclusion in trunk: > > https://www.fossil-scm.org/index.html/timeline?r=xferUuidList Looks OK to me. One note however: People using the Xfer hook should realize that this hook only fires when a UUID is updated due to an external push (or local pull). Local commits or local ticket edits don't result in this hook being fired (local commits are not expected to happen with "fossil server" but ticket edits through the UI are just normal things to happen) > https://www.fossil-scm.org/index.html/timeline?r=warningFixes Perfectly fine with me. I don't see anything wrong with those fixes Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
