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 || iUUID_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
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 to...@acm.org 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?
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 amb-fos...@bradfords.org 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 || iUUID_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] 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] FOSSIL DIFF --TK improvement
On Wed, Sep 10, 2014 at 8:31 AM, Martijn Coppoolse li...@martijn.coppoolse.com wrote: On 9-9-2014 8:28, Stephan Beal wrote: On Tue, Sep 9, 2014 at 8:25 AM, Tony Papadimitriou to...@acm.org 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). The focus on startup issue is known on Windows, maybe it is the same thing on MacOS? http://core.tcl.tk/tk/tktview?name=2817539fff A workaround is to withdraw . and create a new toplevel. If the --tk script did this it would propably work ok on all platforms. /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] Read-only access to files but not history?
Thus said Andy Bradford on 10 Sep 2014 00:26:12 -0600:
As it turns out, this just doesn't seem possible with Fossil
currently. Would there be any interest in something like:
Or how about something like this:
$ f diff
Index: src/login.c
==
--- src/login.c
+++ src/login.c
@@ -795,10 +795,11 @@
const char *zCookie; /* Text of the login cookie */
const char *zIpAddr; /* Raw IP address of the requestor */
char *zRemoteAddr;/* Abbreviated IP address of the requestor */
const char *zCap = 0; /* Capability string */
const char *zPublicPages = 0; /* GLOB patterns of public pages */
+ const char *zPrivatePages = 0;/* GLOB patterns of private pages */
const char *zLogin = 0; /* Login user for credentials */
/* Only run this check once. */
if( g.userUid!=0 ) return;
@@ -963,10 +964,22 @@
** permissions.
*/
zPublicPages = db_get(public-pages,0);
if( zPublicPages!=0 ){
Glob *pGlob = glob_create(zPublicPages);
+if( glob_match(pGlob, PD(REQUEST_URI,no-match)) ){
+ login_set_capabilities(db_get(default-perms,u), 0);
+}
+glob_free(pGlob);
+ }
+ /* If the private-pages glob pattern is defined and REQUEST_URI matches
+ ** one of the globs in private-pages, then also add in all default-perms
+ ** permissions if the user is not nobody.
+ */
+ zPrivatePages = db_get(private-pages,0);
+ if( zPrivatePages!=0 !login_is_nobody() ){
+Glob *pGlob = glob_create(zPrivatePages);
if( glob_match(pGlob, PD(REQUEST_URI,no-match)) ){
login_set_capabilities(db_get(default-perms,u), 0);
}
glob_free(pGlob);
}
This allows me to create users that don't have the the ability to clone
or checkout content but can still view the docs in the globbed
directories and they are required to have a login to see them (nobody is
not allowed):
Andy
--
TAI64 timestamp: 400054100b13
___
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 j...@mistachkin.com: I would appreciate reviews of the following branches for inclusion in trunk: https://www.fossil-scm.org/index.html/timeline?r=xferUuidList One more branch which is ready to be reviewed for inclusion in trunk: http://fossil-scm.org/index.html/timeline?r=multi-thread This branch adds a max-worker-threads setting which enables a new feature in SQLite 3.8.7: Provide the ability for the sorter to start and use auxiliary helper threads in order to increase real-time response.. The default setting is 0, accomplishing the current behavior (no additional worker threads). Whether this really speeds up fossil's real-time response will depend much on the environment, but at least this setting allows to measure it. 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
Re: [fossil-users] possible dynamicTh1Docs or th1ReInit branchinterference - solved
Joe Mistachkin
What are the values of the global Fossil settings matching tcl* and
th1*?
Does the output of fossil all list and fossil all list --ckout make
sense to you?
Hello Joe,
thank you for valuable tips and suggestions. With that I was able to locate
where the problem was.
I had invalid script set in one specific repository in its tcl-setup field.
That way any fossil instance executed on path where its respective _fossil_
file was
located or below it was showing that error.
I have certainly learned something. Especially how easily I can forget about
some leftower configuration while plaing with repo.
One visual clue was that fossil status line in footer stopped to provide TCL
related info.
(I cant recall, where I got it from but it is quite useful)
Thanks
Peter
-- footer revealing TCL info
div class=footer
th1
proc getTclVersion {} {
if {[catch {tclEval info patchlevel} tclVersion] == 0} {
return a href=\http://www.tcl.tk/\;Tcl/a version $tclVersion
}
return
}
proc getVersion { version } {
set length [string length $version]
return [string range $version 1 [expr {$length - 2}]]
}
set version [getVersion $manifest_version]
set tclVersion [getTclVersion]
set fossilUrl http://www.fossil-scm.org
/th1
This page was generated in about
th1puts [expr {([utime]+[stime]+1000)/1000*0.001}]/th1s by
a href=$fossilUrl/Fossil/a
version $release_version $tclVersion
a href=$fossilUrl/index.html/info/$version$manifest_version/a
a
href=$fossilUrl/index.html/timeline?c=$manifest_dateamp;y=ci$manifest_date/a
/div
/body/html
___
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?
On Wed, Sep 10, 2014 at 5:00 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014-09-08 18:50 GMT+02:00 Joe Mistachkin j...@mistachkin.com: I would appreciate reviews of the following branches for inclusion in trunk: https://www.fossil-scm.org/index.html/timeline?r=xferUuidList One more branch which is ready to be reviewed for inclusion in trunk: http://fossil-scm.org/index.html/timeline?r=multi-thread This branch adds a max-worker-threads setting which enables a new feature in SQLite 3.8.7: Provide the ability for the sorter to start and use auxiliary helper threads in order to increase real-time response.. In my measurements, multiple worker threads only provide a performance advantage when you are sorting millions of rows. Which is not something that happens very often in Fossil. On the other hand, there is a performance advantage on *all* operations to disabling mutexes. So my guess is that the patch above makes things slower, not faster. Though, I admit, I have not measured. Have you? -- 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] fossil - JIRA hooks
Does anyone have any experience with hooking up fossil to JIRA? Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] cannot handle R records, use --full-tree error when importing from bzr
I wish to migrate several bzr repos to fossil 1.29, and have gotten stuck at fossil telling me cannot handle R records, use --full-tree trying to import the fast-import dumps. Is there a workaround for this issue? I have seen only one reference to this issue on this ML, from last May, but no solution was offered. What can I do to solve this, short of creating an intermediate git repo? ___ 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] cannot handle R records, use --full-tree error when importing from bzr
On Wed, Sep 10, 2014 at 11:38 AM, Dömötör Gulyás dognot...@gmail.com wrote: I wish to migrate several bzr repos to fossil 1.29, and have gotten stuck at fossil telling me cannot handle R records, use --full-tree trying to import the fast-import dumps. Is there a workaround for this issue? I have seen only one reference to this issue on this ML, from last May, but no solution was offered. What can I do to solve this, short of creating an intermediate git repo? This is the first report of the issue, as far as I am aware. So there is no work-around. If you want to try to hack the Fossil import logic so that it is able to handle R (rename) records, you are welcomed to try. Be warned: The documentation for the fast-import file format is fuzzy, so you'll need to have a number of examples to figure out how it is suppose to work. Probably part of the reason that R records are not currently supported is that we never could figure out their semantics. -- 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] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 9:26 AM, Eric Rubin-Smith eas@gmail.com wrote: Does anyone have any experience with hooking up fossil to JIRA? Do you mean automatic ticket sync between Fossil and an external issue tracking system? Or using an external issue tracking system instead of Fossil's? My generic experience with the latter has been to either use pre and post commit hooks, or create a wrapper around the VCS, to interact with the issue tracking system. FWIW, I originally found Fossil while I was looking for an easy to use, easy to setup issue tracking system that would not require involvement of the IT people. That said, there have been times when it would be nice if I could setup Fossil to receive new tickets from an external system and send updates to those tickets back. I just haven't had the time to truly look into this. Off hand, it looks to me like this could reasonably be accomplished with some combination of the JSON API and the TCL integration. ___ 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 - JIRA hooks
On Wed, Sep 10, 2014 at 6:12 PM, Ron W ronw.m...@gmail.com wrote: like this could reasonably be accomplished with some combination of the JSON API and the TCL integration. And suggestions to either in order to make them usable for such purposes are of course welcomed. :) That said: ticket integration with the JSON API turned out to be a lot more work than anticipated (and thus it is quite castrated) because of the customizability of the ticket subsystem and its close relationship to the scripting world. Thus, i suspect, the TCL/TH1 support might be (out of the box) more use in that area. (And i see no inherent reason why we couldn't generate JSON out of the those worlds, it just has never happened so far.) -- - 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] fossil - JIRA hooks
Ron W wrote: Does anyone have any experience with hooking up fossil to JIRA? Do you mean automatic ticket sync between Fossil and an external issue tracking system? Or using an external issue tracking system instead of Fossil's? I guess I meant the former, though the latter is also interesting if it can be made as nice as Fossil's internal tracker (in the sense that it is easy to drill from the issue down to the check-ins addressing it). My generic experience with the latter has been to either use pre and post commit hooks, or create a wrapper around the VCS, to interact with the issue tracking system. FWIW, I originally found Fossil while I was looking for an easy to use, easy to setup issue tracking system that would not require involvement of the IT people. I'm in the middle of a debate about whether to use Fossil or git+JIRA. If I can hook Fossil up to JIRA then any points about the superiority of JIRA will experience significant erosion. As a separate question along those lines, have people had other sorts of trouble (IT, data sanity or otherwise) with git+JIRA? That said, there have been times when it would be nice if I could setup Fossil to receive new tickets from an external system and send updates to those tickets back. I just haven't had the time to truly look into this. Off hand, it looks to me like this could reasonably be accomplished with some combination of the JSON API and the TCL integration. I guess there are complexities around reconciliation with those simpler approaches. If the external system and Fossil are incommunicado for some period of time (during which they are diverging), then some process will need to have some way of determining the deltas on both sides and doing the sync. The TCL hooks will not suffice for that, unless you extend the scope of what you mean to encompass those full-sync semantics. (This is analogous to the thinking involved in implementing 'fossil sync'.) This in turn will have much to do with the vagaries how to get data into and out from the particular external bug tracker -- JIRA in my case. The tool appears to support a relatively featureful HTTP/REST/JSON API. I guess one of my questions is whether anyone has tried to bite off hooking up a fossil-jira feed using that API yet, whether they experienced any robustness problems or other gotchas in the JIRA API, etc. -- Eric A. Rubin-Smith Aterlo Networks, Inc. http://aterlo.com ___ 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 - JIRA hooks
Stephan Beal wrote: That said: ticket integration with the JSON API turned out to be a lot more work than anticipated (and thus it is quite castrated) because of the customizability of the ticket subsystem and its close relationship to the scripting world. Thus, i suspect, the TCL/TH1 support might be (out of the box) more use in that area. (And i see no inherent reason why we couldn't generate JSON out of the those worlds, it just has never happened so far.) Okay interesting -- thanks for the response. Did you capture any more specific notes or code anywhere that you can point me to? -- Eric A. Rubin-Smith Aterlo Networks, Inc. http://aterlo.com ___ 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 - JIRA hooks
As a separate question along those lines, have people had other sorts of trouble (IT, data sanity or otherwise) with git+JIRA? Sorry to self-reply. I meant for the sense of this question to be constrained specifically to the git-to-JIRA hooks or JIRA itself -- not to git as a stand-alone entity. Fossil devs'/users' criticisms of git in itself are pretty well documented on this forum and elsewhere, and my intention was not to rehash that thinking on this thread. Eric ___ 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 - JIRA hooks
On Wed, Sep 10, 2014 at 12:21 PM, Stephan Beal sgb...@googlemail.com wrote: That said: ticket integration with the JSON API turned out to be a lot more work than anticipated (and thus it is quite castrated) because of the customizability of the ticket subsystem and its close relationship to the scripting world. Thus, i suspect, the TCL/TH1 support might be (out of the box) more use in that area. (And i see no inherent reason why we couldn't generate JSON out of the those worlds, it just has never happened so far.) I'm rather out of date as to what information is available through the various hooks and under what circumstances. Some the messages on this list have only furthered my confusion. But given that an integration with an external issue tracker would, itself, have to be customisable, I am hoping that the JSON API can at least transport the custom fields. If it were also possible to query the descriptions/meta-data of the custom fields, that would be even better. ___ 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 - JIRA hooks
Stephan Beal wrote: In principal, plain old transport is not the problem. The problem (as i recall it, though it's been a while and i've got the memory of a goldfish) was that i could not define a concrete structure for JSON/Ticket I/O because tickets are customizable. Suggestions are of course welcomed, and if there's a concrete case you or Eric have in mind, i can probably say whether it's currently workable or estimate what it would take to make it so. If we assume for a moment that the user is willing to customize the Fossil ticket system to exactly match whatever is needed to integrate with JIRA, does the problem become easy overall? -- Eric A. Rubin-Smith Aterlo Networks, Inc. http://aterlo.com ___ 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 - JIRA hooks
On Wed, Sep 10, 2014 at 6:44 PM, Eric Rubin-Smith eas@gmail.com wrote: If we assume for a moment that the user is willing to customize the Fossil ticket system to exactly match whatever is needed to integrate with JIRA, does the problem become easy overall? To answer that i'd need to know what Jira needs. My use of Jira has been limited to the end-user role - i have NO clue what data it likes to have for inputs. (That said, i quite like Jira, as far as ticket systems go. We get a surprising amount of utility out of the Confluence/Jira combo at my current customer's site.) -- - 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] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 6:35 PM, Ron W ronw.m...@gmail.com wrote: But given that an integration with an external issue tracker would, itself, have to be customisable, I am hoping that the JSON API can at least transport the custom fields. If it were also possible to query the descriptions/meta-data of the custom fields, that would be even better. In principal, plain old transport is not the problem. The problem (as i recall it, though it's been a while and i've got the memory of a goldfish) was that i could not define a concrete structure for JSON/Ticket I/O because tickets are customizable. Suggestions are of course welcomed, and if there's a concrete case you or Eric have in mind, i can probably say whether it's currently workable or estimate what it would take to make it so. -- - 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] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 12:27 PM, Eric Rubin-Smith eas@gmail.com wrote: Ron W wrote: Do you mean automatic ticket sync between Fossil and an external issue tracking system? Or using an external issue tracking system instead of Fossil's? I guess I meant the former, though the latter is also interesting if it can be made as nice as Fossil's internal tracker (in the sense that it is easy to drill from the issue down to the check-ins addressing it). My impression of Jira is that it is designed to be able to integration with most any VCS. Since Fossil commits can be viewed via the web interface, then I would expect this to work nicely. FWIW, I originally found Fossil while I was looking for an easy to use, easy to setup issue tracking system that would not require involvement of the IT people. I'm in the middle of a debate about whether to use Fossil or git+JIRA. If I can hook Fossil up to JIRA then any points about the superiority of JIRA will experience significant erosion. This looks very possible to me. As a separate question along those lines, have people had other sorts of trouble (IT, data sanity or otherwise) with git+JIRA? Our (my team's) concern was/is that IT's ability to cater to the needs of our department are highly variable. IT had one person who was able and willing to handle the needs/wants of software developers (in our case, SW for non-PC devices). Then she moved to another company. They since hired 2 others in succession, each one moving on, only saying that the new offer was better. If we were to use Jira, that would be yet another service to run on IT's servers as the closest we have to a server in our department is the project manager's desk PC. And that is primarily for his convenience in managing issue tickets. Otherwise, we rely on syncing changes peer-to-peer. ___ 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 - JIRA hooks
On Wed, Sep 10, 2014 at 12:44 PM, Eric Rubin-Smith eas@gmail.com wrote: If we assume for a moment that the user is willing to customize the Fossil ticket system to exactly match whatever is needed to integrate with JIRA, does the problem become easy overall? As I understand it, Jira is also customizable, so that would mean 3 places to maintain customizations in sync. ___ 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 - JIRA hooks
On Wed, Sep 10, 2014 at 12:38 PM, Stephan Beal sgb...@googlemail.com wrote: In principal, plain old transport is not the problem. The problem (as i recall it, though it's been a while and i've got the memory of a goldfish) was that i could not define a concrete structure for JSON/Ticket I/O because tickets are customizable. Suggestions are of course welcomed, and if there's a concrete case you or Eric have in mind, i can probably say whether it's currently workable or estimate what it would take to make it so. Is it not possible to define an open-ended list of name-value pairs? More off-hand thinking: A new ticket from Jira (or other) would just be a new ticket request with accompanying field data, including the Jira ID. An update from Jira, I assume the intermediary would need to query Fossil based on the Jira ID, then use the returned Fossil ticket ID to send the updated field data. For updates from Fossil, would need to devise a way to discover the updated tickets (maybe the intermediary keeps track of when it gets updates then queries for tickets changes newer than the time stamp.) ___ 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 - JIRA hooks
On Wed, Sep 10, 2014 at 7:04 PM, Ron W ronw.m...@gmail.com wrote: Is it not possible to define an open-ended list of name-value pairs? i've forgotten the English word (and maybe there isn't one): jein Sure we can, but then we've got a data format nobody can predict, which doesn't sit well with me (at the API level). Projects A and B might both define the custom field foo and give them different semantics: one being a list and one being a free-form text field. The JSON API cannot know what semantics to apply to them, like it can with well-defined (non-custom) fields. More off-hand thinking: A new ticket from Jira (or other) would just be a new ticket request with accompanying field data, including the Jira ID. Which the JSON API has to then understand, and confirm that your customized fossil schema can deal with. That flexibility is a huge burden, in terms of implementation effort, for the JSON bits. Not impossible, just more effort than i ever felt like putting into it (because i so rarely use the ticket system). -- - 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] possible dynamicTh1Docs or th1ReInit branchinterference - solved
Petr Ferdus wrote: One visual clue was that fossil status line in footer stopped to provide TCL related info. (I cant recall, where I got it from but it is quite useful) I actually wrote that. It's part of the Fossil Enhanced Default style footer. -- 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] th1-docs - how to use
I have windows version of fossil build on [c91bafccb5] compiled and enabled
with TH1_DOCS,
TH1_HOOKS and TCL.[1] I run it locally as a server[2]. I am experimenting with
test
repo testtcl.fossil with all tc*, th1* settings allowed and mostly clear[3]
I like to explore TH1_DOCS feature. How can I use it? Which way files will get
interpreted?
My hopes were, that for checked in documents
- th1/tcl scripts/embedded scripts will be interpreted on show of the document
- html file with embedded th1 parts will get interpreted on show of the
document
- I could use baseurl/doc/[tip|ckou]/filename feature to show interpreted
documents
and for not checked in content but located under REPOSITORY directory
- I could browse files (eventually interpret embedded th1) not included in
repo
So far I was able to see interpreted th1[4] file only if it was checked in the
repo
and showed by tip feature (not by ckout). What might block ckout feature?
Html file with embedded th1[5] could be interpreted only if has been
explicitly
marked with mimetype=application/x-th1 otherwise is just displayed.
Tips/examples would be appreciated.
Thanks
Peter
Some tests:
--th1 file [4] get interpreted
http://localhost:8089/soft/bin/testtcl/doc/tip/th_test01.th1
9
211410383005
Wed Sep 10 23:03:25 +0200 2014
--th1 file [4] - not found
http://localhost:8089/soft/bin/testtcl/doc/ckout/th_test01.th1
No such document: th_test01.th1
--th1 file [4]
http://localhost:8089/soft/bin/testtcl/artifact/d2a009c27
[shows content of file uninterpreted]
--th1 file [4]
http://localhost:8080/soft/bin/testtcl/artifact/0819a9d72cb383252063db9fb5b18ae6955eed44
File test_tcl_th1.htm with its content listed, no interpretation
--document [5] with embedded script
http://localhost:8089/soft/bin/testtcl/doc/tip/test_tcl_th1.htm
content uninterpreted
--document [5] with embedded script
http://localhost:8089/soft/bin/testtcl/doc/ckout/test_tcl_th1.htm
No such document: test_tcl_th1.htm
--document [5] with embedded script
http://localhost:8089/soft/bin/testtcl/doc/tip/test_tcl_th1.htm?mimetype=application/x-th1
evaluates th1 script
prints Wed Sep 10 23:26:20 +0200 2014 to the browser window
print directory listing to server console
How to redirect all output into browser windows?
--document [5] with embedded script
http://localhost:8089/soft/bin/testtcl/doc/ckout/test_tcl_th1.htm?mimetype=application/x-th1
No such document: test_tcl_th1.htm
-- file[6] not checked into repository
http://localhost:8089/soft/bin/test_tcl_th1_notchecked.htm
[show content of file uninterpreted]
-- file[6] not checked into repository
http://localhost:8089/soft/bin/test_tcl_th1_notchecked.htm?mimetype=application/x-th1
[show content of file uninterpreted]
---details
[1] used fossil version
fossil.exe ver -v
This is fossil version 1.30 [e7ef2e78ef] 2014-09-10 19:32:29 UTC
Compiled on Sep 10 2014 21:33:57 using mingw32-3.20-gcc-4.8.1 (32-bit)
SQLite 3.8.7 2014-09-01 18:21:27 672e7387b1
Schema version 2011-04-25 19:50
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2-beta3-dev xx XXX )
TH1_DOCS
TH1_HOOKS
TCL (Tcl 8.6.0, loaded TH_OK: 8.6.2)
JSON (API 20120713)
[2] local server instance
fossil.exe server --port 8089 --notfound soft/bin/repodefault.htm
--files-urlenc %27%2A%27 /
[3] test testtcl.fossil repo setings
tcl checked
th1-docs checked
th1-hooks checked
tcl-setup empty
th1-setup empty
th1-uri-regexp * without double quotes
all Transfer scripts empty
[4] th1 document th_test01.th1 checked into repo
th1 set x 9
html br
puts $x
html br
reinitialize 5; # enable reading Tcl setting from global config.
puts [globalState flags]
puts [tclEval {clock seconds}]
html br
puts [tclEval {clock format [clock seconds]}]
html br
/th1
[5] document test_tcl_th1.htm with embedded script, checked into repo
th1
puts [tclEval {clock format [clock seconds]}]
html [puts [ tclEval {
#
# Report all the files and subdirectories in the current directory
# For files: show the size
# For directories: show that they are directories
#
set dirs [glob -nocomplain -type d *]
if { $dirs != {} } {
puts Directories:
foreach d [lsort $dirs] {
puts $d
}
} else {
puts (no subdirectories)
}
set files [glob -nocomplain -type f *]
if { $files != {} } {
puts Files:
foreach f [lsort $files] {
puts [file size $f] - $f
}
} else {
puts (no files)
}
}
]
]
/th1
[6] document test_tcl_th1_notchecked.htm with embedded script,
NOT checked into repo the same content as [5]
___
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] th1-docs - how to use
Petr Ferdus wrote:
What might block ckout feature?
First, you should be aware that enabling the th1-docs setting on a
repository basically
implies that all people with check-in privileges are implicitly trusted.
That is why it
is disabled by default at compile-time and runtime.
If you enable the th1-docs setting and add a *.th1 file into the
repository with
th1/th1 sections contained within it, those scripts will be evaluated
when that
file is rendered via the associated embedded documentation URL, perhaps via
fossil ui,
e.g.:
http://localhost:8080/doc/ckout/example.th1
Contents of example.th1:
th1
set x 9
html br
puts $x
html br
reinitialize 5; # enable reading Tcl setting from global config.
puts [globalState flags]
puts [tclEval {clock seconds}]
html br
puts [tclEval {clock format [clock seconds]}]
html br
/th1
Should produce some interesting output.
Note that the .th1 file in the above example should not actually need to
be checked
in, since ckout may be used to view pending embedded documentation file
changes.
--
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] How to do branching with new major versions
Hi all, I have a question about how to properly use branches in the following scenario: I have version 1.0 of my software, which is stable. Then I want to start developing version 2. Initially I make a version2 branch where all development happens, while at the same time I continue to maintain trunk which is currently version 1. Then, a few months later I decide that the version2 branch is now stable and should officially replace version 1. Version 1 is in trunk as I mentioned, and ideally what I would like to do is switch things around 180 degrees so that we have a version1 branch and trunk reflects version 2 instead. This way I can backport bugfixes done in trunk to the older version1 branch, and eventually close it when version 1 is completely dead. Is this a reasonable approach to the problem, or should I be doing something else? Is it possible to swap branches in the fashion I describe? I notice that SqLite4 is in a totally separate repository from SqLite3. Is that the recommended solution, or can I do what I describe above somehow as well? I'd be grateful for any tips. Kind regards, Philip Bennefall ___ 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 do branching with new major versions
On Wed, Sep 10, 2014 at 7:50 PM, Philip Bennefall phi...@blastbay.com wrote: Hi all, I have a question about how to properly use branches in the following scenario: I have version 1.0 of my software, which is stable. Then I want to start developing version 2. Initially I make a version2 branch where all development happens, while at the same time I continue to maintain trunk which is currently version 1. This is what we do on SQLite: (1) We try to keep the trunk always working. (This helps when doing bisect in later years.) New development goes on feature branches until (a) we know it is going to be merged into a release, and (b) it passes all tests. Then it gets merged into trunk. A recent example of a feature branch is btree-speedup (http://www.sqlite.org/src/timeline?r=btree-speedup). Or changes can be made directly on trunk as long as they pass all tests and do not seem risky or disruptive. As I write this, we are working on three separate feature branchs: user-auth, 64-bit-lengths, and experimental-bulk-update. (2) Release is from trunk. We just --tag a trunk check-in with release and with version-X.Y.Z. We also set --bgcolor 'xd0c0ff' so that releases have a distinct background color. (3) New development after the release continues to go onto trunk (once it passes tests as required by [1] above). If we need to patch a release, then the patches go into a branch rooted at the release. The branch for version-X.Y.Z is named branch-X.Y.Z. Example: http://www.sqlite.org/src/timeline?r=branch-3.8.4 (4) We also maintain a few long-term branches in parallel with trunk. These are versions of SQLite that we have no immediate plans to merge into trunk but need to track trunk. The current long-term branches are apple-osx (containing the slightly-modified code that gets shipped with MacOS and iOS) and sessions. Up unto just recently, we were also maintaining the threads branch, but it has now been merged into trunk. Sometimes we will make a check-in to trunk then later decide it doesn't belong there, so then move it into a branch. (You can do that easily in Fossil.) An example is the btree-speedup changes which started on trunk but got move to a branch. See the timeline at http://www.sqlite.org/src/timeline?c=2014-08-20 and specifically the edit at 13:11 for when the original trunk check-in was moved into the btree-speedup branch. -- 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] How to do branching with new major versions
Thanks, Richard! I really appreciate the detailed response. Many of the practices you describe, I am already following such as tagging each release with both release and the version number. It makes things really easy when going back to fix bugs, answer support queries about the given version etc. The idea about putting patched releases in a new branch based on the original release is neat, too. I will start doing that. Digging around in the Fossil UI I found out how to do exactly what I wanted, as well. I can rename branches easily and I can move check-ins between branches with no difficulty. Thanks once again, for making the system so intuitive! Kind regards, Philip Bennefall P.S. You might be interested to know that Fossil has one of the most accessible web interfaces for blind/visually impaired users with screen reading software, out of all the version control systems I have used. On 9/11/2014 2:12 AM, Richard Hipp wrote: On Wed, Sep 10, 2014 at 7:50 PM, Philip Bennefall phi...@blastbay.com mailto:phi...@blastbay.com wrote: Hi all, I have a question about how to properly use branches in the following scenario: I have version 1.0 of my software, which is stable. Then I want to start developing version 2. Initially I make a version2 branch where all development happens, while at the same time I continue to maintain trunk which is currently version 1. This is what we do on SQLite: (1) We try to keep the trunk always working. (This helps when doing bisect in later years.) New development goes on feature branches until (a) we know it is going to be merged into a release, and (b) it passes all tests. Then it gets merged into trunk. A recent example of a feature branch is btree-speedup (http://www.sqlite.org/src/timeline?r=btree-speedup). Or changes can be made directly on trunk as long as they pass all tests and do not seem risky or disruptive. As I write this, we are working on three separate feature branchs: user-auth, 64-bit-lengths, and experimental-bulk-update. (2) Release is from trunk. We just --tag a trunk check-in with release and with version-X.Y.Z. We also set --bgcolor 'xd0c0ff' so that releases have a distinct background color. (3) New development after the release continues to go onto trunk (once it passes tests as required by [1] above). If we need to patch a release, then the patches go into a branch rooted at the release. The branch for version-X.Y.Z is named branch-X.Y.Z. Example: http://www.sqlite.org/src/timeline?r=branch-3.8.4 (4) We also maintain a few long-term branches in parallel with trunk. These are versions of SQLite that we have no immediate plans to merge into trunk but need to track trunk. The current long-term branches are apple-osx (containing the slightly-modified code that gets shipped with MacOS and iOS) and sessions. Up unto just recently, we were also maintaining the threads branch, but it has now been merged into trunk. Sometimes we will make a check-in to trunk then later decide it doesn't belong there, so then move it into a branch. (You can do that easily in Fossil.) An example is the btree-speedup changes which started on trunk but got move to a branch. See the timeline at http://www.sqlite.org/src/timeline?c=2014-08-20 and specifically the edit at 13:11 for when the original trunk check-in was moved into the btree-speedup branch. -- D. Richard Hipp d...@sqlite.org mailto: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] How to do branching with new major versions
On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp d...@sqlite.org wrote: Sometimes we will make a check-in to trunk then later decide it doesn't belong there, so then move it into a branch. ( Isn't this only possible if no further commits have been made on the trunk? I suppose one possible fix if there have been additional commits is to reverse cherrypick out the change but that leaves the timeline without a clear visible trace of the actions. A similar option would be to cherrypick the post-goof commits to a new trunk and rename the goof + downstream commits as branch goof and then close (and maybe hide) it. Do you have a better way to do this? This type of thing has caused some confusion for my team in that when the branch of the current checkout node changes fossil does not inform the user. In the example a user might find themselves mysteriously on branch goof after doing fossil update where previously the branch was trunk. The fix is to run fossil up trunk but that is tribal knowledge and non-obvious. A message from fossil when the branch changes in this scenario would be good IMHO. -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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 do branching with new major versions
On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland estifo...@gmail.com wrote: On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp d...@sqlite.org wrote: Sometimes we will make a check-in to trunk then later decide it doesn't belong there, so then move it into a branch. ( Isn't this only possible if no further commits have been made on the trunk? I suppose one possible fix if there have been additional commits is to reverse cherrypick out the change but that leaves the timeline without a clear visible trace of the actions. A similar option would be to cherrypick the post-goof commits to a new trunk and rename the goof + downstream commits as branch goof and then close (and maybe hide) it. Do you have a better way to do this? On the few cases when this has happened to me, I've moved goof into a new branch (typically mistake) then cherry pick the follow-on check-ins back over to trunk, assuming there are not to many of them. This type of thing has caused some confusion for my team in that when the branch of the current checkout node changes fossil does not inform the user. In the example a user might find themselves mysteriously on branch goof after doing fossil update where previously the branch was trunk. The fix is to run fossil up trunk but that is tribal knowledge and non-obvious. A message from fossil when the branch changes in this scenario would be good IMHO. I have your request. -- 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] How to do branching with new major versions
On Wed, Sep 10, 2014 at 8:47 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland estifo...@gmail.com wrote: On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp d...@sqlite.org wrote: Sometimes we will make a check-in to trunk then later decide it doesn't belong there, so then move it into a branch. ( Isn't this only possible if no further commits have been made on the trunk? I suppose one possible fix if there have been additional commits is to reverse cherrypick out the change but that leaves the timeline without a clear visible trace of the actions. A similar option would be to cherrypick the post-goof commits to a new trunk and rename the goof + downstream commits as branch goof and then close (and maybe hide) it. Do you have a better way to do this? On the few cases when this has happened to me, I've moved goof into a new branch (typically mistake) then cherry pick the follow-on check-ins back over to trunk, assuming there are not to many of them. On reflection I agree this is a good approach. This type of thing has caused some confusion for my team in that when the branch of the current checkout node changes fossil does not inform the user. In the example a user might find themselves mysteriously on branch goof after doing fossil update where previously the branch was trunk. The fix is to run fossil up trunk but that is tribal knowledge and non-obvious. A message from fossil when the branch changes in this scenario would be good IMHO. I have your request. Thank you for considering it. -- 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 -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Going insane with symlinks
I use symlinks very heavily; I'm trying to convert all my world to fossil, but I can't get symlinks to work. Here's a transcript: : Daves-MacBook-Retina-784 ; ls -l current current/cmf.html lrwxr-xr-x 1 dmason staff 5 Sep 9 22:42 current - f2014 -rwxr-xr-x 1 dmason staff 18391 Sep 3 07:23 current/cmf.html : Daves-MacBook-Retina-784 ; rm -f ~/Fossils/cps313.fossil : Daves-MacBook-Retina-784 ; fs new ~/Fossils/cps313.fossil project-id: 76e0e6ab77d37136593e31eee464516d1ad8f2ec server-id: 680d700b03ea6410deaee53d44bef9b5e1036584 admin-user: dmason (initial password is ec610a) : Daves-MacBook-Retina-784 ; fs open ~/Fossils/cps313.fossil project-name: unnamed repository: /Users/dmason/Fossils/cps313.fossil local-root: /Users/dmason/fs/cps313/ config-db:/Users/dmason/.fossil project-code: 76e0e6ab77d37136593e31eee464516d1ad8f2ec checkout: 8d36cd71d406c10194d9526bc577a5ae895c71a8 2014-09-11 04:34:09 UTC leaf: open tags: trunk comment: initial empty check-in (user: dmason) checkins: 1 : Daves-MacBook-Retina-784 ; fs add .fossil-settings current f2014/cmf.html ADDED .fossil-settings/allow-symlinks ADDED .fossil-settings/binary-glob ADDED .fossil-settings/clean-glob ADDED .fossil-settings/ignore-glob ADDED .fossil-settings/ignore-glob.no-warn ADDED current ADDED f2014/cmf.html : Daves-MacBook-Retina-784 ; cat .fossil-settings/allow-symlinks yes : Daves-MacBook-Retina-784 ; fs ci -m test New_Version: 240dcb9a36ff5fde1c3bc1ae1e906dbb479b3698 : Daves-MacBook-Retina-784 ; cd .. : Daves-MacBook-Retina-784 ; mkdir foo : Daves-MacBook-Retina-784 ; cd foo : Daves-MacBook-Retina-784 ; fs open ~/Fossils/cps313.fossil .fossil-settings/allow-symlinks .fossil-settings/binary-glob .fossil-settings/clean-glob .fossil-settings/ignore-glob .fossil-settings/ignore-glob.no-warn current f2014/cmf.html project-name: unnamed repository: /Users/dmason/Fossils/cps313.fossil local-root: /Users/dmason/fs/foo/ config-db:/Users/dmason/.fossil project-code: 76e0e6ab77d37136593e31eee464516d1ad8f2ec checkout: 240dcb9a36ff5fde1c3bc1ae1e906dbb479b3698 2014-09-11 04:35:14 UTC parent: 8d36cd71d406c10194d9526bc577a5ae895c71a8 2014-09-11 04:34:09 UTC leaf: open tags: trunk comment: test (user: dmason) checkins: 2 : Daves-MacBook-Retina-784 ; ls -l total 8 -rw-r--r-- 1 dmason staff5 Sep 11 00:35 current drwxr-xr-x 3 dmason staff 102 Sep 11 00:35 f2014 --- Note that current isn't a symlink as it should be. I've tried making allow-symlinks have: 1, yes, on but I get the same results in all 3 cases: no symlink What am I doing wrong?!?!?! Thanks ../Dave ___ 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] Going insane with symlinks
Thus said David Mason on Thu, 11 Sep 2014 00:42:09 -0400: : Daves-MacBook-Retina-784 ; cat .fossil-settings/allow-symlinks yes : Daves-MacBook-Retina-784 ; fs ci -m test New_Version: 240dcb9a36ff5fde1c3bc1ae1e906dbb479b3698 I could be wrong, but I don't think the .fossil-settings apply until *after* they have been committed. So, either explicitly set: fossil settings allow-symlinks yes Prior to adding any files/links to your repository. Then add your files and make your commit. After that, the versioned setting will apply (you can remove the setting). Or, instead, commit the .fossil-settings directory before adding any other files/links. Then add your files/links and commit them. Andy -- TAI64 timestamp: 400054112de5 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
