[fossil-users] 'Contact Info' field in user registration/editing screen
Hi, is the 'Contact Info' field (set in user registration/editing screen) available for hte current user via the ticket (and other) templates? > This bit of code will get rid of the "email" field entry for logged-in > users. Since we know the user's information, we don't have to ask for > it.*NOTE: it might be good to automatically scoop up the user's email and put > it > here. [1]* > Cheers, Stephen [1] http://www.fossil-scm.org/index.html/doc/trunk/www/custom_ticket.wiki -- -- Stephen De Gabrielle stephen.degabrie...@acm.org Telephone +44 (0)20 85670911 Mobile+44 (0)79 85189045 http://www.degabrielle.name/stephen ___ 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] WHY IS FOSSIL REMOVING ALL MY CODE!
On Sun, 22 May 2011 06:50:56 -0400
Richard Hipp wrote:
[...]
> > >>> Does anybody have any other suggestions on how to prevent the
> > >>> lose of uncommitted work?
> > >>
> > >> Maybe not suggestion to prevent losing of uncommitted work, but
> > >> I'm thinking about using 'stash' in such situation.
> >
> > Perhaps Fossil could do this automatically. Whenever an 'update'
> > would change any locally modified file, Fossil could stash the
> > changes away first and inform the user.
> >
>
> That's sort of what "fossil undo" does. Except it only stores the
> most recent change. You are suggesting an "auto-stash" that keeps
> backups at each change, and stores them in a visible place such as
> the stash. An interesting idea...
>
> Would we purge the auto-stash on a commit? Or just let it grow until
> the user manually purged it?
This looks like Git's "reflog" functionality [1].
The basic idea of the reflog is that its entries reference commit
objects which could otherwise be "lost" (for instance due to the current
branch's HEAD having been forcibly repositioned to point to another
commit ("hard reset" in Git speak)).
1. http://www.kernel.org/pub/software/scm/git/docs/git-reflog.html
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WHY IS FOSSIL REMOVING ALL MY CODE!
On Mon, May 23, 2011 2:44 pm, Konstantin Khomoutov wrote:
> On Sun, 22 May 2011 06:50:56 -0400
> Richard Hipp wrote:
>
> [...]
>> > >>> Does anybody have any other suggestions on how to prevent the
>> > >>> lose of uncommitted work?
>> > >>
>> > >> Maybe not suggestion to prevent losing of uncommitted work, but
>> > >> I'm thinking about using 'stash' in such situation.
>> >
>> > Perhaps Fossil could do this automatically. Whenever an 'update'
>> > would change any locally modified file, Fossil could stash the
>> > changes away first and inform the user.
>> >
>>
>> That's sort of what "fossil undo" does. Except it only stores the
>> most recent change. You are suggesting an "auto-stash" that keeps
>> backups at each change, and stores them in a visible place such as
>> the stash. An interesting idea...
>>
>> Would we purge the auto-stash on a commit? Or just let it grow until
>> the user manually purged it?
>
> This looks like Git's "reflog" functionality [1].
> The basic idea of the reflog is that its entries reference commit
> objects which could otherwise be "lost" (for instance due to the current
> branch's HEAD having been forcibly repositioned to point to another
> commit ("hard reset" in Git speak)).
>
> 1. http://www.kernel.org/pub/software/scm/git/docs/git-reflog.html
Well, not really. This discussion has been about protecting files in a
working directory, whereas the git thing is about unreferenced commits in
the repository being protected against garbage collection! Fossil has no
such thing as an unreferenced commit and doesn't ever lose anything from
the repository unless it is explicitly shunned (which is never part of a
normal workflow).
Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WHY IS FOSSIL REMOVING ALL MY CODE!
A multi-level stash could end up performing the one feature of git I like over fossil: that I can do nonsense commits onto a branch I don't push, then "git rebase -i" them into beautiful sense before I commit... I've wondered if that should be available as a feature on fossil's private branches (in effect, when the private branch merges, rather than just being one commit, let it be a user-chosen set of commits with the private branch commits split between them as per specification), but it might be more flexible to let people mess with stashes rather than private branch shenanigans. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ 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] WHY IS FOSSIL REMOVING ALL MY CODE!
Richard's question regarding a multi level undo, and when to purge, got me thinking; and I apologize for posting mid - thought stream ... What if fossil kept track of all the commands issued that change either the repository or the working files. Obviously, it already does this at some level (commits and merges); in the case of a revert (or even an update), it would save the affected files, perhaps by creating an automatic branch. Fossil now has the files but also the complete command path to reproduce a particular scenario, which would help in debugging. This would really fill any gap in the stated goal of never losing any work; not only committed work, but also work in progress. From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Richard Hipp Sent: Sunday, May 22, 2011 5:51 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] WHY IS FOSSIL REMOVING ALL MY CODE! On Sun, May 22, 2011 at 12:04 AM, chi wrote: Ron Wilson schrieb: > On Sat, May 21, 2011 at 4:29 PM, Gour-Gadadhara Dasa wrote: > >> On Sat, 21 May 2011 14:32:34 -0400 >> Richard Hipp wrote: >> >>> Does anybody have any other suggestions on how to prevent the lose >>> of uncommitted work? >> >> Maybe not suggestion to prevent losing of uncommitted work, but I'm >> thinking about using 'stash' in such situation. Perhaps Fossil could do this automatically. Whenever an 'update' would change any locally modified file, Fossil could stash the changes away first and inform the user. That's sort of what "fossil undo" does. Except it only stores the most recent change. You are suggesting an "auto-stash" that keeps backups at each change, and stores them in a visible place such as the stash. An interesting idea... Would we purge the auto-stash on a commit? Or just let it grow until the user manually purged 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] slightly OT: an alternative wiki for fossil repos
Hello, fossilers, The past six weeks or so i've been hacking and re-hacking a custom wiki back-end which runs as a CGI and serves wiki pages in arbitrary wiki syntaxes (as JSON objects which hold the page content and other metadata), for rendering on the client side. The original goal of the project was to port over some of my more active fossil wikis because i strongly prefer the Google Code wiki syntax over any other wiki syntax. (i write absurd amounts of documentation, so i'm a tiny bit picky about what tools i use to write with.) As of today that backend is hosting 4 wikis, all of which were ported over from fossil: http://whiki.wanderinghorse.net/?page=RealWorldWhikis (Achtung: that whole site needs a Damned Fine Browser. Only tested with Chrome and FF 4.x. "Should work" with FF3.x and other modern, standards-conformant, non-IE browsers.) This page shows a fairly simple approach to porting the pages from fossil to whiki: http://whiki.wanderinghorse.net/?page=HowTo-FossilToWhiki The wikis i've ported over so far went relatively painlessly - i had to clean up a few constructs which confused the GoCo wiki parser, but other than that it was easy sailing. The largest one has 35 pages and requires only about 170kb of server-side storage (an sqlite3 database, though mysql is also supported). Since whiki doesn't support versioning (boo!), the storage requirements tend to stay fairly constant. For those of you who run fossil as a CGI, this might provide an interesting alternative wiki for you. Its main claim to fame is that it doesn't do any wiki parsing - it serves only JSON and the client can do what he wants with it. Thus as long as you have a JavaScript implementation for your favourite wiki parser then you're good to go. A client can potentially support any number of formats (e.g. the above sites render C and shell code using a source highlighter, and can "execute" pages written in JavaScript). The most significant caveat, i think, is that because it's 100% client-rendered, and fetching the pages requires processing JSON fetched via AJAX, it does not degrade gracefully (at all) for "lesserly capable" clients. It doesn't work on a Nintendo Wii or Gameboy DSi, for example, nor on a Nokia e90 phone. Happy hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Odd numbers reported as sent and received
This doesn't look right: fw@deneb:~/src/fossil$ ./fossil update Autosync: http://www.fossil-scm.org/ Bytes Cards Artifacts Deltas Sent: 177 2 0 0 Received:3620 79 0 0 Total network traffic: 322 bytes sent, 2101 bytes received fw@deneb:~/src/sqlite3-doc$ ../fossil/fossil update Autosync: http://www.sqlite.org/docsrc/ Bytes Cards Artifacts Deltas Sent: 130 1 0 0 Received: 538 12 0 0 Sent: 647 12 0 0 Received:8152 23 1 10 Sent:2762 57 0 0 Received: 59240 68 5 51 Total network traffic: 2515 bytes sent, 39285 bytes received Or is compression involved? Then perhaps the last line should read "Total uncompressed network traffic". ___ 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] slightly OT: an alternative wiki for fossil repos
On Mon, May 23, 2011 at 3:25 PM, Stephan Beal wrote: > The most significant caveat, i think, is that because it's 100% > client-rendered, and fetching the pages requires processing JSON fetched via > AJAX, it does not degrade gracefully (at all) for "lesserly capable" > clients. Very interesting project. Thank you for posting about it. I don't know about GoCo wiki syntax, but with most wiki syntaxes, it is somewhat human readable, so being 100% client side rendered is not that big of an issue. Being delivered as JSON is very significant. As I observed before, in the absense of Fossil delivering proper raw wiki source, Fossil does put the content in a div with class='content', so finding the content from Javascript on the client is fairly easy. If the wiki page is contained within nowiki, then the wiki page source is delivered as-is, so a client side wiki rerenderer could then extract the source from within the content division. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Odd numbers reported as sent and received
On Mon, May 23, 2011 at 4:46 PM, Florian Weimer wrote: > This doesn't look right: > > fw@deneb:~/src/fossil$ ./fossil update > Autosync: http://www.fossil-scm.org/ >Bytes Cards Artifacts Deltas > Sent: 177 2 0 0 > Received:3620 79 0 0 > Total network traffic: 322 bytes sent, 2101 bytes received > Sent and Received are uncompressed, but omit the HTTP header. The "Total network traffic" is measured at a much lower level and is an actual measurement of the number of bytes sent over TCP. > > fw@deneb:~/src/sqlite3-doc$ ../fossil/fossil update > Autosync: http://www.sqlite.org/docsrc/ >Bytes Cards Artifacts Deltas > Sent: 130 1 0 0 > Received: 538 12 0 0 > Sent: 647 12 0 0 > Received:8152 23 1 10 > Sent:2762 57 0 0 > Received: 59240 68 5 51 > Total network traffic: 2515 bytes sent, 39285 bytes received > > Or is compression involved? Then perhaps the last line should read > "Total uncompressed network traffic". > ___ > 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] Supporting markwon syntax for wiki
Hi, Is there any thought on supporting markdown as a wiki format for fossil? For information there is a fast, simple and easy to use library (license BSD 2 clauses) that maybe used for that: http://fossil.instinctive.eu/libupskirt/home it is easy to bundle if desired. Markdown is a really simple format that would imho greatly improve the embed wiki of fossil. regards, Bapt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
