Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On Thu, Jun 28, 2018 at 12:14 PM, Chad Perrin wrote: > On Thu, Jun 28, 2018 at 11:40:01AM -0700, Sam Putman wrote: > > > > As a target, I would suggest the emitted html look as much like this > > as possible: > > > > view-source:https://github.com/jvirkki/libbloom/blob/master/bloom.c > > > > The actual code block begins at line 821. > > > > This style of markup is a de-facto standard and leads to a linking > > style that would greatly aid migration from git if fossil could adhere > > to it. > > I'm not sure how this has any effect on migration from git to fossil, > though. Git export and Fossil import wouldn't touch this code. Are you > talking about some kind of external tools being able to interact with > this code in the browser? If so, the classes involved probably come > from whatever JS library is used for syntax highlighting anyway, rather > than from something like code internal to Fossil (unless syntax > highlighting gets implemented in C as part of Fossil). > > I guess the upshot is that I'm not sure what you mean, and all I've been > able to do so far is guess. > > It's a related but distinct feature, the ability to render links like this one: https://github.com/jvirkki/libbloom/blob/master/bloom.c#L57-L60 Github, Gitlab, and Gogs will all correctly render that link, and various short/relative links of the same form. This is a good convention for making URIs for branches, files, lines, and the like. These URIs get embedded into documentation and tickets, anywhere you might want a hyperlink in your rendered cod. The schema would work as well for fossil as it does for git. Those can't be effectively migrated to fossil, which will display the content hash of the file being rendered as the URI. As for the HTML schema for marking up code, it's also a de-facto standard. Originating with pygments, if I recall correctly and used, with some variation, by all the major syntax highlighters. If the other proposal is just whatever highlights.js emits, I'm sure we'll find that they are somewhere between similar and identical. ___ 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] Patch: Enables integration of syntax highlighting systems
On Thu, Jun 28, 2018 at 9:07 AM, Chad Perrin wrote:
> See if this makes sense:
>
> Apply syntax highlighting to a block of code. Organize the code in
> second column TD elements of a table. Organize line numbers in first
> column TD elements of a table.
>
> Thus, you would have HTML for a line of code that looks something like
> this (using a totally made-up function as example code):
>
>
> $num
>
> uint16_t class="color-label">get_next() {
>
>
>
> Of course, that's just off the top of my head. I don't actually know
> how the HTML resulting from application of the syntax highlighting code
> would look in this case. The upshot, though, is that applying syntax
> highlighting to the code to be displayed first, then organizing it into
> table cells with number cells, might avoid JS syntax highlighting issues
> with line numbers, including any issues around multiline highlighting.
> The downside is that it would result in either having to do all line
> numbering in JS or applying syntax highlighting server-side.
>
>
As a target, I would suggest the emitted html look as much like this as
possible:
view-source:https://github.com/jvirkki/libbloom/blob/master/bloom.c
The actual code block begins at line 821.
This style of markup is a de-facto standard and leads to a linking style
that would
greatly aid migration from git if fossil could adhere to it.
___
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] A fossil library
On Tue, Jun 19, 2018 at 11:28 AM, Stephan Beal wrote: > On Tue, Jun 19, 2018 at 8:13 PM Sam Putman wrote: > >> >>> >>>> I got the sense from the docs that the hash is using the SQLite style >>>> versioned API, so it follows that >>>> the old hash code is sitting where it needs to. >>>> >>>> Does this amount to following the style of that file for another >>>> similar file in fossil(1)? >>>> >>> >>> i'm not clear what you mean :|. >>> >>> >> I'm sure that could have been more clear. >> >> Did some poking around between fossil and libfossil, it looks like they >> both have a sha-1.c, >> the difference starts with the copyright, 2006 vs 2013. A cursory scan >> suggests that the ~200 >> line difference is more tests, and some framework code that presumably >> libfossil doesn't need. >> >> fossil also has sha1-hard.c (let's ignore this for now?) and sha3.c. >> >> I haven't yet found where in libfossil sha-1.c is called, and what the >> substantive differences >> are between the two. What I'm wondering is, can the wrapper for sha-1.c >> be rewritten to also >> wrap sha-3? Possibly sha1-hard as well, if it's on a critical path. >> > > A few of the utility classes (most notably sha1 and md5) were originally > copied over 1-to-1 and renamed to match the libfossil project conventions. > sha1-hard and sha-3 came along after my RSI fallout, and are not included > in libfossil. i have _no_ idea what the differences are between sha1 and > sha1-hard, so can't comment on those. The buffer sizes differ between sha1 > and sha-3, so i'm not sure whether those two could be reasonably/cleanly > combined. i have to resist the temptation to go poking around in the code > rabbit hole, as that almost invariably leads to days of hand pains :(. > (Software development was always like a drug to me, and i am very much a > recovering addict.) > > I'm fairly sure the various hashes need to operate separately. It also sounds like the fossil(1) side of this is a matter of updating libfossil with the latest versions. > I know there's some wrinkles around how fossil picks a sha that allowed >> for the transition, I'm >> content with being able to wield those sha functions in a fossil context >> at a fairly low level, for now. >> > > It "should" be trivial to port the core sha1-hard and sha-3 to libfossil - > porting of sha1 and md5 was literally a copy/paste/rename job. However, the > assumption that SHA1 is "the" hash is "strongly embedded" in many places in > libfossil (md5 is only used in the manifest files and its usage does not > need to be modified/extended). It "should" be simple to find all such > places by grepping for FSL_UUID_STRLEN (defined in > include/fossil-scm/fossil-hash.h), and porting all such places to support > variable hashes is, AFAIK, the only critical piece needed for making > libfossil compatible (again) with fossil(1). If that hurdle can be > surpassed, the rest is "easy" (even the merging - it simply needs to be > ported over from fossil, adapting the API to a library interface along the > way). > > That kind of breadcrumb (FSL_UUID_STRLEN) is really helpful, thanks. Don't know when or even if I might, but I'm warming to the idea of trying it. ___ 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] A fossil library
On Tue, Jun 19, 2018 at 10:20 AM, Stephan Beal wrote: > On Mon, Jun 18, 2018 at 7:18 PM Sam Putman wrote: > >> A Capitalized pure-C struct being referred to as an object is not unheard >> of! But it did lead me down >> the wrong path. >> > > Here's my little contribution to spreading the word about OO in C: > > http://www.wanderinghorse.net/computing/papers/DoingOOInC.pdf > > :) > Looks like I've got some evening reading ahead of me! > > >> I got the sense from the docs that the hash is using the SQLite style >> versioned API, so it follows that >> the old hash code is sitting where it needs to. >> >> Does this amount to following the style of that file for another similar >> file in fossil(1)? >> > > i'm not clear what you mean :|. > > I'm sure that could have been more clear. Did some poking around between fossil and libfossil, it looks like they both have a sha-1.c, the difference starts with the copyright, 2006 vs 2013. A cursory scan suggests that the ~200 line difference is more tests, and some framework code that presumably libfossil doesn't need. fossil also has sha1-hard.c (let's ignore this for now?) and sha3.c. I haven't yet found where in libfossil sha-1.c is called, and what the substantive differences are between the two. What I'm wondering is, can the wrapper for sha-1.c be rewritten to also wrap sha-3? Possibly sha1-hard as well, if it's on a critical path. I know there's some wrinkles around how fossil picks a sha that allowed for the transition, I'm content with being able to wield those sha functions in a fossil context at a fairly low level, for now. ___ 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] A fossil library
On Mon, Jun 18, 2018 at 4:54 AM, Stephan Beal wrote: > On Sun, Jun 17, 2018 at 11:11 PM Sam Putman wrote: > >> On Sun, Jun 17, 2018 at 6:39 AM, David Mason wrote: >> >>> Just had a quick thought that might make the conversion to library much >>> easier. >>> >>> If you have a relatively small API interface, each of the API functions >>> could do a setjmp https://en.wikipedia.org/wiki/Setjmp.h >>> >> >> > This is the kind of approach I glossed over as a "goto cleanup", so we're >> on >> the same track here. >> >> I haven't had a chance to go over some of the core C files in libfossil >> yet, >> curious to what degree it follows this pattern already. >> > > i have to admit that you lost me at setjmp. There are certain C APIs which > i won't touch unless absolutely forced to, and setjmp/longjmp belong to > that category. gotos are widely used in libfossil to simplify error > handling/deallocation within a given function. > > setjmp/longmp are of course weapons of awesome power. In this context, just a way of goto jumping farther than goto alone allows for. Never use them when a simple goto will do, and it sounds like it will. I think the proposal was to replace every crash with the same longjmp, to simplify porting the code, but you've already taken the time to do it right. In libfossil, all error state is propagated as an integer, with some cases > providing additional information in an Error object owned by the Context > object (each Context manages, at most, one opened repo instance). The API > docs describe, where relevant, which result codes must be considered > fatal/unrecoverable (allocation error being the primary case). An example > of propagating more information is SQL query preparation failure - the > error string from sqlite would be propagated back up via the Context's > Error object. An allocation error, on the other hand, is simply returned as > the enum entry FSL_RC_OOM, as we can't provide more information for that > case without more allocation (which would presumably fail). > > Excellent, no surprises here. ___ 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] A fossil library
On Mon, Jun 18, 2018 at 4:43 AM, Stephan Beal wrote: > On Sun, Jun 17, 2018 at 11:07 PM Sam Putman wrote: > >> About those objects... >> >> What your docs call fossil(1) is written in plain C. Or rather C, Tcl, >> SQL and TH1, if you prefer. >> In any case, not C++. >> > > liubfossil is 100% C89 except that it requires "long long" because sqlite3 > requires it. long long is not strictly C89 but all compilers supports it. > The C++ code in the tree is simply optional high-level wrappers, intended > primarily to allow me to "exercise" the core API, to make sure that it > would be useful in other contexts. > > Oh that's good news. A C++ wrapper is even a useful template for FFI bindings. > I'm still pretty convinced the work on libfossil won't go to waste. >> > >> The excellent documentation alone has advanced my understanding >> considerably. >> > > :) > > >> What might make sense is a sort of 'parallel construction'. Nice thing >> about a revision control >> system, it's got all the revisions. >> >> So to write a clean C libfossil, we can start with the first commit and >> follow the breadcrumbs. >> > > The only "problem" with that (for a given definition of "problem") is that > i'm rather chaotic in terms of how i work on code: there's little rhyme or > reason, nor any specific ordering to commits or (for the most part) > features. You won't find any reasonable order to the timeline. The > implementation required, of course, certain features before others, though, > so... there is that. > > It's never fun to take a forensic approach to a codebase. This was all predicated on some references to a Context object, both in the thread and the docs. A Capitalized pure-C struct being referred to as an object is not unheard of! But it did lead me down the wrong path. > I don't think it's strongly tied to the patch-centric model, it's a >> (relatively) simple matter of >> representing possible outcomes as distinct states. There might be some >> potentially >> exponential bad behavior, we are talking about permutations after all. >> > > It might even be feasible to store each such variation in the 'stash' > table (llibfossil never got far enough to implement the 'stash' or 'undo' > parts, as both depend on the merge process, which was the final "big/scary" > hurdle left to port). > > Looking like all I've got is a small chicken-and-egg problem. Needing to port a few more modules over is a-ok. Trouble is the repos I want to work with are c. 2018 (or ported in 2018 from older git), so they'd be using the new hash. I could start linking in libfossil and poke around an older repository, but that breaks the feedback loop. Big difference between playing around with a library and dogfooding it. I got the sense from the docs that the hash is using the SQLite style versioned API, so it follows that the old hash code is sitting where it needs to. Does this amount to following the style of that file for another similar file in fossil(1)? That's a bite small enough I might be able to chew it. ___ 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] A fossil library
On Sun, Jun 17, 2018 at 6:39 AM, David Mason wrote: > Just had a quick thought that might make the conversion to library much > easier. > > If you have a relatively small API interface, each of the API functions > could do a setjmp https://en.wikipedia.org/wiki/Setjmp.h and then the > fatal error routines could longjmp back. This would give you API safety, at > very limited code intervention. And if a flag got set by the API functions, > then the fatal routines could check, so that fossil the program would need > no changes as only the API functions would change the default fail-hard > behaviour. > > But perhaps the API would be too big to make this a win. > > Just a thought. > > ../Dave > > > This is the kind of approach I glossed over as a "goto cleanup", so we're on the same track here. I haven't had a chance to go over some of the core C files in libfossil yet, curious to what degree it follows this pattern already. Stephan has indicated that allocation is necessarily somewhat more fine-grained than this, and elsewhere in the documentation, exceptions are mentioned... -Sam ___ 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] A fossil library
On Sun, Jun 17, 2018 at 4:50 AM, Stephan Beal wrote: > On Sat, Jun 16, 2018 at 11:44 PM Sam Putman wrote: > >> >> An incremental refactoring of this into something more modular would >> be a boon to maintenance and testing. Seems like a sleeping dog we can >> let lie for now. >> > > That's actually the easy part. The real effort comes in with error > checking and handling, especially in cases where an error may (in a > library) propagated from 3+ levels deep. The app will just exit() at that > point, so no thought has gone (nor needed to go) into error handling or > propagation (because there is no propagation - all errors are "immediate"). > Not only does the propagation at the error-triggering point need to be > decided upon, but how it will propagate arbitrarily far up the call stack. > In the end, libfossil went with a hybrid approach of returning non-0 (from > a well-defined enum of result codes) and the context object holds an Error > object which may (or may not, depending on context) hold more details about > the error. > > About those objects... What your docs call fossil(1) is written in plain C. Or rather C, Tcl, SQL and TH1, if you prefer. In any case, not C++. We have fairly strict requirements for the languages we include in our own runtime, because we intend to parse both the syntax and the static semantics of the languages we use. That makes C++ a non starter, as I would imagine it is for including a libfossil as the core of fossil(1). Even for my own needs, the C89-99 family hits the sweet spot; I'm tolerant of ANSIsms in old code but try not to emit them personally. Given that, I'll skip ahead a bit: > > >> >> I concur with Warren that the effort of a libfossil is best justified if >> it becomes the core of fossil proper. >> > > Absolutely 100%, but it's essentially impossible to back-port it into > fossil proper without some massive upheaval. Since fossil lies at the heart > of the sqlite project, there's not (in my somewhat conservatively cautious > view) much room for such severe upheaval. A 3rd-party implementation is > interesting in and of itself, but it would also potentially be a point of > contention, as you say... > I'm still pretty convinced the work on libfossil won't go to waste. The excellent documentation alone has advanced my understanding considerably. What might make sense is a sort of 'parallel construction'. Nice thing about a revision control system, it's got all the revisions. So to write a clean C libfossil, we can start with the first commit and follow the breadcrumbs. > > Tasks like isolating those core intricate algorithms into well-documented >> modules, where >> errors and edge cases are handled where they occur, this can really pay >> off. >> > > That's all in libfossil. > > >> Merging and patch theory are >> areas where real conceptual leaps are still happening. >> > > libfossil has all of fossil's diff algorithms but i don't think i ever > ported the full merge support (it can apply deltas but i don't recall > porting the type of merging decisions which are made during, e.g., a > checkout). Speaking of merging: that's often an interactive process, and > interactivity is difficult to define in a UI-ignorant library. > > This is a legitimately hard problem. Pijul's approach of having a conflict object instead of spraying the merge conflict all over the source file has potential. I don't think it's strongly tied to the patch-centric model, it's a (relatively) simple matter of representing possible outcomes as distinct states. There might be some potentially exponential bad behavior, we are talking about permutations after all. I'm way ahead of myself there; this is just to say that we can most likely do better than pushing a diff into the source code, while still providing a library API. > The one area of fossil I've done enough reading into to feel comfortable >> in my understanding is the >> file format itself. There's an edge to the documentation and I'm kinda >> peering over that edge slightly. >> > > The "artifact format" documentation is really Fossil's heart. All of the > other parts are implementation details for supporting that. Nonetheless, > any port will certainly want to take advantage of as many of those details > as possible (much of fossil's "heavy lifting" is done with sqlite, and > reimplementing many of those pieces without sqlite would be a massive > undertaking). > SQLite is a core library for bridgetools. I took to heart the "SQLite as alternative to fopen()" slogan, one of the best architectural decisions I've made. That's why we're using fossil as our DVCS, no matter what happens with this libfossil prop
Re: [fossil-users] A fossil library
, this can really pay off. Merging and patch theory are areas where real conceptual leaps are still happening. This is one of the shortcomings of git: aspects of the data structure are baked into the filesystem-database hybrid, and aspects of the merge algorithm leak into the data structure. Working with a dynamic, relational, single-file database can only improve upon this. The one area of fossil I've done enough reading into to feel comfortable in my understanding is the file format itself. There's an edge to the documentation and I'm kinda peering over that edge slightly. It has the necessary sort of forward compatibility baked into it. Following a SQLite model of using merge_v1, merge_v2, and so on, could really come in handy. i would be thrilled to see someone implement a library for fossil, but > anyone doing so needs to understand, in advance, that it's a large > undertaking. > > I'm happy to sign contribution agreements and otherwise smooth the way to collaborating on this. I am already a project lead on a daunting number of repos; taking point wouldn't be possible, I'm also basically brand new here. A short introduction is probably in order: I'm with Special Circumstances, a nascent think tank. We're contracting with the Defense Department, among other partners, to work on open source software. Our initial brief is concentrated on language-theoretic security; as we grow, hiring people to work on this sort of project is how we intend to do it. Thanks again, Stephan. I'll be looking into those links, please don't feel as though a back-and-forth on each email is necessary, whatever is comfortable for you. cheers, -Sam ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] A fossil library
First post. Hi! I've been lurking along, following the discussion here. Common thread is a desire for 'more fossil'. I'm in this camp myself. But I see the attraction of the core fossil application. It works perfectly for a fairly close-knit community, and it follows a philosophy that's been working for decades now. One that is, if anything, more effective as it becomes less fashionable. Let me make a suggestion: what we need is not more fossil, it is less fossil. I wrote Dr. Richard Hipp about this earlier, his response was positive enough that I felt encouraged to bring it to the community. For my own projects, I've switched to fossil. It's the obvious choice, we're using SQLite in preference to the old pile o' files already. The fossil codebase has all the core algorithms for storing deltas in a single database file, merging, deduplication, Merkle hashing, key signature management, extensible metadata... I don't have to sell you on the virtues of this VCS! I would benefit greatly from being able to use this excellent collection of SQLite best practices and algorithms, the same way I use SQLite: as a static or linked library, one which can be wrapped in various FFIs for VMs, or linked directly from a systems language. My own case would call this from LuaJIT, what matters is everyone can be happy. fossil proper can stay attuned to the SQLite/Tcl/Tk alliance, as it should, and adventurers could wire it to mailing lists, wikis, forums. I think this would help fossil really stand out. Just the fact that here we have tools to read and write git to a single-file database, that's huge! Tools for revision control would be a real boon to applications already using SQLite as an AFF. I could go on. I always feel some trepidation towards what amounts to asking other people for free work. I feel this refactoring could benefit fossil as well as my own software. I'd be a part of such an effort as soon as anything halfway plausible was compiling, if invited. Sincerely, -Sam Putman -- Special Circumstances ___ 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] (New To Fossil): Repo Workflow / Should I Clone Or Use Many Opens
I've been using fossil this way with Dropbox for over a year now. I have never seen any fossil repo corruption or had other issues. On Fri, Aug 1, 2014 at 6:02 AM, David Botham dbot...@infoblox.com wrote: All, I am in the process of moving from git to fossil. My question is about how many repositories to use for a particular project. A summary of my use case: - Single developer, but, may from time to time (once a year) have someone else I work with want to contribute. And those contribs are usually small. - I alter the code for my projects on different computers (workstation at the office, laptop on the road, etc...). - I use DropBox as a data store. - Mostly I develop on Windows, but, target Windows and Linux (and now and then OSX). After reading the docs and Jim's book, I setup like this: + Main repo on DropBox: c:\ cd DropBox\fossil-repos c:\DropBox\fossil-repos\ fossil new my-project.fossil + Clone the repo in DropBox to my local workstation, laptop, etc, so on each, I do this: c:\ cd fossil-repo-clones c:\fossil-repo-clones\ fossil clone \DropBox\fossil-repos\my-project.fossil my-project.fossil + Open the local clone in a dedicated development directory and commit the initial files (intial file commit done once, on the system where the code base starts): c:\ cd dev-projects\my-project c:\dev-projects\my-project\ fossil open \fossil-repo-clones\my-project.fossil c:\dev-projects\my-project\ fossil add . output here... c:\dev-projects\my-project\ fossil commit -m Initial commit of files. Starting development. My big question is, am I wasting my time creating the local clones on all my different systems? Should I just the repo in my DropBox and simply open on my various systems? Thanks in advance for looking at my issue and helping. David ___ 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] Tree view and browser back button
I may have missed something, but this is not showing up on the main fossil timeline anymore. Has the new tree view been pulled out of trunk for now? On Tue, Jan 14, 2014 at 6:55 PM, Richard Hipp d...@sqlite.org wrote: On Tue, Jan 14, 2014 at 8:42 PM, Joel Bruick j...@joelface.com wrote: Joel Bruick wrote: Sorry, I shouldn't have committed it to trunk in the first place. I'll let you know when I've got it working better. Should be working properly now. Tested on Firefox, Chrome, and IE10/11. Brilliant! Thanks, Joel. The latest code has been merged to trunk and is now in the server. ___ 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] Extract HTML and JavaScript out of timeline.c
I intend to file the following feature request if it has not been discussed and rejected before. The HTML and JavaScript generated to render the timeline lacks flexibility. I was able to resolve my own problem (having a skin with a black background and white text) by making the modifications to timeline.c to display white lines between commits on the timeline. As far as I know, there is no other (or easy) way to resolve this. The fix is simple, but inflexible. Another possible fix would be to draw the lines using the default font color. Ultimately, I think that the HTML and Javascript should be moved to its own configuration page under Admin (like CSS, Footer, and Header) to allow users to further customize their fossil experience. If there are no objections, I will create the ticket for this feature request. Regards, Sam ___ 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] Extract HTML and JavaScript out of timeline.c
Hello everyone, I accidentally send this from a workstation with email tracking software enabled on the client. Please forgive this error, it was not intentional. Regards, Sam ___ 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] New user request
Thank you sir! This is exactly the type of thing I am looking for. I appreciate the time you put into this. — Hi Sam. Welcome aboard. I think Fossil is excellent, and I hope you will too. I'm typing on a mobile device ATM, so please excuse the brevity and spelling errors. I use fossil for all my personal projects, as well as professionally. For personal projects, I make a project-specific dir under my project containing dir (~/work), such as ~/work/foo/, and create an out-of-tree repo: cd ~/work/foo; fossil new ../fossils/foo.fsl; fossil open ../fossils/foo.fsl . Then, in the project dir I make ./doc, ./src/vendor, ./test. Supporting third-party code goes into ./src/vendor/libawesome (for example), my own code goes into ./src, docs to ./doc, and tests to ./test. For an imaginary lib awesome project that I want to build against, I place the code in ./src/vendor/libawesome, fossil add ./src/vendor, then commit it to it's own branch: fossil ci -m libawesome v.1.2.3 --branch vendor For my own code, infrastructure, I go back to trunk (fossil co trunk), add my files: (cd ~/work/foo; fossil add ./Smakefile ./src/*.c ./src/*.h.in) and do initial commit: fossil ci -m initial commit. If you feel you need/may patch your vendor code, you can: fossil co vendor; [hack hack hack]; fossil ci -m custom patches against lib awesome for project foo --branch vend_patched -- and maintain this along with upstream lib awesome updates: fossil co vendor; [dump lib awesome v1.2.4 code over 1.2.3]; fossil ci -m update lib awesome 1.2.3 - 1.2.4 Import to vend_patched: fossil co vend_patched; fossil merge vendor; [check for conflicts, correctness], fossil ci -m merge latest lib awesome 1.2.4 from [vendor] Back to the code your writing yourself: fossil co trunk; fossil merge vend_patched; fossil ci -m import supporting vendor code; [hack hack hack]; fossil ci -m my useful commit msg here; [hack hack hack] ... now you (still on [trunk]) want to start on a potentially build-breaking experimental feature: a bunny themed widget set. Start hacking in bunny-code, but at first commit: fossil ci -m start of bunny conversion --branch hop_hop You've now got two branches that are interesting to you: current stable production in [trunk], and the Next Big Killer Feature (not ready for prime time), in hop_hop. You hack on [hop_hop] (which is a derivative of [trunk], and improve it. Along the way though, your boss says: I've heard lowercase is the new black; make all the dialogue in our current project lowercase. No title case, upper case, camel case... All user facing text is lowercase. [hop_hop] is still WIP (work in progress), not ready for public consumption, so you go back to [trunk] (which you are shipping). You're in the middle of hacking [hop_hop], and you're not really ready to commit, but you don't want to lose your work. No problem. Stash it. fossil stash add -m hop_hop fluffy tail feature - incomplete Your work is safe in a stash that is shared among all branches, and you have no pending commits in your working set (you just stashed it, and when that partial work was stashed, the pertinent files were reverted to the state of the last commit.) You prepare to start lowercasing: fossil co truck; [hack hack hack]; fossil ci -m lowercase here, lowercase there, and change all user dialogue, etc to lowercase, committing as you convert. You tag a new release: fossil tag add foo_5.4.3 trunk, notify q/a and release management, and get back to bunny hacking. fossil co hop_hop You start making a game plan for finishing fluffy tail feature, when you realize that the super-awesome lowercasing you just finished isn't in your hop_hop codebase. No problem: fossil merge foo_5.4.3; [check work for conflicts, nice importing]; fossil ci -m import lowercase excellence from [foo_5.4.3] Now, pick up your partial fluffy tail implementation: fossil stash pop (pops last stashed item like a stack operation), and you're ready to finish your interrupted coding and finish bunnifying. As you finish coding and commit, your boss comes up and says: What have you been working on these last 3 weeks? I'll show you, you say! fossil server [Open Firefox or opera, or chrome, etc], http://127.0.0.1:8080/ You are taken to the Foo Project Repository homepage, and from there you browse the timeline which has a pretty layout of each commit, each branch, each merge, each tag... Your boss is impressed. I'm impressed. But I want to give you some feature requests we've collected from clients. Would you like them as a crumpled collection of post it notes, or some other format? You say: Point your IE4 browser to 192.168.0.99:8080/, log in as superboss like I showed you, and add each item as a feature-request ticket, so we can all see the requests, and their state, and append notes to each feature as necessary. OK, says your boss, a glob of post it notes trying to break out of their pocket
[fossil-users] New user request
Hello Fossil Users, I'm new to fossil and getting more involved in software development work after a significant break doing non-development IT work. I've started using fossil for some professional work and all my personal projects. I love the design and simplicity of fossil. If a few of you could take the time to summarize your workflow with fossil, from starting a new project in a green field to the first production release, I would highly appreciate it. I know there is not one supreme workflow, I'm just looking for examples. I understand fossil's basics, but the meaning and function of some commands are still illusive to me. I would also like examples of what you do through the project's lifecycle, including the creation of branches (like a test or experimental branch). If you think of any things that confused you or you changed over time, please share that. If you know of a blog post or another write-up that fits this description, please point me to it. Thanks everyone. Regards, Sam ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
