[fossil-users] Feature idea: Mailing lists / discussion forums
I know this is a bit I want a pony, but it occurs to me that the one thing Fossil lacks as everything you need to coordinate a software project in one little executable is a mailing list manager. I know we could fit a Web forum in there relatively easily (just, y'know, all the work producing a usable user interface and that). But I find web forums less usable than mailing lists :-) Adding an NNTP interface would be possible, by making it work like fossil server. People like me who run a lot of fossils from one server could run them on funny ports and have a master NNTP server peer with them all and presenting a public interface on the usual port. NNTP is cool, and would save us from having to write a user interface, but asking users to set up an NNTP client might be a stretch. An email discussion list is the de-facto standard for open source collaboration, and it would be possible to build one into Fossil - perhaps by giving it a post command that reads in an email from stdin so it can be hooked up to mail pipe, and sending emails out to a configured SMTP server. Mailing list subscriptions could be handled as part of the existing user database. No matter what interface to the discussions is available (or a combinatoin of the above), fossil ui/server could provide a browsable archive, and it'd be nice to be able to sync the discussion archive (although list admins might need to do a lot of shunning of spam). Integration with ticketing (newly created tickets go to a chosen mailing list, and replies to that message become comments on the ticket) would be nice, too. What do people think? I have a bunch of open source projects in fossil repos, and it's great that fossil handles the web hosting and ticket tracking and source control, but one of them is starting to need a mailing list, and it seems strange to have to set up a separate thing when everything else is built in! ...also, a fossil IRC bot that notifies the channel of new tickets and commits, and responds to ticket/commit IDs with a one-line summary would be nice too, but I can't have a pony AND a unicorn ;-) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital 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] Examples of public Fossil repositories
On 02/01/15 14:34, Richard Hipp wrote: I'm trying to compile a list of interesting public Fossil repositories. My list currently includes: http://www.fossli-scm.org/fossil/ http://www.sqlite.org/src/ http://www.eagle.to/cgi-bin/eagle/timeline http://core.tcl.tk/tcl/timeline http://www.androwish.org/ http://netbsd.sonnenberger.org/ And, of course, all of the repos on http://chiselapp.com/ Are there any others that I should add to the list? https://www.kitten-technologies.co.uk/ may be of interest to you; it's where I host my multiple open-source repos - all with a scripting system (see https://kitten-technologies.co.uk/project/kitten-technologies for the repo hosting THAT) that keeps them all skinned the same. And custom CSS/navigation. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital 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] fossil for web site maintenance [was how to use git to lose data]
On 06/09/14 17:03, Richard Hipp wrote: I'll let Scott answer the specific question. But I just want to remind Miles of the Embedded Documentation feature of Fossil (http://www.fossil-scm.org/fossil/doc/tip/www/embeddeddoc.wiki) and that the main Fossil website including all of the on-line documentation is really just a running instance of Fossil serving the Fossil self-hosting repository. (All of the main website, except the Download page, that is.) I have a related kind of setup at https://www.kitten-technologies.co.uk/ The top-level site is static HTML (but generated via scripts from master content in a fossil repo). However, there are a number of fossil repos for different projects, which are invoked via fossil-as-cgi. https://www.kitten-technologies.co.uk/project/kitten-technologies is the project that generates the master site, which includes the cgi thingies! Eg, /project/kitten-technologies itself comes from https://www.kitten-technologies.co.uk/project/kitten-technologies/artifact/cdeb6789a25bed09afebb6c4f8577a5fc00ad349 And I've hacked the CSS around like crazy to all refer to the central stuff. Per-repo stuff like the skin gets rolled out from the central configuration by a script. It... works! And keeps down the maintenance cost for me of a heap of fossil repos for my crazy open-source outpourings. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital 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] Anecdote regarding permissions tracking in Fossil
On 07/10/13 23:27, Joseph R. Justice wrote: On Mon, Sep 23, 2013 at 7:05 AM, Alaric Snell-Pym ala...@snell-pym.org.uk mailto:ala...@snell-pym.org.uk wrote: I've written a backup/archival tool based on content-addressible storage, and a common question people ask is So why don't I just put my home directory/entire filesystem in git, then?, and I have to raise this aspect of the quite different goals between backup and source control :-) I note that there are people who *do* put their home directories, .rc files, etc under source control. (IIRC, I've read stories in, like, Linux Journal, lwn.net http://lwn.net, blog stories, etc.) I have the distinct impression that, often, at least part of the reason for doing this is that the user has multiple systems they regularly use, and they wish to keep the personal configuration details and I suppose also the personal data stored on/for for each system as consistent between systems as is reasonably achievable to achieve. I do that with a fossil repo that I check out in ~/alaric, which .emacs, .bashrc and a few others symlink into. ~/alaric/bin goes on my PATH, etc. But it keeps it all locked away in one subdirectory, and doesn't mean I have a very cluttered fossil extras. ABS signature.asc Description: OpenPGP digital 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] Anecdote regarding permissions tracking in Fossil
On 08/10/13 01:24, Matt Welland wrote: What (D)SCM's have that backup systems do not is a way to intelligently update files in the managed area. I.e. backup systems do not have a concept analogous to fossil update so they cannot gracefully patch in changes from some other time or location. What backup systems have that SCM's generally do not is capacity. Neither fossil nor git do well with 100's of thousands of files and terabytes of data. Also most backup systems preserve special files, named pipes, permissions and sometimes hard links. FWIW, I think there's a lot of common logic that could be shared between backup systems, archival/document repository systems (a somewhat empty category outside of huge enterprise environments), and SCMs, with relatively minor differences in high-level organisation, user interface, and deployment architecture... The obvious place to start is in sharing the backend blob storage, and standardising the storage paradigm for files and directories into it; then, at least, you'll get de-duplication between the source files in your SCM repo and the checked-out copy of it in your home directory that gets backed up to a shared storage area... For long term archiving I currently use bup. I'd rather use Alaric's Ugarit but it doesn't work on my system right now and I haven't had time to track down the problem. Recent bug hunting escapes in the Chicken Core may have fixed this, by the way - I need to retest a bunch of stuff myself to see if any of the problems I was seeing persist! However most important of all is using fossil for almost everything of value. Here I break the rules and use the tool for both revision control, backup and sync between systems. The purists are recoiling in horror but it works for me and I love it. I did the same thing with Monotone for years with great success. The distributed SCM model is heaven and fossil is a wonderful implementation of that model. I concur. I put everything that matters into fossil (or git or svn or whatever for projects controlled by others with different tastes), to get syncing between machines, sharing between people, and revision history for information and safety in case of user error. This also offers some protection against accidental zapping of the files themselves, but I still like my cron-jobbed daily snapshot backups, as they'll catch any uncommitted work I have! ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital 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] Anecdote regarding permissions tracking in Fossil
On 19/09/13 20:38, B Harder wrote: And that's why we 1) trust our good judgment, the judgment of our fellow fossil developers, and discuss these sorts of things rather than blindly doing what git does 2) don't conflate a version controlled repository with a release. I've written a backup/archival tool based on content-addressible storage, and a common question people ask is So why don't I just put my home directory/entire filesystem in git, then?, and I have to raise this aspect of the quite different goals between backup and source control :-) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital 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] Memorable names for ticket IDs
On 07/09/13 23:43, David Given wrote: OTOH, thinking about the actual use case for these, I'm not sure there's going to be that many situations where someone needs to remember an entire unambiguous hash. The main use case I'm thinking of here, which is where someone from work comes over to my desk and says 'So, about bug 7188...' and I say 'huh?'. I want memorable bug names so that *I* can disambiguate them in my rather faulty memory. So someone saying 'So, about bug we-choo-fa...' is much more likely to get a coherent response from me than 7188. OTGH I'd still rather they referred to it as MISTER SHERIFF simply for cool value! I concur. I think the memorable names are great for spoken usage around the office, and even when copied and pasted into emails, you'll be more able to look at the name and remember Oh, that's the bug about the core dump when you pass -v than if presented with a hex hash; you'll be less likely to have to look it up. Also, tickets for feature requests rather than bugs automatically give things code names, reminiscent of all these NSA project names Snowden's leaked. BULLRUN, CHEESY NAME, etc :-D Now, how apart names for commits, too? This bug was introduced by commit ABSENT FRIEND TROUSERS... ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital 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] New option --keep, and setting keep-glob for fossil clean
On 14/05/13 16:11, Jan Nijtmans wrote: I think you will like this. I do! [snip] Feedback appreciated! I *love* it :-D 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] Fossil vs. Git/Mercurial/etc.?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2013 05:12 PM, Richard Hipp wrote: Might that be a useful approach for Fossil, too? If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. Yep; that hides all the private branch history into the private repo, though - what I'm talking about *looks* like that but has the history available to everyone if you expand the commit by clicking on a [+] in the web UI or some such. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDqsj8ACgkQRgz/WHNxCGo76ACdF0rjW4NqXpNFSR8Z4gdItTHF m/MAn2nj/pIFIXaAuSYbL5m+DHO2LpSs =bGDp -END PGP 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] Fossil vs. Git/Mercurial/etc.?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2012 09:33 AM, Nico Williams wrote: I'm very glad you mentioned this. I really would like git rebase (and any equivalents in other VCSes) to add an empty commit whose message contains: the old base commit hash, the new base commit has, and the rebase recipe (i.e., the pick/squash/fixup/edit/... instructions, including the commit hashes of dropped commits). That reminds me of a discussion I had with a dyed-in-the-wool git fan, of the make the history beautiful camp, who was a fan of making lots of tiny commits during development but then squashing them into a single neat patch to go onto the trunk. I was nervous about the history-loss this created, and one idea that I suggested as a compromise between our positions was a special kind of merge commit in the history that looked like a single commit containing the entire branch as a single patch in the UI, rather than like a merge of the topic branch containing the work. This would appear like rebasing the topic branch and squashing all the commits, but was actually just a merge in all respects other than how it looked in the timeline. Might that be a useful approach for Fossil, too? ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDluxYACgkQRgz/WHNxCGp4HQCghgq9q1JuvzndW3tlkj0zXNS1 2XsAn0GS6hdXXtvj0C7aXBWvoDYDidjL =S55G -END PGP 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] comparison with Git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/09/2012 11:19 AM, Remigiusz Modrzejewski wrote: Actually... No. Fossil, with it's monolithic single-app design, is relatively hard to both extend and embed. Also, seeing how Natacha's attempts at providing a much-requested feature were ignored, it can be hard to influence. Is it time to fork Fossil? Richard has his own priorities, and if there's enough people who'd like to see Fossil go in a different direction, it would be perfectly honorouable for a fork that served different priorities to form in an amicable manner. As much as possible should be contributed to the original Fossil and then pulled into the fork, but the fork can accept direct contributions that Original Fossil won't. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlB0AVgACgkQRgz/WHNxCGr2EQCfd0+wJw2Ox5kHNEzZuFJO96me vEwAniXvrCjgaD5DgBVOEhhibnQIcOhD =QgoL -END PGP 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] The future of markdown-in-fossil
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/2012 10:46 AM, Jan Danielsson wrote: On 08/03/12 15:42, Stephan Beal wrote: [---] Another consideration here is that the wiki has kind of fallen out of use, [---] I don't know that that is true. The only proof of this I have seen prior to this thread is that at times it's mentioned that the fossil repository uses embedded wiki rather than the built in wiki. Hear hear. All that means is that wikis aren't the best way of handling documentation for an open source project; it is indeed better to version documents as part of the source code tree. However, wikis are ideal for user-contributed material that's attached to an open-source project, and documents relating to that project with a scope beyond a particular revision of the project itself. Also, wikis are editable in the browser, making them far more accessible for contribution than embedded documentation. I have a fossil repo for my house. The wiki is served up from the home fileserver and contains recipies, useful information for visitors, and stuff like that. I have tickets for DIY projects and things we need to buy. And the filesystem repo contains important documents pertaining to the house. I've set up web permissions so that only logged-in users can get beyond the wiki. On the other hand, my open source projects at http://www.kitten-technologies.co.uk/ are all cgi-hosted Fossil repos (the front site itself is static HTML, but generated from stuff in a fossil repo - see http://www.kitten-technologies.co.uk/project/kitten-technologies and a typical project such as http://www.kitten-technologies.co.uk/project/ugarit), all heavily based around embedded documentation; I'll do things with the inbuilt wiki if a user community develops around any of them and non-contributors seem to want to contribute stuff! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAhJ5kACgkQRgz/WHNxCGqk5gCfdlORZHYj1qJ2aWMMCHI8Tbcc F9YAn2eR8n+sWgPpHaUmIpVW2pSlpBkf =lBZf -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Revisions between two commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! A friend asked me how to get Fossil to produce a series of patch files on disk, one per revision within a range, like git format-patch does. I found it possible to get a list of revisions between two arbitrary commits using an UGLY HACK, namely fossil bisect good at one end and fossil bisect bad at the other end, then fossil vlist produces reasonably parseable output. fossil timeline's output is far too human-centric and doesn't let you specify arbitrary start and end revisions! Am I missing a trick? Should I write a patch for fossil to add show me the revisions between X and Y in a simple format (including error handling for cases where there is no direct path from X to Y!)? ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7U1WgACgkQRgz/WHNxCGqV6ACbB7nRj3SDxKVviBMdqRUqQaEE eXsAoIGZfxgD6vcwk97nCDT7qecuRUyt =OwCO -END PGP 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] Revisions between two commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2011 12:57 PM, Richard Hipp wrote: See the test-shortest-path command. It probably does what you want. So the question becomes: should we promote test-shortest-path to be a supported command? Perhaps... but as this is most useful for scripts that build on top of fossil, perhaps the issue is more one of whether it should be exposed via the JSON stuff (if it isn't already). Which, I gather, is accessible from the CLI as well as via HTTP, right? ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7U2XcACgkQRgz/WHNxCGo2aACfeQM3knrNI3bC6LeDMPctRhj5 qWkAoISnGhWqfOnHZssKjYAH/79eLbhe =7dzu -END PGP 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] Veracity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2011 03:52 PM, Stephan Beal wrote: Could a new special tag be used to implement lock-like behaviour? By special i mean a reserved name (or name pattern, e.g. locked-by-USERNAME). Tags apply to whole commits, though, not individual files. Perhaps lock/unlock actions should be implemented as a special commit that changes no file data, but changes a locked by foo property of the files in the manifest. Making them slightly funny commits would mean they appear in the history and are appropriately replicated, scoped to branches, and all that jazz. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6e54UACgkQRgz/WHNxCGoJpACcCb2CEFRnyD3QFLJF6cBqLpGm UHUAn2evRfMColj1Bi739+VrlDQXsj5l =PUux -END PGP 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] Listing artifact IDs for shunning?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/05/2011 08:19 AM, Eric wrote: Not altogether a bad idea but, as you might expect, I would worry about how to select the time interval, and I think the system should insist on keeping a comment about the deletion. Perhaps shuns should be proper objects, like commits, that end up as sentinel objects marking the shunned objects; so if you shun a version of a file, when you try and check that version of the repository out, it'll encounter the shun while traversing the directory tree and will print out: login.c - SHUNNED accidentally checked in the test server's login password that I hardcoded for a test ...and login.c will be missing. This will involve a lot of extra cases to check; whenever we fetch an object from the repo and process it in some way, we'll need fallback cases for if we get a shun. But I hope we already have those checks in place for the error that will arise when trying to get an object that is missing because it was shunned! Eric ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6MIUQACgkQRgz/WHNxCGok3ACfWXKfdtE+950mWpA/IuDStsYR IMYAn1GqjNGQ22sDEDP4Bt8fxHIgPGus =/T1N -END PGP 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] Protection against timing attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 07:57 PM, Dmitry Chestnykh wrote: I posted a link about this concern: http://rdist.root.org/2010/01/07/timing-independent-array-comparison/ This is also why introducing a random delay to mask the timing doesn't really solve the problem (but it does make the attacker need more samples to average it out)! People who make crypto smartcards have to really worry about issues like this, as the smartcard will be in the hands of attackers, who will feed it multiple carefully-crafted authentication requests while monitoring response time, power consumption, spikes on the power lines caused by transistor switching... and maybe even feed the same request through again and again while bombarding the card with radiation to try and cause random bit flips within its circuitry and seeing how this affects the result. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6Fj0EACgkQRgz/WHNxCGpR4gCfbcjC9EeCTz9KNobUEl+o+Q3B n/IAn0qXg0EUwAiGC9zAO5o5Quhm63B2 =mEdU -END PGP 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] authentication in JSON: anonymous vs. guest user
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/12/2011 05:07 PM, Stephan Beal wrote:
On Mon, Sep 12, 2011 at 5:50 PM, Richard Hipp d...@sqlite.org wrote:
Anchor tags in HTML are just one mechanism for providing hyperlinks. In
JSON, you could just as easily invent an alternative mechanism. Perhaps an
object:
{
LinkType: Next,
URI: http://www.fossil-scm.org/fossil/json/timeline?first=12345
}
That looks good.
@Anyone who's got ideas for how to best represent stuff like that, feel free
to chime in. This doesn't just apply to the timeline, but potentially to any
page which presents detail links (as opposed to the nav links in the page
header and whatnot).
I'm not sure if LinkType is necessary as it'll presumably be implied
by context, but it might be worth including JSON and human-HTML versions
of each URL, like so:
{
...stufff about a commit...
parents : {
hash of parent commit : { json : http://..json;, html
: http://...html; },
hash of parent commit : { json : http://..json;, html
: http://...html; }
}
}
- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5vFKQACgkQRgz/WHNxCGpczQCeMQa3JMjYxB67BefHXfVPfDUB
dGEAnRBKSR1RX8imx0DpgJNeaDX7TXag
=D42+
-END PGP 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] authentication in JSON: anonymous vs. guest user
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/2011 04:24 PM, Ron Wilson wrote:
On Tue, Sep 13, 2011 at 4:30 AM, Alaric Snell-Pym
ala...@snell-pym.org.uk wrote:
by context, but it might be worth including JSON and human-HTML versions
of each URL, like so:
{
...stufff about a commit...
parents : {
hash of parent commit : { json : http://..json;, html
: http://...html; },
hash of parent commit : { json : http://..json;, html
: http://...html; }
}
}
If the difference between a JSON and an HTML URL is just the .json (or
.../json/...), then a single URL should be sufficient.
That depends if you want to promise forever more that said difference
will hold, and expect clients to do their own regexping to exploit said
promise :-)
ABS
- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEUEARECAAYFAk5vyBwACgkQRgz/WHNxCGoBswCgj82M+ZNDR1ZHz2u1vbl5/erR
a9kAl34BkFjg+XaTbczOoOV/UZRk8rI=
=05r8
-END PGP 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] Draft doc for JSON/REST Fossil interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/08/2011 09:27 PM, Stephan Beal wrote: On Thu, Sep 8, 2011 at 10:11 PM, Martin S. Weber martin.we...@nist.govwrote: On 09/08/11 16:01, Stephan Beal wrote: 1) A split between library and app. i.e. libfossil vs. the fossil server/cgi/shell app(s) I couldn't agree more. One of my goals (luckily no milestone I'll ever be evaluated against) is to do that. i can promise you that herculean effort was not a hyperbole! That said, i would be happy to assist you in this, and i think it can be done incrementally, taking a long time to do but having no outwardly effect on the apps. What will this mean for the famed single binary, just copy it into your PATH effect? Will said single binary still exist and statically link libfossil into itself, but also have a libfossil.so available alongside? ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5pz4sACgkQRgz/WHNxCGrFLACcCz9R9FPxtRvjJOxlX8FtkL9q 3C8An2ZHKw8QupPr2NUxZxcB+LcuY0uu =acGv -END PGP 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] CR/NL warning in .pdf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2011 11:33 AM, Remigiusz Modrzejewski wrote: On Sep 6, 2011, at 1:18 AM, Konstantin Khomoutov wrote: The problem is while PDF is considered to be a binary file (and it indeed usually contains compressed regions, it does contain ASCII header and footer (I think it's its PostScript heritage), so it can be considered to be a plain ASCII file by any tool which does not look for its special magic character sequence (in the first line of the header). Probably Fossil does not do that. That's a bit funny, because the pdf files contain a single \r\n ending not within a compressed region. Converting that to \n doesn't seem to break anything, but did I just kill a kitten? Yes. PDF files contain tables of contents that point to byte offsets within the file. Changing line endings like that removes a byte, which shifts everything. Some readers *may*, if a ToC entry points to something that doesn't look like what they expect, search about a bit to find the header. Some might not. Such PDF files are unreliable! And the more important question: should we make fossil to treat all pdf files to be binary? Yes. They are binary files. The fact that they contain lots of ASCII text is misleading - they can't be treated as text files. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5l96kACgkQRgz/WHNxCGpk/gCfcOkct8f1WdqYxbqnDtDTE1qB Fp0An2IjFOw5Yz5UvvTv1zt8PlCX3CHx =bIsi -END PGP 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] Diff after move
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/01/2011 06:17 PM, Stephan Beal wrote: Regarding the comparison with git: git tracks changes differently, and can even tell you that a given commit moved X lines of code from file A to file B (it's pretty f-ing smart that way). Fossil tracks whole files only. i unfortunately don't understand the internal details of how fossil tracks lineage and changes well enough to explain/justify fossil's behaviour, but this topic as come up before and IIRC (which i won't guaranty!) the consensus was that fossil's design doesn't immediately lend well to solving that. Or maybe it's just that nobody's pitched in yet to do it. AIUI, both git and fossil store each commit as a full tree; such cleverness is purely in the hands of the diff algorithm... - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5gsC0ACgkQRgz/WHNxCGqF2wCfaB8KJO4x6qH5i2RD5IgVt0Iw zXUAnRdpYBLMjRZpyJ0L7YKHFIsrOczM =gLts -END PGP 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] New features for merging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/2011 11:47 AM, Ben Summers wrote: Richard has kindly indicated he is probably willing to merge the changes in the ben-testing branch if the community has no objections, after being asked for any suggestions on improvements. The features look useful, in my opinion; I'll try building your branch and playing with them personally to see about all those usage messages and the like! The empty dirs one is a bit of a hack, though; would it be a good idea to merge in everything *but that* for now? Indeed, does it need to be part of Fossil - one could just have an empty-dirs file and a script you run after checkout (dare I say hook? Nah, best not...) that ensures they all exist? ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5FPp8ACgkQRgz/WHNxCGopeACdGhIRMgTAD5pGOMDoUxvvo1gv WAEAoIy5yZ+yiwA1YSBNAJ8Ye7TnVxq/ =ESze -END PGP 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] New features for merging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/2011 07:10 PM, Joshua Paine wrote: On 8/12/2011 1:50 PM, altufaltu wrote: 1. Versioned settings: I'd prefer having all settings in a single text file with name=value kind of one-setting-per-line format (although I don't mind a value spanning multiple lines for readability) rather than one file per setting. I thought this at first, too, but one file per setting makes it easier to manipulate with other tools, and it makes it easier to get an idea what happened from the commit log. Aye. My fossil extras .fossil-settings/ignore_glob brought a smile to my lips. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5Ff/QACgkQRgz/WHNxCGol5wCfeL2HcMT8J+/hvY0/0ljyFydW Q/cAn3aPay3VfvoQLZnK/p1iidTEfaBD =oPGM -END PGP 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] content does not mach sha1 hash
On 08/09/2011 02:16 PM, Richard Hipp wrote: da39a3ee5e6b4b0d3255bfef95601890afd80709 is the hash for a zero-length object. Something is clearly messed up. As a general rule of thumb, whenever mysteriously zero-length files crop up, the first thing I check is whether anything's run out of disk space at any point... ...shortage of disk space can result in files being creatable (taking up already-allocated space in inode tables and directory entries) but then not being writable (leading to zero-length files). 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] Automatic branch color selection. Was: Question on short-lived branches in fossil
On 07/23/11 01:06, Ross Berteig wrote: I get the impression that your calculation picks hues that are too close together... it might be better to quantize it more to keep them further separated. I think that'll just force currently-similar colours to be the SAME colour, by reducing the space of available colours... ...allowing some variablity in S and V might be a better idea, to expand the space. Since the text color is controlled by the CSS which fossil almost certainly does not parse, you probably would need a separate configuration option somewhere to choose between dark and light automatic color choices. Perhaps the configuration could list max and min values for H, S and V, and have Fossil pick a colour within that region. The default would allow all of H and a small range of pastel-oriented S/V. People with a bold corporate colour scheme could restrict H somewhat if blue just really clashed with their headers! :-) 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!
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] Actually Removing A Garbage Ticket
On 04/14/11 15:06, Richard Hipp wrote: Shunning the ticket should work. But shunning doesn't take effect until you run fossil rebuild. Did you perhaps leave out that step? I can understand the need for a 1-click ticket shun and will consider requests for such a feature. I tinkered with this myself (in fact, I cloned fossil.fossil and was tinkering with it, then wanted to kill my junk tickets), and came away with the impression that a ticket with any history ends up as a heap of artefacts, all of which needed to be traced down and shunned (which was tricky). I ended up just re-cloning fossil.fossil... I'm pretty sure I did do fossil rebuilds, but I may be wrong. Mists of time and all. Soddit, let's try it: I've made a ticket with uuid 868f607aa491dc53c265d3fb011813b60d4f9f13 ...ok, I've shunned that, and rebuilt, and the ticket still appears in the All Tickets report, even without having had any history added to it; I just made the ticket. What giveth? 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] Actually Removing A Garbage Ticket
On 04/14/11 15:23, Alaric Snell-Pym wrote: What giveth? PS: I'm testing that on: This is fossil version [84e755e213] 2011-03-16 11:19:14 UTC 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] Actually Removing A Garbage Ticket
On 04/14/11 15:28, Alaric Snell-Pym wrote: On 04/14/11 15:23, Alaric Snell-Pym wrote: What giveth? PS: I'm testing that on: This is fossil version [84e755e213] 2011-03-16 11:19:14 UTC Updated to: This is fossil version [289ea2a9b6] 2011-04-14 14:23:52 UTC ...and it still does the same, plus still exhibits 19be0265ff (wrong output from the rebuild button in the shun page) ;-) 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] tracking cherry-picked merges?
On 04/11/11 19:11, Richard Hipp wrote: Fossil does not (currently) record any information about cherry-picks. I did make an extension to the file format to allow Fossil to do this in the future. But I only made that extension this year. If any information is recorded about cherry-picks, people with older versions of fossil won't be able to read repositories that make use of this extension. So I need to wait until everybody has upgraded to a more recent version of Fossil before I add the code to actually record the cherry-picks in the manifest files. Good stuff! I guess the use cases are: 1) Drawing nice (dotted? grey?) arrows in the ui timeline to show cherry-pick mini-merges cleanly 2) Smarter merging when some of the content has already merged (either way) due to cherry-picks It strikes me that, for the latter, it might be good if cherry-picks went into their own commits rather than potentially mingling with other changes (or even with each other; I'm not sure). What are people's use-cases for cherry picks, out of interest? I tend to use them (in git, at least) for pulling in some of a contributer's contributions but not others, in which case the merge problem is theirs when they merge my latest trunk into their branch. 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] tracking cherry-picked merges?
On 04/12/11 14:37, Richard Hipp wrote: On Tue, Apr 12, 2011 at 9:17 AM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote: What are people's use-cases for cherry picks, out of interest? Back-porting important bug fixes from trunk to an historical version branch. For example: http://www.sqlite.org/src/ci/e8177e0149 Also good. I tend to just wholesale merge trunk in, but if that's hard as there's a messy change, cherry-picks would be sensible too. 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] tracking cherry-picked merges?
On 04/11/11 16:15, Stephan Beal wrote: Hi, all, Last weekend i finally found the opportunity to use the --cherrypick option of the merge command (and it saved me a lot of tedious effort in the form of manual merges). i notice that the timeline does not appear to track such merges. Is there a way to see such merges after the fact? Since i couldn't find one, i started adding the cherrypicked IDs to my commit messages (thank goodness i can edit them after the fact), but i'm curious if i just overlooked something. It would be nice to record this, yeah - merge --cherrypick seems to just apply the diffs of a particular merge to the working copy (and add any new files as ADDED_BY_MERGE, it seems). I've just done an experiment, doing three commits that add new files on a branch, cherry-picking the middle of the three back to the trunk (with a commit message saying so), then merging the trunk into the branch - it worked, but complained that there was no common ancestor for the file added in the cherry-picked commit. I didn't have time to try it with actual content that gets merged, but I'm hoping the system realises it's got some changes already present due to cherry-picking and doesn't explode about conflicts if so... 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] Fossil on Hammer Principle
On 03/24/11 20:29, Stephen De Gabrielle wrote: Cute. It seems pretty accurate. IMHO http://twitter.com/DRMacIver/status/53029890634682369 http://twitter.com/DRMacIver/status/53030039134023680 *whistles innocently* The pros and cons now at: http://versioncontrol.hammerprinciple.com/items/fossil ...look quite fair, though. Pluggability and GUI tools are just a matter of time, I reckon. Suitability for large teams, without costing simplicity for small teams, will require more thought. The first thought that comes to mind on that point for me is git's support for dealing with shipping patches around, which I think Zed posted about an approach to recently (importing patches into your stash?); I'm not sure what would happen when the person who wrote the patches then pulled from your repo after you'd applied them, and tried to merge. rebase might end up sneaking into the system via the back route. S. 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] Fossil social networking
On 03/29/11 10:16, Paul Ruizendaal wrote: That being said, I'm opposed to bloat and function creep in Fossil. Perhaps what is needed is a small companion to Fossil that acts as a hub server. That companion could be a webserver / sqlite / javascript combo, which either reads the database files direct, or calls out to Fossil to perform its operations. Hrm. Why embed a language for hooks at all? svn/git/etc seem to have managed without... this makes hooks platform-specific (shell scripts are fine for Unix users, less fine on Windows), but as the hooks would presumably be repo-specific rather than part of the global state, is that a problem? Paul 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] Basic FossilHub functionality works
On 03/28/11 07:43, Bill Burdick wrote: In order to watch a repository, that repository has to a small (1K) HTML asset which provides access to the timeline feed (using HTML5's window.postMessage) -- this can just be attached to a wiki page; it doesn't have to be in a project branch. The main body of code, however, is in the account repository, in JavaScript and served up using a Fossil doc URL. Again, this did not require any changes to the Fossil executable. It's awesome that you can do this without modifying Fossil. I dunno if the social networking stuff will take off or not... but the fact it can be implemented like this is amazing! Well done to you and to Richard for making Fossil flexible through simplicity ;-) [What a geeky answer. Dunno about the social stuff, what an awesome gadget ;-)] Bill 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
[fossil-users] Fossil on Hammer Principle
Hello! Hammer Principle is a whimsical site where people can rank contentious things on various axes, and it then generates overall scores for stuff. They added version control systems lately, and Fossil's one of them: http://versioncontrol.hammerprinciple.com/ However, as of the time of writing, only two people have expressed opinions on Fossil (and I'm one of them). Let's fix that :-) Enjoy, 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
