Re: [fossil-users] Meta-enhancement
It does seem a bit strange that we all sell the value of fossil partly because it has a wiki and ticket system built in. but then we don't eat our own dog food. I'm no better on my personal projects... but perhaps RSS can also play a role here. Or if one could subscribe to the email updates for the ticket system and forum, one could monitor what was being discussed, and click in to join the discussion. ../Dave On 26 June 2018 at 14:52, Andy Goth wrote: > On 06/26/18 12:42, Richard Hipp wrote: > >> On 6/26/18, Andy Goth wrote: >> >>> A forum might be nice, but I don't want to have to enhance Fossil >>> just to be able to discuss enhancing Fossil! >>> >> >> Initial prototypes for the forum code are already in the tree. It >> just needs some more work. >> > > I noticed! Thank you. > > The recent email notification enhancements were made in order to >> support ongoing Forum development. >> > > I figured that's why you were doing it, and I thought it was very clever > to recognize that email is useful for more than just forum integration. So > even if forums end up dropped, we'll still have a major benefit for having > made the attempt. > > Patience, grasshopper. >> > > Naturally. But even with forums in place, I think there's benefit to > putting the existing Fossil ticket and wiki systems back in service. > Email/forums, tickets, and wiki individually serve different goals, but > they can be used together to implement a workflow management system. Though > in a sense, wiki is the odd man out. With good email/forums and tickets, > wiki isn't really necessary, but nevertheless wiki is commonly used as an > informal replacement for email/forums and tickets. > > -- > Andy Goth | > > ___ > 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] Checking out the same check-in displays meaningless error
On 6/26/18, Richard Hipp wrote: > it is mostly harmless. In fact, the message comes from fossil_warning() Quite harmless. -- 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] Checking out the same check-in displays meaningless error
On 6/26/18, Dan Barbarito wrote: > Hello everybody, > > I figured I'd share a bug I found on here since tickets by anonymous > users seem to be disabled. I am using the latest code in the trunk > branch and I noticed that if you run "fossil checkout" on the same > check-in twice in a row then you get an error that says "Missed call to > db_end_transaction(). Rolling back." To reproduce, just run "fossil > checkout tip" twice. I have not yet had the chance to try this on the > 2.6 release build of Fossil but I figured I would let you all know that > this is occurring anyway. I added that new error message yesterday, to help ferret out subtle problems. Thanks for the report. But don't stress over the error - though it out to be fixed, it is mostly harmless. -- 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] Checking out the same check-in displays meaningless error
Hello everybody, I figured I'd share a bug I found on here since tickets by anonymous users seem to be disabled. I am using the latest code in the trunk branch and I noticed that if you run "fossil checkout" on the same check-in twice in a row then you get an error that says "Missed call to db_end_transaction(). Rolling back." To reproduce, just run "fossil checkout tip" twice. I have not yet had the chance to try this on the 2.6 release build of Fossil but I figured I would let you all know that this is occurring anyway. Thanks! -- Dan Barbarito Email 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] Markdown in tickets
On 6/26/18, Chad Perrin wrote: > > I am running Fossil v2.5 here: > > $ fossil version > This is fossil version 2.5 [188a0e2904] 2018-02-07 18:48:14 UTC > > I see no Markdown formatting option for tickets when visiting the web UI > via `fossil serve`: Go to /Admin/Tickets and edit the scripts you find there to provide support for markdown. As the scripts already provide support for text/plain, text/html, and text/x-fossil-wiki, it should be apparent how to enhance them with an extra case for text/markdown. Once you get this working, submit your changes for inclusion in the SQLite source tree. -- 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] Markdown in tickets
On Tue, Jun 26, 2018 at 12:05:51PM -0400, Richard Hipp wrote: > On 6/26/18, Andy Goth wrote: > > Is there a reason why Fossil tickets don't allow markdown? The format > > options are wiki, HTML, plain text, and [links only]. > > Markdown as a formatting option can be added by configuration. > > Perhaps you are asking for Markdown support to be added to the default > configuration? I am running Fossil v2.5 here: $ fossil version This is fossil version 2.5 [188a0e2904] 2018-02-07 18:48:14 UTC I see no Markdown formatting option for tickets when visiting the web UI via `fossil serve`: https://i.imgur.com/F3UL8kc.png It only shows Wiki, HTML, Plain Text, and [links only]. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] `unversioned' questions
Le 26/06/2018 à 19:40, Richard Hipp a écrit : On 6/26/18, sky5w...@gmail.com wrote: But now I am confused by this thread? If/When I add unversioned files, are their original paths stripped? Are they stored differently than source code? Unversioned files were created for the purpose of providing a place to store build products when Fossil is used as a server, as you find on the https://fossil-scm.org/fossil/uv/download.html. See https://www.fossil-scm.org/fossil/doc/trunk/www/aboutdownload.wiki for a discussion of how the download page is implemented. Maybe you need three concepts : - History of the file + a copy of each version of the the file - History of the file + a copy of the last version of the file only - Only a copy of the file. -- Stéphane Aulery ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
On Tue, 26 Jun 2018 18:58:42 +0200, Andy Goth
wrote:
I think the next project that needs this feature should write a utility
script for themselves that uses the uv commands to extract files however
makes sense for them. This live experimentation is necessary to figure
what is needed in practice. No one is forced to wait for any changes to
be made to Fossil itself. One day, a set of best practices (i.e., a
vague consensus on which compromises and heuristics most people can live
with most of the time) will emerge, at which point Fossil can adopt them
as useful defaults, but people should always be able to write new
scripts that work best for their specific projects.
On 06/26/18 10:31, Richard Hipp wrote:
My thought was to provide a new setting (perhaps versionable) that
specified a directory relative to the root of the check-out into which
unversioned files are written whenever one does "fossil update" or
"fossil checkout". If the setting is missing or empty, then Fossil
works as it does now. If you turn on the setting, though, then the
unversioned files work just like other files in the check-out, except
that Fossil never records their history.
I overall like the idea, but I can envision an endless stream of feature
creep as people want to do any of the following and more:
- Deal with files having platform-incompatible names (slashes,
backslashes, drive letters, characters unsupported by the filesystem)
- Extract only files within certain size ranges
- Extract only files within certain date ranges
- Extract only files matching certain glob patterns
- Update the unversioned files when checking in
- Get diffs showing which unversioned files have changed
- Handle new files being added to the unversioned directory
- Reverse filename mapping done for platform compatibility when checking
in or adding new unversioned files
- Selectively check in unversioned files along with the rest of the
check-in
And on it goes. All of the above can be done today via shell scripts,
so projects wanting to experiment are invited to get started right away.
I dislike feature creep and endless "please implement this for me"
requests, too. but I don't think this argument applies here, really.
anyway the developer(s) decide what they implement and what not...
from this thread I have learned in the meantime, that uv-files where
intended for something different than what I would have guessed ("created
for the purpose of providing a place to store build products when Fossil
is used as a server") and that uv-files usually(is that right?) are
residing outside of the checkout. so be it. and then I can understand why
fossil does what it does with uv-files (and what it does not, namely
providing a `fsl uv up' command that would do the same with uv-files that
`fsl up' does with versioned files.
all the possible issues with file system /OS issues etc. are sure valid
but to the extent that fossil handles these with versioned files it could
do the same with uv-files (at least as long as their pathnames are
relative to the checkout root).
so my question would be:
is their any strong argument against a `fossil up -u' command? would it be
undesirable to have? (if it really is going to be implemented und whether
drh is willing to invest the time is a different question, naturally.) I
think it would be quite valuable for assorted projects, notably those
depending on large binary files such as jpeg-images (or libs) that are
*project-specific* and prone to multiple changes over the duration of the
project but where tracking changes of these files is not required. I
simply would find it useful to be able to do `fsl up; fsl up -u' (or both
with a single command) in order to bring my checkout including uv-files up
to date...
and yes, I will write a shell or TCL script to do this, if everything else
fails. but it will be inferior to integration of this feature into fossil.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Syntax Highlighting
Recently I had the pleasure of succeeding in enabling syntax highlighting. Even with that success I still found some things that could make the process easier and more robust. One major issue would be that fossil by default inserts the following in the head: This is fairly prohibitive towards trying to get outside resources included so as to allow syntax highlighting. The solution? Download jquery, highlightjs, and a CSS file to the directory that fossil server is serving up and tell it with the "--files" glob pattern to serve those sorts of files. Even so, I understand it's perhaps useful when running as it's own http server during local development but truthfully when ran with say the "--scgi" parameter I'm unsure that it does any good setting things that can be set in headers by the http server that is proxying it. In my case I use nginx and had my own set of CSP headers defined that I use across quite a few different resources. This confused me for a good minute when trying to use a CDN for highlightjs. The next major issue is that the "Artifact Content" pages use "" instead of "". This means that there are quite a few syntax highlighting tools that will absolutely not work. These tools insist on the latter (think prism.js). Luckilly highlightjs doesn't insist. Regardless, even if its "", utilizing "" would be far better. I've looked at the function in "src/info.c" and I also notice one other area where this could be improved if it were to move to "". The function already knows the file name and thereby could ascertain the file's extension quite easily. That said, say the file name is "bla.lua", it could detect the extension "lua", and set the class of the code block to it like "". Having the ability to utilize syntax highlighting would greatly enhance fossil and I'd love to see the previous paragraph's proposal implemented because most syntax highlighting detection engines will be more than horribly incorrect (I've played with highlightjs and have had nothing but incorrect detection). Finaly, I'd love to contribute, and had thought to go ahead and write a probably horrible patch considering I haven't read the entirety of the code base and am ultimately not up to speed with the project from a programming perspective. I saw on the site that a contributors agreement is needed but I also didn't see a way to submit the agreement even if I did fill it out. I at the moment believe someone other than myself could implement this feature correctly and less horribly than I could before I could manage to appropriately submit such an agreement. Even so, I'd like to get a contributors agreement on file so if anyone can help with that. -- Lester L. Martin II ___ 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] Meta-enhancement
On 06/26/18 12:42, Richard Hipp wrote: On 6/26/18, Andy Goth wrote: A forum might be nice, but I don't want to have to enhance Fossil just to be able to discuss enhancing Fossil! Initial prototypes for the forum code are already in the tree. It just needs some more work. I noticed! Thank you. The recent email notification enhancements were made in order to support ongoing Forum development. I figured that's why you were doing it, and I thought it was very clever to recognize that email is useful for more than just forum integration. So even if forums end up dropped, we'll still have a major benefit for having made the attempt. Patience, grasshopper. Naturally. But even with forums in place, I think there's benefit to putting the existing Fossil ticket and wiki systems back in service. Email/forums, tickets, and wiki individually serve different goals, but they can be used together to implement a workflow management system. Though in a sense, wiki is the odd man out. With good email/forums and tickets, wiki isn't really necessary, but nevertheless wiki is commonly used as an informal replacement for email/forums and tickets. -- Andy Goth | ___ 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] Meta-enhancement
On 6/26/18, Andy Goth wrote: > A > forum might be nice, but I don't want to have to enhance Fossil just to > be able to discuss enhancing Fossil! > Initial prototypes for the forum code are already in the tree. It just needs some more work. The recent email notification enhancements were made in order to support ongoing Forum development. Patience, grasshopper. -- 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] `unversioned' questions
On 6/26/18, sky5w...@gmail.com wrote: > But now I am confused by this thread? > If/When I add unversioned files, are their original paths stripped? > Are they stored differently than source code? > Unversioned files were created for the purpose of providing a place to store build products when Fossil is used as a server, as you find on the https://fossil-scm.org/fossil/uv/download.html. See https://www.fossil-scm.org/fossil/doc/trunk/www/aboutdownload.wiki for a discussion of how the download page is implemented. -- 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] email testing - no subscriber table?
On Mon, Jun 25, 2018 at 2:51 PM, Richard Hipp wrote: > On 6/25/18, jungle Boogie wrote: > > If I inadvertently forward my email along > > to someone/group without modifying the footer, the person/group would > > be able to alter my subscription. > > How can I fix that? > > -- > D. Richard Hipp > d...@sqlite.org This is a pretty normal problem with mailing lists, the standard response is to send a confirmation email for subscription and an alert email for unsubscription. The alert email has a one-click resubscribe, so all our Mallory can do here is attempt to subscribe me to an email list, and unsubscribe me such that when I check my email, I find the unsubscription and fix the problem. If someone develops a persistent enemy who finds this form of mild harassment satisfying, you could add a user option "send a confirmation email before unsubscription/any change". For most users that's one step too many, but with that engaged, all that's left is sending spam requesting various changes. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
On 06/26/18 12:10, sky5w...@gmail.com wrote: My repo's were built prior to the unversioned feature, so I have not used this yet. And there is no benefit to migrating my candidate files to unversioned since their history will remain in the repo without complex shunning. But now I am confused by this thread? If/When I add unversioned files, are their original paths stripped? Are they stored differently than source code? ../dev/src/myapp/bla*.c ../dev/src/lib/bla*.c ../dev/img/bla*.png <-- unversioned ../dev/exe/myapp.exe <-- unversioned Do unversioned files remain in their relative paths at inception? Unversioned files just associate a name with contents. There are restrictions on the name. But when you extract, you have to specify where you want to extract to, which can be stdout or an editor program. http://fossil-scm.org/index.html/artifact/d3ad1bea31672b94?ln=689-773 http://fossil-scm.org/index.html/artifact/43ca4a3045902238?ln=296-308 http://fossil-scm.org/index.html/help/uv -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
My repo's were built prior to the unversioned feature, so I have not used this yet. And there is no benefit to migrating my candidate files to unversioned since their history will remain in the repo without complex shunning. But now I am confused by this thread? If/When I add unversioned files, are their original paths stripped? Are they stored differently than source code? ../dev/src/myapp/bla*.c ../dev/src/lib/bla*.c ../dev/img/bla*.png<-- unversioned ../dev/exe/myapp.exe <-- unversioned Do unversioned files remain in their relative paths at inception? On Tue, Jun 26, 2018 at 12:58 PM, Andy Goth wrote: > I think the next project that needs this feature should write a utility > script for themselves that uses the uv commands to extract files however > makes sense for them. This live experimentation is necessary to figure > what is needed in practice. No one is forced to wait for any changes to be > made to Fossil itself. One day, a set of best practices (i.e., a vague > consensus on which compromises and heuristics most people can live with > most of the time) will emerge, at which point Fossil can adopt them as > useful defaults, but people should always be able to write new scripts that > work best for their specific projects. > > On 06/26/18 10:31, Richard Hipp wrote: > >> My thought was to provide a new setting (perhaps versionable) that >> specified a directory relative to the root of the check-out into which >> unversioned files are written whenever one does "fossil update" or >> "fossil checkout". If the setting is missing or empty, then Fossil >> works as it does now. If you turn on the setting, though, then the >> unversioned files work just like other files in the check-out, except >> that Fossil never records their history. >> > > I overall like the idea, but I can envision an endless stream of feature > creep as people want to do any of the following and more: > > - Deal with files having platform-incompatible names (slashes, > backslashes, drive letters, characters unsupported by the filesystem) > - Extract only files within certain size ranges > - Extract only files within certain date ranges > - Extract only files matching certain glob patterns > - Update the unversioned files when checking in > - Get diffs showing which unversioned files have changed > - Handle new files being added to the unversioned directory > - Reverse filename mapping done for platform compatibility when checking > in or adding new unversioned files > - Selectively check in unversioned files along with the rest of the > check-in > > And on it goes. All of the above can be done today via shell scripts, so > projects wanting to experiment are invited to get started right away. > > -- > Andy Goth | > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Meta-enhancement
Over the past several years I've been accumulating a long and growing list of Fossil ideas, enhancement requests, and bug reports, and it's not productive to keep them to myself, especially since it's been ages since I've had enough free time to meaningfully contribute code. But I've also not wanted to flood the list with every little pet project that comes into my head, so keep my ideas to myself is what I've done. I'm considering making a Fossil wiki page to collect it all, but the Fossil wiki is largely inactive and not conducive to discussion. A forum might be nice, but I don't want to have to enhance Fossil just to be able to discuss enhancing Fossil! It might seem the thing to do is create a bunch of tickets so each idea can be tracked, but there haven't been any Fossil ticket changes since the end of 2015, so clearly that's not been the preferred practice. Instead we've done all our discussion via email and have had very little formal development process. But were I to dump all my ideas onto the mailing list, surely most of them would get lost. Tickets are supposed to be the solution to that problem, except it appears we've been ignoring them. My next instinct is to use the Fossil wiki. Create a wiki page that lists the original ideas, gives a summary of their current status, and links to their threads in the mailing list archive. This gives a way to see all ideas quickly, know where they stand, judge them in the context of the other ideas, and drill down to the code and discussion as desired. Reviewing the wiki page list, I see there are not many pages, and most of them cover the same subject: ideas, enhancement requests, bugs. Perhaps the time has come to refactor the wiki and clean up obsolete requests and reports, instead of adding yet another page to an uncurated pile. And yet, keeping that wiki page up-to-date is a manual process that the ticket tracker system is supposed to handle automatically. Furthermore, check-ins can reference tickets more easily and stably than they can wiki pages; just do so on at least the first check-in of each branch as well as on check-ins/merges to trunk. Tickets are also more appropriate than wiki pages for capturing a discussion. But email is better yet, allowing for branching conversations, provided people make correct use of reply so threads stay together. (A forum would be help with that last problem, plus could more easily and permanently be linked to/from other areas of the repository.) Or, do both. All three, really, since I'm biased against any approach that doesn't include email since that's where the lively discussion occurs. The wiki page would index and summarize the ideas and provide links to tickets. Yes, this would be kept up manually, but it would be a little more visible than the current ticket situation. Maybe this is just a transitional phase marking the first step in a cultural shift. We'll see. The tickets would link to mailing list threads, as well as be linked to by check-ins, and would track status, assignment, finer implementation details. The mailing list would be where all the talk happens, all the philosophy about which ideas are worthwhile, how to make them better, who will benefit from them, when to tackle them, who is going to handle them, how they interact with other things, how they will end up being used in practice, and all that free-form stuff that would clog a wiki and would never fit in the rigid linear structure of a ticket. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
I think the next project that needs this feature should write a utility script for themselves that uses the uv commands to extract files however makes sense for them. This live experimentation is necessary to figure what is needed in practice. No one is forced to wait for any changes to be made to Fossil itself. One day, a set of best practices (i.e., a vague consensus on which compromises and heuristics most people can live with most of the time) will emerge, at which point Fossil can adopt them as useful defaults, but people should always be able to write new scripts that work best for their specific projects. On 06/26/18 10:31, Richard Hipp wrote: My thought was to provide a new setting (perhaps versionable) that specified a directory relative to the root of the check-out into which unversioned files are written whenever one does "fossil update" or "fossil checkout". If the setting is missing or empty, then Fossil works as it does now. If you turn on the setting, though, then the unversioned files work just like other files in the check-out, except that Fossil never records their history. I overall like the idea, but I can envision an endless stream of feature creep as people want to do any of the following and more: - Deal with files having platform-incompatible names (slashes, backslashes, drive letters, characters unsupported by the filesystem) - Extract only files within certain size ranges - Extract only files within certain date ranges - Extract only files matching certain glob patterns - Update the unversioned files when checking in - Get diffs showing which unversioned files have changed - Handle new files being added to the unversioned directory - Reverse filename mapping done for platform compatibility when checking in or adding new unversioned files - Selectively check in unversioned files along with the rest of the check-in And on it goes. All of the above can be done today via shell scripts, so projects wanting to experiment are invited to get started right away. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
On Tue, 26 Jun 2018 18:33:22 +0200, Stephan Beal wrote: On Tue, Jun 26, 2018 at 5:45 PM wrote: Can unversioned files respect their original paths when added? I have several locations for bitmaps, icons, pdf's, etc. They do not necessarily reside in an isolated folder. yes, same here, *but* in directories *within* the checkout dir. That wouldn't work cross-platform. You might store file the C:\D\e\f.txt which i could not extract on Unix because we don't have drive letters. If we ignore the C: part, i still couldn't extract to /D/e/f.txt, unless i was the root user. Case sensitivity is another problem in that regard. If you store C:\D\e.txt and C:\d\e.txt, those would map to two different folders on Unix systems. Likewise, Unix /a/b/c.txt has no direct mapping on Windows (which drive should it use?). I was only thinking about *relative* pathnames w.r.t. checkout root and that sure could be managed with the same logic cross-plattform as versioned files, right? but as explained, I have not used uv-files until today (and have not followed the discussion closely, when it was implemented). so I do not know all the use cases that are of relevance here. I now -- in view of your mail -- understand of course that there could be use cases (possibly the majority) where uv-files are located somewhere else in the file tree, rather than in the checkout. no idea how these should be properly handled, than. probably the way DRH just proposed would than be the only way. o.t.o.h.: the special case, where *everything* (versioned and unversioned files) reside together in the checkout dir might deserve special consideration/handling. it seems to me the "logical" extension/next step beyond "put everything under revision control": still keep all the stuff that constitutes "the project" together in one place (the checkout dir), but decide which files could be handled as uv-files in order to safe on disk space/repo size. this would imply special handling of the case "`fossil uv ls'" reports relative, rather than absolute pathnames" but maybe it could be quite useful, just think of my simple example: a LaTeX doc including several project-specific image files that I do not want to keep under revision control but as part of the repo. the tex-file will no longer compile on "the other side" if the uv-files are not put back into the expected (relative) location... -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Markdown in tickets
On 06/26/18 11:05, Richard Hipp wrote: On 6/26/18, Andy Goth wrote: Is there a reason why Fossil tickets don't allow markdown? The format options are wiki, HTML, plain text, and [links only]. Markdown as a formatting option can be added by configuration. I apologize, I was unclear. When I was talking about Fossil tickets, I was referring specifically to Fossil's own tickets, rather than tickets in general. Right now I can't use Markdown when writing a ticket (or comment thereto) against Fossil itself. Perhaps you are asking for Markdown support to be added to the default configuration? I don't see a reason to disable it by default. -- Andy Goth | ___ 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] Email notifications content transfer encoding
Hi, On 2018-06-26 at 09:35 -0400 Richard Hipp wrote: >Since Rafal's original inquiry, I have modified the email notification >logic to use quoted-printable instead of base64. Quoted-printable is >not as clean as plain-old 8bit, but it is much more readable than >base64. Acceptable compromise? For me it's perfectly acceptable compromise. I'd like to note however, that for non-latin based alphabets QP has much higher overhead than base64 and is exactly as non-readable. But for latin-based ones it's "good enough" and that's what I'm interested in ;-). Thank you. >On 6/26/18, Rafal Bisingier wrote: >> Hi >> >> Richard asked me to post it on the list for discussion, so here it is: >> The new email notification functionality in fossil use base64 as >> Content-Transfer-Encoding. I personally prefer use of 8bit encoding, >> which have a side-effect of human-readable source of message. I admit >> that it does not matter much in a normal situation (reading the message >> in an email client), but on a few occasions I had to grep/cat through >> mailbox files, and having a readable message body was of great help >> then. That's why I want to submit for consideration using a 8bit >> content transfer encoding for email notifications. Nowadays there are >> practically no problems in transport of such messages. The only down >> side I could think of is that theoretically there is a limit of 1000 >> chars in a line in an email message (and base64 encoding bypasses it). >> But would it really be a bigger problem? >> On the pros there is simplified debugging (no need to decode message, >> which fossil store in his database file in "transport-ready" form - >> so currently with base64 encoded body). Of course DRH already wrote a >> tool to help in this ;-) so it is already doable without much trouble >> https://www.fossil-scm.org/fossil/file/tools/decode-email.c >> Nevertheless I'd like to have a readable source of messages. ;-) -- Greetings Rafal Bisingier ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
On Tue, Jun 26, 2018 at 5:45 PM wrote: > Can unversioned files respect their original paths when added? > I have several locations for bitmaps, icons, pdf's, etc. > They do not necessarily reside in an isolated folder. > That wouldn't work cross-platform. You might store file the C:\D\e\f.txt which i could not extract on Unix because we don't have drive letters. If we ignore the C: part, i still couldn't extract to /D/e/f.txt, unless i was the root user. Case sensitivity is another problem in that regard. If you store C:\D\e.txt and C:\d\e.txt, those would map to two different folders on Unix systems. Likewise, Unix /a/b/c.txt has no direct mapping on Windows (which drive should it use?). -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
On Tue, 26 Jun 2018 18:12:54 +0200, Richard Hipp wrote: On 6/26/18, j. van den hoff wrote: turning this setting on by default might also offer the "least surprise" for the user It isn't an on/off setting. I was not clear. The setting is the name of the directory that is the root of the unversioned file hierarchy. see my previous mail: from a user perspective (mine, anyway...) it seems that the only "good" solution would be that the uv-files end up at the exact same place as on the "pushing" site/repo, i.e. under the pathname that is recorded in the database and reported by `fossil uv ls'. in my view, uv-files are not different from any other file in the repo, except that there history is not recorded. so they should not change location in my checkout, depending on a setting. they should keep their logical position (pathname relative to checkout root). An empty string for this setting means "off". But there are infinitely many "on" settings. What should be the default? "unversioned"? ".uv"? Just "."? this could of course work if the path convention is obeyed also by the "pushing" repo (that checks the uv-files in) even before checking the files into the repo (think of my example: file names of the unversioned files are used in some "include" statement elsewhere, e.g. in our LaTeX document). but it seems error prone. also, there might be good reason for multiple directories containing (e.g. different types of) uv-files. why could the uv-files not "simply"(?) be always put into the locations as reported by `fossil uv ls'. am I overlooking some obvious problem? I would think that could be the only thing a user would want: uv-files are always located/put where they "should be" (namely at the location where they were prior to checking them in in one of the clones) just as the versioned files? if unversioned files are moved around in the checkout manually, the changed paths should be propagated with the next `uv sync' to the other side/everywhere. I presume... -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
On 6/26/18, j. van den hoff wrote: > turning this setting on by default might also offer the "least > surprise" for the user It isn't an on/off setting. I was not clear. The setting is the name of the directory that is the root of the unversioned file hierarchy. An empty string for this setting means "off". But there are infinitely many "on" settings. What should be the default? "unversioned"? ".uv"? Just "."? -- 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] `unversioned' questions
On Tue, 26 Jun 2018 17:31:32 +0200, Richard Hipp wrote: My thought was to provide a new setting (perhaps versionable) that specified a directory relative to the root of the check-out into which unversioned files are written whenever one does "fossil update" or "fossil checkout". If the setting is missing or empty, then Fossil fyi, in our today's "test case", the unversioned files reside in a designated sub-directory of the checkout root *plus* in sub-directories thereof. I presume, this is typical: it might not always be desirable (or feasible) to put *all* unversioned files (there might be many...) in a common, single directory. moreover, in our test case, these files are image files whose path appears in the `\includegraphics' directives in the LaTeX file using them: so they must not change their location relative to the checkout root ... overall, I would think the handling of unversioned files needs always to respect the (recorded) original path relative to the repo root (as also reported by `fossil uv ls'). anything else might break builds (of latex docs or programms), no? works as it does now. If you turn on the setting, though, then the unversioned files work just like other files in the check-out, except that Fossil never records their history. such a setting (even if not versionable) would be an ideal solution in my view. turning this setting on by default might also offer the "least surprise" for the user (it sure surprised us here today that the files simply did not show up in the other working copy at all ...) I'm not sure yet whether or not this is a good idea. I'll need to think about it. see above: my opinion is, that the location of the files should be as reported by `fossil uv ls', i.e. unchanged relative to checkout root. I do hope, this would not cause trouble elsewhere for fossil or complicate implementation too much? thank you for bothering to look into this. joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Markdown in tickets
On 6/26/18, Andy Goth wrote: > Is there a reason why Fossil tickets don't allow markdown? The format > options are wiki, HTML, plain text, and [links only]. Markdown as a formatting option can be added by configuration. Perhaps you are asking for Markdown support to be added to the default configuration? -- 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] Markdown in tickets
Is there a reason why Fossil tickets don't allow markdown? The format options are wiki, HTML, plain text, and [links only]. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
Can unversioned files respect their original paths when added? I have several locations for bitmaps, icons, pdf's, etc. They do not necessarily reside in an isolated folder. Thanks for the new Fossil features! On Tue, Jun 26, 2018 at 11:31 AM, Richard Hipp wrote: > My thought was to provide a new setting (perhaps versionable) that > specified a directory relative to the root of the check-out into which > unversioned files are written whenever one does "fossil update" or > "fossil checkout". If the setting is missing or empty, then Fossil > works as it does now. If you turn on the setting, though, then the > unversioned files work just like other files in the check-out, except > that Fossil never records their history. > > I'm not sure yet whether or not this is a good idea. I'll need to > think about 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 > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
My thought was to provide a new setting (perhaps versionable) that specified a directory relative to the root of the check-out into which unversioned files are written whenever one does "fossil update" or "fossil checkout". If the setting is missing or empty, then Fossil works as it does now. If you turn on the setting, though, then the unversioned files work just like other files in the check-out, except that Fossil never records their history. I'm not sure yet whether or not this is a good idea. I'll need to think about 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
Re: [fossil-users] `unversioned' questions
On Tue, 26 Jun 2018 17:08:48 +0200, Richard Hipp wrote: Unversioned files do not appear in the local check-out, by design. It would be an enhancement to make them do so. But you are not the first to request that capability. I've been on a Fossil-enhancement binge lately - perhaps I can find the time to fix that has not gone unnoticed :) that for you... this would be great, of course, if doable. I actually was suspecting/"afraid" that the current behavior is by design and that there might be deeper reasons for it ... but when I discussed this with my colleague we were not able to find an example were providing `up -u' or `uv up' could cause a problem. could it? On 6/26/18, j. van den hoff wrote: today I convinced a colleague to give fossil a try. so we set up a project (two checkouts/clones, one central server/repo), using a planned journal article (to be written in latex) as the test case. now, while I never have used 'unversioned files' so far, he immediately wanted to try this option for the jpeg-figures to be included (and probably modified 100 times before the paper is completed). good: he managed to get them into his repo and to sync it to the server. good: I managed to sync the unversioned files into my repo. problems/questions: 1. the files do not materialize in my checkout after "sync -u". they are "just" present in my local repository. that probably is as it should be (just as with standard `sync'). but there seems to be no equivalent to `fossil up' for the unversioned files. question: what is the canonical way to get them out of the repo? I see the export command but it probably is not the idea to issue 20 export commands (or to write a shell script for that)? 2. if I export the files manually now, what happens after the next push of unversioned files by my colleague? I guess, I can sync them (but am not really notified of changed content) but would have again to export them manually (and would have to know that this is required)? maybe I am missing some stupid point here, but my expectation would have been that unversioned files mostly behave like tracked/versioned files in that there should be an update facility (say `fossil up -u' or something like that) of these files in my local checkout? thank you, joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
Unversioned files do not appear in the local check-out, by design. It would be an enhancement to make them do so. But you are not the first to request that capability. I've been on a Fossil-enhancement binge lately - perhaps I can find the time to fix that for you... On 6/26/18, j. van den hoff wrote: > today I convinced a colleague to give fossil a try. so we set up a project > (two checkouts/clones, one central server/repo), using a planned journal > article (to be written in latex) as the test case. > > now, while I never have used 'unversioned files' so far, he immediately > wanted to try this option for the jpeg-figures to be included (and > probably modified 100 times before the paper is completed). > > good: he managed to get them into his repo and to sync it to the server. > good: I managed to sync the unversioned files into my repo. > > problems/questions: > > 1. > the files do not materialize in my checkout after "sync -u". they are > "just" present in my local repository. that probably is as it should be > (just as with standard `sync'). but there seems to be no equivalent to > `fossil up' for the unversioned files. > > question: what is the canonical way to get them out of the repo? I see the > export command but it probably is not the idea to issue 20 export commands > (or to write a shell script for that)? > > 2. > if I export the files manually now, what happens after the next push of > unversioned files by my colleague? I guess, I can sync them (but am not > really notified of changed content) but would have again to export them > manually (and would have to know that this is required)? > > maybe I am missing some stupid point here, but my expectation would have > been that unversioned files mostly behave like tracked/versioned files in > that there should be an update facility (say `fossil up -u' or something > like that) of these files in my local checkout? > > thank you, > > joerg > > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > ___ > 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] Cloning repository with large files very slow
On 06/21/2018 10:00 PM, E Cruz wrote:
On 06/21/2018 08:38 PM, Richard Hipp wrote:
Please rebuild your Fossil using the latest trunk check-in, then try
your clone using the new --nocompress option. Report back whether or
not this solves your problem.
Using the new option cuts the cloning time of one of the repositories
from 8 minutes down to 4 minutes. For another repository it went from
2 minutes down to to 1 minute, so basically using "--nocompress" is
cutting the time in half. Most of the remaining time is in the
"rebuilding repository meta-data" phase, but this change is a
significant improvement already. Thanks
On 06/22/2018 09:57 PM, E Cruz wrote:
Delta encoding is still taking a significant amount of time, in
particular the call to content_deltify() by add_one_mlink() in
manifest.c.
Commenting out this call to content_deltify() allows cloning my
smaller repository with "--nocompress" to go from 1 minute down to 4
seconds. I am not familiar enough with fossil to know all the
implications of commenting this call out, but the resulting cloned
repository seems to be fine. If the noCompress flag could be
propagated down so that this particular call to content_deltify() is
skipped when cloning with the flag enabled, the clone operation time
could be reduced to a small fraction of what it is now.
Based on my previous findings, I will like to propose a way to reduce
cloning time of repositories that contain large files with very large
"deltas" between revisions. The change involves saving the
"--nocompress" flag in fossil's global state and using it to skip
calling content_deltify() from add_one_mlink() if the flag is set. I do
not yet understand all the internals of fossil, so I have checked the
proposed changes by cloning fossil's repository with and without
--nocompress, then comparing the outputs of "fossil export --git".
Outputs from both clones were identical. I also checked individual
tables in the two clones and the only differences found were:
1. timestamp of |last-sync-url| entry in |config| table
2. timestamps for the cluster entries in the |tagxref| table
3. |pw| field in the |user| table.
My understanding is these differences are expected to be present between
clones. The way I implemented the proposed changes is shown in the
included patch file. Could you take a look to see if they don't have
any unintended side effect?
Thanks.
Index: src/clone.c
==
--- src/clone.c
+++ src/clone.c
@@ -128,10 +128,12 @@
const char *zHttpAuth; /* HTTP Authorization user:pass information */
int nErr = 0;
int urlFlags = URL_PROMPT_PW | URL_REMEMBER;
int syncFlags = SYNC_CLONE;
int noCompress = find_option("nocompress",0,0)!=0;
+
+ g.noCompressClone = noCompress;
/* Also clone private branches */
if( find_option("private",0,0)!=0 ) syncFlags |= SYNC_PRIVATE;
if( find_option("once",0,0)!=0) urlFlags &= ~URL_REMEMBER;
if( find_option("verbose","v",0)!=0) syncFlags |= SYNC_VERBOSE;
Index: src/main.c
==
--- src/main.c
+++ src/main.c
@@ -283,10 +283,11 @@
} reqPayload; /* request payload object (if any) */
cson_array *warnings; /* response warnings */
int timerId; /* fetched from fossil_timer_start() */
} json;
#endif /* FOSSIL_ENABLE_JSON */
+ int noCompressClone; /* True if cloning with --nocompress */
};
/*
** Macro for debugging:
*/
Index: src/manifest.c
==
--- src/manifest.c
+++ src/manifest.c
@@ -1245,11 +1245,11 @@
db_bind_int(, ":pfn", pfnid);
db_bind_int(, ":mp", mperm);
db_bind_int(, ":isaux", isPrimary==0);
db_exec();
}
- if( pid && fid ){
+ if( !g.noCompressClone && pid && fid ){
content_deltify(pid, , 1, 0);
}
}
/*
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] `unversioned' questions
today I convinced a colleague to give fossil a try. so we set up a project (two checkouts/clones, one central server/repo), using a planned journal article (to be written in latex) as the test case. now, while I never have used 'unversioned files' so far, he immediately wanted to try this option for the jpeg-figures to be included (and probably modified 100 times before the paper is completed). good: he managed to get them into his repo and to sync it to the server. good: I managed to sync the unversioned files into my repo. problems/questions: 1. the files do not materialize in my checkout after "sync -u". they are "just" present in my local repository. that probably is as it should be (just as with standard `sync'). but there seems to be no equivalent to `fossil up' for the unversioned files. question: what is the canonical way to get them out of the repo? I see the export command but it probably is not the idea to issue 20 export commands (or to write a shell script for that)? 2. if I export the files manually now, what happens after the next push of unversioned files by my colleague? I guess, I can sync them (but am not really notified of changed content) but would have again to export them manually (and would have to know that this is required)? maybe I am missing some stupid point here, but my expectation would have been that unversioned files mostly behave like tracked/versioned files in that there should be an update facility (say `fossil up -u' or something like that) of these files in my local checkout? thank you, joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Email notifications content transfer encoding
Since Rafal's original inquiry, I have modified the email notification logic to use quoted-printable instead of base64. Quoted-printable is not as clean as plain-old 8bit, but it is much more readable than base64. Acceptable compromise? On 6/26/18, Rafal Bisingier wrote: > Hi > > Richard asked me to post it on the list for discussion, so here it is: > The new email notification functionality in fossil use base64 as > Content-Transfer-Encoding. I personally prefer use of 8bit encoding, > which have a side-effect of human-readable source of message. I admit > that it does not matter much in a normal situation (reading the message > in an email client), but on a few occasions I had to grep/cat through > mailbox files, and having a readable message body was of great help > then. That's why I want to submit for consideration using a 8bit > content transfer encoding for email notifications. Nowadays there are > practically no problems in transport of such messages. The only down > side I could think of is that theoretically there is a limit of 1000 > chars in a line in an email message (and base64 encoding bypasses it). > But would it really be a bigger problem? > On the pros there is simplified debugging (no need to decode message, > which fossil store in his database file in "transport-ready" form - > so currently with base64 encoded body). Of course DRH already wrote a > tool to help in this ;-) so it is already doable without much trouble > https://www.fossil-scm.org/fossil/file/tools/decode-email.c > Nevertheless I'd like to have a readable source of messages. ;-) > > -- > Greetings > Rafal Bisingier > ___ > 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] Email notifications content transfer encoding
Hi all: In message <20180626110936.3524bd1f@puter>, Rafal Bisingier writes: >Richard asked me to post it on the list for discussion, so here it is: >The new email notification functionality in fossil use base64 as >Content-Transfer-Encoding. I personally prefer use of 8bit encoding, >which have a side-effect of human-readable source of message. I agree having a regular readable/greppable message is a big win. Just my $0.02. -- -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. ___ 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] What should email notifications look like?
On 2018-06-22 20:40, Joerg Sonnenberger wrote: [---] > BTW, the main mercurial list uses the following mail format for "batch" > changes: > > https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-June/117551.html This is highly machine parse-friendly. I like it a lot. -- Kind Regards, Jan ___ 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] mv-rm-files setting
perfect, thanks a lot!
On Tue, 26 Jun 2018 13:22:40 +0200, Richard Hipp wrote:
The mv-rm-files setting used to require a compile-time option in order
to function. I have removed that requirement. mv-rm-files now works
without special compile-time options.
On 6/26/18, j. van den hoff wrote:
I have not fiddled with this for some time and now I do no longer recall
how exactly this setting is managed. it is mentioned in several of the
help pages and I do have an entry
in my global `.fossil' database
INSERT INTO global_config VALUES('mv-rm-files','on');
(I do no longer recall when and how I've put it there :| ...) but it is
neither reported by `set' AFAICS nor, in fact, does `fossil set'
recognize
"mv-rm-files" as a valid setting. what am I missing? a pointer where to
look in the documentation would be appreciated...
thank you,
joerg
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] mv-rm-files setting
The mv-rm-files setting used to require a compile-time option in order
to function. I have removed that requirement. mv-rm-files now works
without special compile-time options.
On 6/26/18, j. van den hoff wrote:
> I have not fiddled with this for some time and now I do no longer recall
> how exactly this setting is managed. it is mentioned in several of the
> help pages and I do have an entry
> in my global `.fossil' database
>
> INSERT INTO global_config VALUES('mv-rm-files','on');
>
> (I do no longer recall when and how I've put it there :| ...) but it is
> neither reported by `set' AFAICS nor, in fact, does `fossil set' recognize
> "mv-rm-files" as a valid setting. what am I missing? a pointer where to
> look in the documentation would be appreciated...
>
> thank you,
>
> joerg
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
> ___
> 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
[fossil-users] mv-rm-files setting
I have not fiddled with this for some time and now I do no longer recall
how exactly this setting is managed. it is mentioned in several of the
help pages and I do have an entry
in my global `.fossil' database
INSERT INTO global_config VALUES('mv-rm-files','on');
(I do no longer recall when and how I've put it there :| ...) but it is
neither reported by `set' AFAICS nor, in fact, does `fossil set' recognize
"mv-rm-files" as a valid setting. what am I missing? a pointer where to
look in the documentation would be appreciated...
thank you,
joerg
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] email testing - no subscriber table?
Le 26/06/2018 à 09:25, j. van den hoff a écrit :
On Mon, 25 Jun 2018 23:57:35 +0200, jungle Boogie
wrote:
On 25 June 2018 at 14:51, Richard Hipp wrote:
On 6/25/18, jungle Boogie wrote:
If I inadvertently forward my email along
to someone/group without modifying the footer, the person/group would
be able to alter my subscription.
How can I fix that?
it seems the only way would be to _not_ include the link in each and
every alert, no? maybe automated separate notification mail once every
(3?) months ("your subscription details are here:") would be feasible?
many mailing lists do the same (mailing subscription password reminders
once a month or every 3 months). o.t.o.h.: it is of course not really a
big deal to leave it as is (but the unintentional dissemination of the
subscription links via forwarding the alert mails will then happen
regularly, of course).
Why not just include the unsubscribe link (*)?
Users enter their e-mail and get via e-mail a link to unsubscribe or
change the subscriptions.
Olivier
* https://fossil-scm.org/fossil/unsubscribe
___
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] email testing - no subscriber table?
On Mon, 25 Jun 2018 23:57:35 +0200, jungle Boogie
wrote:
On 25 June 2018 at 14:51, Richard Hipp wrote:
On 6/25/18, jungle Boogie wrote:
If I inadvertently forward my email along
to someone/group without modifying the footer, the person/group would
be able to alter my subscription.
How can I fix that?
it seems the only way would be to _not_ include the link in each and every
alert, no? maybe automated separate notification mail once every (3?)
months ("your subscription details are here:") would be feasible? many
mailing lists do the same (mailing subscription password reminders once a
month or every 3 months). o.t.o.h.: it is of course not really a big deal
to leave it as is (but the unintentional dissemination of the subscription
links via forwarding the alert mails will then happen regularly, of
course).
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
