Re: [fossil-users] Google code shutting down
On Mon, Mar 16, 2015 at 3:51 PM, jungle Boogie jungleboog...@gmail.com wrote: Yes, this is a great plan. I didn't say it was great or even good. Only that is what we were told to do. Or not be allowed to generate email from the Fossil repos. ___ 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] GitHub question. Was: Git-v-Fossil.
Sat, 14 Mar 2015 14:02:18 +0200 John Found johnfo...@asm32.info: IMO, everything is in reverse. GitHub is not popular, because Git is great SCM. Git is popular because is used by GitHub! Notice that GitHub is not only repository hosting. It is a social network for developers. That is why it is popular. And every SCM used in such popular social network will become popular on its own. It's not just that GitHub dragged Git along to popularity. The real achievement is that it has more or less de-decentralized Git. Putting lipstick on git workflows did certainly help. But I believe their newcomer-friendly tutorials and documentation are underestimated when it comes to GHs success. (Also shouldn't discount free support.) Social network is a nice metaphor. But it's also just a side-effect of having a data silo. Most developer interactions center around the issue tracker. Which is pretty. And often just used as discussion board with ticket numbers. Which is not to say that we shouldn't take a few cues here and there. Mon, 16 Mar 2015 09:45:13 +0200 John Found johnfo...@asm32.info: But, for example fossil can provide some way to connect the stand alone repositories and developers in some kind of distributed peer-to-peer network and to provide some interaction - I don't know - maybe some voting, messaging, clone tracking, collaborative environment, pull requests, whatever will turn a heap of independent repositories into mutually connected developers network. No one is interested, but I will continue a little. :) The first step towards such achievement is to allow all Fossil users to exists in one common username space. OpenID authentication could help to make this without big effort. If there should be more interactivity between Fossil users and repos, then of course a global user namespace would make sense. OpenID might be an option, but has sort of served its time already. It wasn't originally intended as login system even (homepage URL authorization really). And it's not just Google that depreciated it. It's still trivial to implement a consumer. But I'm concerned this would end up being feature creep for Fossil. - Wouldn't discount it though. I'd think for some social network appeal there should be user avatar support first. - Instead of cross-domain authorization etc. Our `user` table has an unused `photo` column for instance. Not sure that's ever going to get used. So perhaps supporting some form of gravatar in /register might be more practical. - Preferrably even a decentralized and non-proprietary variant like Libravatar. That would implicitly yield a globally unique user hash. Another step is to provide some notification mechanism from the cloned repositories to the parent repository - for example, when the user make commit to the cloned repository, Fossil sends notification message to the parent repository. These automatic notifications are not so useful but may serve as a statistics mechanism and as a indicator of the project development. Of course, if the project leader has informations about the changes, he can choose to pull some/all of these changes without waiting the pull request. Even more useful is if the parent repository, notifies the clones about new commits, because the cloned repository might want to merge these changes. But if the cloned repository is not hosted on a web server this can be not easy task. In this case the notification can be made by request from the cloned repository. Networked commit notification sounds like no little effort. :} Theoretically one could already implement basic commit diffs by polling the JSON API of known remotes. However, we don't even have a network graph of forked repositories yet. Which is something that I'd also like to see. I doubt everyone would want to have this automated. But a /admin page (or a TH plugin) for a central registry seems feasible. For obvious reasons a Fossil repo list would work best on ChiselApp, may just require a remote_repositories table and an AJAX endpoint. (Not sure about push/pull requests ala GitHub. That's mostly just gatekeeper syndrome due to gits volatility. Might be a nice gimmick still.) The ticket system can be used as a distributed messaging engine between developers. A global inbox and cross-repo messages wouldn't be difficult. Just needs an agreed API. (Which might even solve itself with web push notifications in the near future. Could just be a skin feature then.) Of course, a distributed social network on top of a DVCS is a little out of scope. But this could just be a TH1 plugin. (And doesn't harm setting up a fx cron job for standard ticket emails etc.) So, going a step back and centralizing it GitHub-style could suffice. - Notification pool on ChiselApp :? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org
Re: [fossil-users] fossil ui not working with recent chrome browser
Hi, On 14 March 2015 at 05:12, a...@gmx-topmail.de a...@gmx-topmail.de wrote: This is what does show the problems for me (on Windows 7): fossil init test.fossil fossil ui test.fossil then use chrome version 41.0.2272.89 m to navigate to e.g. the new ticket page, of which only the summary inputfield and Type-combobox are shown. Same page and setup shows correctly with e.g. firefox. I'm using Fossil 1.32, Windows 7 home premium, Google Chrome 42.0.2311.39 beta-m and Mozilla Firefox 36.0.1. With your above steps, I cannot reproduce what you're describing. Both browsers display the /tktnew identically. Time to rule out some things. -Can you send the repo to anyone? -Can you use a different Windows computer? -fossil init test.fossil on a non-Windows computer and load the repo on your Windows computer, what's it look like? -Try Fossil 1.32 -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] Browser support
On Mar 16, 2015, at 11:15 AM, Richard Hipp d...@sqlite.org wrote: The timeline graph is drawn using JS. Without JS you do not get the very nice timeline graph. I don't see any reasonable way around that. Hi, it’s the resident pro web app developer checking in again. :) There are at least three ways to create the timeline without Javascript. 1. Build the timeline as a dynamic PNG on the server side, then serve the client a URL to that dynamic PNG. This requires libpng or similar, some line-drawing API on top of that (e.g. libgd, SDL, etc.), and ideally a place to cache the generated PNG so it doesn’t have to be re-generated until a timeline update invalidates it. We actually have code doing this, written before the next two options became widely available. We’ll get around to rewriting it RSN. 2. Generate the timeline server-side as SVG, and serve it inline on the timeline page. Of the mainstream browsers with significant market share, only IE8 doesn’t support SVG: http://caniuse.com/#search=svg The only reason there’s still a significant chunk of IE8 out there is that that’s the last version of IE that will run on XP. No developer should still be running an unsupported 13 year old OS on his desktop anyway. 3. Generate the timeline via canvas. Yes, technically this is one of those spiffy HTML5 features, but it’s actually about as well supported as SVG these days: http://caniuse.com/#search=canvas Only option 1 will work for Tim's favorite browser, Dillo, but…ugh. Fossil should not *require* any of the latest HTML5 stuff. A few years ago I would have agreed with you, but browsers have come a long way recently, what with all the new competition. I’m all for supporting “ancient” browsers, as long as they still render standard HTML, CSS and JS code correctly. Our own web app finally dropped Firefox 2 support recently, moving the low bar up to Firefox 3, because we found a case where 2 wasn’t doing the right thing with some perfectly reasonable code. I don’t think it’s unreasonable to require a browser released 6 years ago at minimum. We have too many good browsers available these days to be continuing to bend over backwards with browser compatibility hacks. You have to be able to draw some line in the sand, some minimum level of required features. I think IE9 makes a pretty good target. Although it’s only 4 years old now, it was about 3 years behind the rest of the mainstream browser world at the time, in terms of HTML, CSS JS feature compatibility. (Yes, about equal to Firefox 3, Safari 3, and Chrome 1.0!) IE9 is the newest IE that still runs on the oldest supported version of Windows, Vista, which will be in “extended support” for another couple of years. This does rule out XP support for sites unwilling to switch from IE, but I don’t think such people are Fossil’s target market anyway. Incidentally, if you’re looking for ways to test with versions of IE you otherwise wouldn’t have access to, visit: https://www.modern.ie/ You wouldn’t know it from the URL, but it’s actually a Microsoft service, offering legitimate testing versions of Windows pre-loaded with specific versions of IE. An especially nice feature is that it can generate images in any of several VM formats: VirtualBox, OVA (VMware), Hyper-V, Parallels… ___ 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] Browser support
Hi Warren, On 16 March 2015 at 17:50, Warren Young w...@etr-usa.com wrote: Hi, it’s the resident pro web app developer checking in again. :) There are at least three ways to create the timeline without Javascript. Do you have examples of these three methods? Just curious, what would a HTML5 Fossil actually look like contrasted with what it is now? What new things would it offer over what doesn't exist now? just curious. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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 version 1.32
Does the server fossil know the version number of the client fossil on a clone? Or could it ask? If so, it could do what Andy suggests. ../Dave On 16 March 2015 at 14:24, Richard Hipp d...@sqlite.org wrote: On 3/16/15, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Stephan Beal on Mon, 16 Mar 2015 18:41:34 +0100: wiki-/ticket-only repos might not have a manifest at all. Then these types of repositories would have to be unclonable by older versions of Fossil. The server would have to refuse the clone request (similar to how it refuses to accept content from clients with an out of date schema). The clone protocol could be modified to include an identifier that allows the server to know if such a repository is incompatible with the client making the request before allowing the clone to proceed. Not sure if this is even possible, but in theory it seems to work. :-) Keep in mind that if everyone is using Fossil 1.30 or later, we never need to have any check-ins in the repository and the first check-in (if one exists) need not be artifact 1. The code already takes care of all of that. The problem comes up when people try to use Fossil 1.27. And we cannot go reach into peoples machines and fix 1.27. We have to work around whatever it is that 1.27 does. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On 3/16/15, Richard Hipp d...@sqlite.org wrote: On 3/16/15, Warren Young w...@etr-usa.com wrote: On Mar 16, 2015, at 11:15 AM, Richard Hipp d...@sqlite.org wrote: The timeline graph is drawn using JS. Without JS you do not get the very nice timeline graph. I don't see any reasonable way around that. Hi, it's the resident pro web app developer checking in again. :) There are at least three ways to create the timeline without Javascript. 1. Build the timeline as a dynamic PNG on the server side, then serve the client a URL to that dynamic PNG. This requires libpng or similar, some line-drawing API on top of that (e.g. libgd, SDL, etc.), and ideally a place to cache the generated PNG so it doesn't have to be re-generated until a timeline update invalidates it. We actually have code doing this, written before the next two options became widely available. We'll get around to rewriting it RSN. The main difficulty is knowing where to put each node of the graph, since the vertical space between nodes depends on how long the check-in comment is and how it wraps. And if the operator resizes the browser window to be narrower or wider, then the comments will wrap at different places and change the spacing. Is there a css fill/sticky option that will shrink/grow that ? If so, it'd be like using a 1x90 image and just declaring it 500x90 so it's stretched, making a bar, no ? I haven't worked in this field for long enough that few paradigms have come-and-gone, but I feel like a gd (or similar) solution isn't far-fetched. -bch I didn't get far enough down this path to investigate the second potential problem: limits on the sizes of GIF/PNG files. Some of the graphs can be *very tall* - hundreds of thousands or perhaps millions of pixels. Is there a limit on the height of a GIF/PNG file? And will browsers successfully render very tall GIF/PNGs. Or would it be necessary to bring the image up into segments, with a separate server round-trip and CGI-process invocation for each chunk? 2. Generate the timeline server-side as SVG, and serve it inline on the timeline page. Of the mainstream browsers with significant market share, only IE8 doesn't support SVG: http://caniuse.com/#search=svg The only reason there's still a significant chunk of IE8 out there is that that's the last version of IE that will run on XP. No developer should still be running an unsupported 13 year old OS on his desktop anyway. Is it wrong to think that any browser that does not support JS probably also does not support SVG? I've never worked with SVG, so I don't know its limitations and capabilities. Can it create the very tall graphics required by the Fossil timeline? 3. Generate the timeline via canvas. That also requires JS, no? Some early versions of Fossil actually did this. The main problem is that the canvas is limited in size to 32768 pixels high. (What was the W3C thinking when they speced this!!!) Lots of timelines are much taller than that. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Xekri skin: weird dropdowns on timeline page in Opera
Hello Tontyna! Thank you for the information about the problem you ran into with the Xekri skin. I don't have access to Opera, so I can not test any fixes to make sure it would work equally on Chrome and Firefox. A possible fix which uses -o-display: block for the div.submenu has been pushed to the skin-xekri branch. Please let me know if it works for you and I am open to any suggestions for a better solution. Andrew On Mon, Mar 16, 2015 at 5:54 PM, Tontyna tont...@ultrareal.de wrote: Opera (12.17/Win32) produces gigantic selects -- see attached screenshot. Culprit is the display: flex property of div.submenu - Tontyna ___ 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] New skin: Blitz
I sent DRH a new bundle with some tweaks. - set padding on a instead of li in .mainmenu - adjust font-sizes on diff panels to 1rem, Blitz is 1rem=10px. 0.85rem is too small. - set the timeline checkin-id to lowercase rather than uppercase As for the content-width... the reason to set a max width is to avoid distortion of content. It's a common practice in webapps. This is often coupled with responsive design where components are shown/hidden based on CSS media queries. This allows a UI to scale gracefully from handhelds to desktops. Most current CSS toolkits feature responsive layout classes, but adoption of one would require changes to the Fossil-generated HTML, not just wrapping a header and a footer around the current generated content. -J ___ 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 skin: Blitz
On 16 March 2015 at 15:13, James Moger james.mo...@gmail.com wrote: I sent DRH a new bundle with some tweaks. - set padding on a instead of li in .mainmenu - adjust font-sizes on diff panels to 1rem, Blitz is 1rem=10px. 0.85rem is too small. - set the timeline checkin-id to lowercase rather than uppercase As for the content-width... the reason to set a max width is to avoid distortion of content. It's a common practice in webapps. This is often coupled with responsive design where components are shown/hidden based on CSS media queries. This allows a UI to scale gracefully from handhelds to desktops. Most current CSS toolkits feature responsive layout classes, but adoption of one would require changes to the Fossil-generated HTML, not just wrapping a header and a footer around the current generated content. Maybe I am stating the obvious but it does not make sense to scale the main content area to arbitrarily wide screens. At some point the lines get so long they are pain to read. Of course, this length is individual to some extent and it would be nice tunable parameter but there certainly should be a limit. When you have headers and footers that you can reflow beside the main content and a toolkit that has the ability it's fine but that still does not extend to arbitrarily wide screen. Thanks Michal ___ 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 ui not working with recent chrome browser
On 3/16/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote: 6) my own remote fossil standalone instances on Linux server - incomplete pages for all browsers except firefox, which shows complete pages Are you able to set up a such an instance that we can access to investigate the problem? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] GitHub question. Was: Git-v-Fossil.
On 14 March 2015 at 18:48, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Richard Hipp on Sat, 14 Mar 2015 00:05:07 -0400: Am I wrong to think that clicking through the changes in a project (not necessarily from the beginning, but from some signification event, say the most recent release) in chronological order is something that people might commonly want to do? It's certainly something I commonly want to do, and sorely miss when I have to use github. I use gitk to fill the voi d, but it too is lacking. I prefer that the tools I use help me reason effectively about the data I'm looking at and something like clicking through changes helps me do this for a series of checkins. But I'm just expressing my bias---I don't know what other people might commonly want to do. :-) Yes, it's useful. And time and time again I find the web tools lacking so I just clone the repository locally and use fully functional local tools. I always view the web interfaces as a sort of preview of the VCS content which you can use to determine if the patch you are looking for was pushed or to determine if the project code looks interesting (as opposed to the name and short description). The time when web interfaces are fully functional looks far far away. They are one of the available tools and they complement the tool set but are not replacement for the others. Thanks Michal ___ 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 Version control
the one guy behind it also wrote a book about VCSs called Version Control By Example That one guy (Eric Sink) is actually a pretty well-respected VCS developer small business owner; Veracity was not a one-man project, it was an Apache licensed company product. In the early 2000s if you had to use VisualStudio and were afraid of the abomination known as Visual SourceSafe (VSS), then SourceGear http://sourcegear.com/ Vault were your best friends. Veracity was going to be SourceGear's DVCS follow-up to Vault building on the lessons learned from Git/Hg which in-turn learned from Monotone/tla/Darcs/SVK/etc. Veracity basically died two years ago, I assume because they concluded the DVCS market was saturated and they couldn't make any money. Although the PlasticSCM https://www.plasticscm.com guys are unabashedly pursuing it to great success, I believe. Instead, Eric et al formed Zumero http://zumero.com/ using the distributed tech they developed for Veracity and applying it to SQLite MS-SQL server. Zumero provides bi-directional data replication for mobile devices enterprise servers. -J ___ 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] Browser support
On 3/16/15, Chad Clabaugh chadclaba...@gmail.com wrote: Is there an official list of supported browsers? I've been unable to find any references in the documentation. If not, can one be added? There is no official list. The correct answer, though, should be as many as possible. The idea is to keep the interface conservative and not depend on having the latest trending browser features. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil version 1.32
On Sun, Mar 15, 2015 at 11:37 AM, Andy Bradford amb-fos...@bradfords.org wrote: The requirement, specifically, is that the first artifact that the server sends during a clone, must be a checkin, or older Fossil clients will end up in this state. Could the server side be modified to insure the first artifact sent is the first manifest? ___ 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] Browser support
On 2015-03-16 12:04, Richard Hipp wrote: Is there an official list of supported browsers? I've been unable to find any references in the documentation. If not, can one be added? There is no official list. The correct answer, though, should be as many as possible. The idea is to keep the interface conservative and not depend on having the latest trending browser features. As someone who likes uses Dillo (a light FLTK browser[1]) and console browsers such as lynx[2]/links/elinks/w3m, and flies with NoScript on Firefox, there have been certain features that appear to require JavaScript. While I expect that full non-JS accessibility is often only a nice-to-have pipedream, if such a list of supported-browsers was created, it would be nice to catalog which parts of Fossil break without JS. -tim [1] http://www.dillo.org/ [2] http://lynx.isc.org/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Google code shutting down
On Mon, Mar 16, 2015 at 4:33 AM, Graeme Pietersz gra...@pietersz.net wrote: On 16/03/15 13:30, Ron W wrote: On Sun, Mar 15, 2015 at 3:56 AM, Graeme Pietersz gra...@pietersz.net mailto:gra...@pietersz.net gra...@pietersz.net wrote: 1) email notifications, the most important for me Can currently be accomplished with external (to Fossil) service, using, for example, Fossil's RSS feed to trigger email generation. Not easy to do with a private repo without compromising privacy. I assume you mean the risk of enabling the RSS feed. I just looked and don't see a way to disable the RSS. Nor do I see any documentation describing how it works, in particular, how it is affected by the login state. 4) link user names to user pages with other activity (only useful of you have some social networking features) You mean like linking to users's walls? Tickets descriptions and comments can contain wiki mark-up. That relies on people remembering to do it - procedure for something that could be painless and uniform if automated. I think it could be automated by modifying the TH1 code in the Edit Ticket page. 5) edit the original report if things change Not sure I agree. While making corrections might be nice, I think comments are better for describing an evolving situation. In general, but if the task is changed significantly there is a good case for changing the ticket itself. To take a recent example I came across, you have a ticket to upgrade an application to work with a more recent library version. You then change your mind about which more recent version to upgrade to. A ticket that still says upgrade to version x.y when you are now upgrading to x.z is misleading. At least in my department (New Product Engineering), our process requires us to open a new ticket, related to the original, and close the original with the reason Obsolete and a comment stating why. 6) sub-tasks/child tickets/todo list for ticket In the description and comments, other tickets can be linked,, as can wiki pages and commits. Would be nice if other fields could link as well. Anyway, could create a child ticket using Javascript to populate a new ticket with defaults derived from the currently viewed ticket. That does not provide the same functionality. It is a partial workaround but relies on manual intervention to ensure the links run both ways, and does not prevent the parent ticket being closed before all child tickets are closed. I'm pretty sure the Javascript could take care of links in both directions. Then, if TH1 query can read the statuses of the child tickets, the TH1 code in Edit Ticket can handle the do not close unless child tickets are closed logic. (This would not need to be recursive. Only need to iterate over the direct children.) ___ 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] Missing timeline graph above 36 timeline items (?!)
On 3/16/15, Richie Adler richiead...@gmail.com wrote: After the latest upgrades, I've been unable to see the timeline graphs if I have more than 36 items in the timeline. The space for the graph remains, but nothing is drawn. The weirdest thing is that I have reverted to old versions and I'm still unable to see the full graph! I can see it in the Fossil site which is running the same version, though... In another thread (fossil ui not working with recent chrome browser) there are reports of truncated pages when running on Windows. But so far, none of the developers have been able to reproduce the problem. If you can show us how to repro the problem, we'll fix it right away. -- 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] Missing timeline graph above 36 timeline items (?!)
After the latest upgrades, I've been unable to see the timeline graphs if I have more than 36 items in the timeline. The space for the graph remains, but nothing is drawn. The weirdest thing is that I have reverted to old versions and I'm still unable to see the full graph! I can see it in the Fossil site which is running the same version, though... This is fossil version 1.32 [127ee1f572] 2015-03-16 14:25:03 UTC Compiled on Mar 16 2015 12:48:12 using mingw32-3.20-gcc-4.7.2 (32-bit) SQLite 3.8.8 2015-02-25 14:25:31 6d132e7a22 Schema version 2015-01-24 zlib 1.2.8, loaded 1.2.8 JSON (API 20120713) MBCS_COMMAND_LINE Running on Windows 7. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] ANSI color would be nice
If you're looking for improvement ideas (unfortunately without a corresponding contribution this time), ANSI color support would be a nice usability improvement. I suppose Windows could be a problem for that. -J ___ 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] Git-v-Fossil. Was: Google code shutting down
On Fri, Mar 13, 2015 at 8:26 PM, Richard Hipp d...@sqlite.org wrote: Fossil was created to support the development of SQLite. All other use (and there is more and more of that lately) is just gravy. They all start somewhere. :) Git Hg were both written to solve the Linux kernel's BitKeeper conundrum. Both grew to be larger than just a solution for the initial need. It could happen for Fossil too. -J ___ 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 skin: Blitz
It depends on the selected toolkit, but there are generally two approaches: 1. allow reflow 2. show/hide Blitz is based on Skeleton without any of the response classes. Skeleton supports reflow only. http://getskeleton.com/#grid Bootstrap - much heavier/larger and more powerful - supports reflow and show/hide. http://getbootstrap.com/css If I take the timeline, for example, there is a lot of content and density. If you wanted to display it legibly on a phone (i.e. without pinch/zoom) you'd have to hide elements from displayed page. This would be done by specifying additional css classes on the elements within the timeline table that allowed/prohibited display on small screen devices. If you want a live example based on (older) Bootstrap, take a look at this page https://dev.gitblit.com/summary/gitblit.git with different browser form-factors. -J On Mon, Mar 16, 2015 at 10:26 AM, Richard Hipp d...@sqlite.org wrote: On 3/16/15, James Moger james.mo...@gmail.com wrote: adoption of [a responsive interface] would require changes to the Fossil-generated HTML, not just wrapping a header and a footer around the current generated content. Can you elaborate? What changes would be required? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ANSI color would be nice
On Mon, Mar 16, 2015 at 10:32 AM, bch brad.har...@gmail.com wrote: if anybody tackles this, I sure hope it's a non-default selectable option. The colors themselves must be user-definable as well. Not just because people have slightly different preferences, but also because of differing visibility (strongly depends on the chosen bg color of the terminal (white vs black vs some gray)) [*] [*] In my setup yellow text-color is pretty much invisible against the light grey background I use, as is white text. Adding bold helps. So, fixed colors will not really cut it. Reminds me that I should see how much of the Stackato cli (**) color commands can be put into Cmdr for more generic support. (**) https://github.com/ActiveState/stackato-cli (colors command, and color ensemble). http://core.tcl.tk/akupries/cmdr/index On 3/16/15, James Moger james.mo...@gmail.com wrote: If you're looking for improvement ideas (unfortunately without a corresponding contribution this time), ANSI color support would be a nice usability improvement. I suppose Windows could be a problem for that. -J ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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 version 1.32
On Sat, Mar 14, 2015 at 10:24:05PM -0400, Richard Hipp wrote: On 3/14/15, James Turner ja...@calminferno.net wrote: It appears the actual tarballs were also removed. While I understand the reasoning behind this, this will break automated build systems like ports in OpenBSD for stable releases that may reference older versions of fossil. Is there a reason why the tarballs had to be removed? They are still accessible in the old_builds directory. I could move them back. But I decided to make them hard to get to encourage people to upgrade to a version that doesn't have the Ryerson-student-project-eating bug. *If* you can make a compelling argument to move them back, I might. It's not such a big deal for us, OpenBSD, but I wasn't sure for others if having archives go missing would break builds. Then again I guess it's a good way to force people to upgrade :) -- 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 -- James Turner ___ 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] Google code shutting down
On Mon, Mar 16, 2015 at 5:05 AM, Graeme Pietersz gra...@pietersz.net wrote: (there is a ticket change hook now?). Supposedly there is, and other hooks, but I've never seen documentation. But, supposedly, the TH1 thus invoked by the hook can, if enabled, touch a URL. With an appropriately constructed URL, a supporting service could then generate and send email. ___ 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] Git-v-Fossil. Was: Google code shutting down
On Mar 16, 2015 9:44 AM, James Moger james.mo...@gmail.com wrote: On Fri, Mar 13, 2015 at 8:26 PM, Richard Hipp d...@sqlite.org wrote: Fossil was created to support the development of SQLite. All other use (and there is more and more of that lately) is just gravy. They all start somewhere. :) Git Hg were both written to solve the Linux kernel's BitKeeper conundrum. Both grew to be larger than just a solution for the initial need. It could happen for Fossil too. It has happened for fossil. Just to a different magnitude. :) SDR ___ 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] ANSI color would be nice
if anybody tackles this, I sure hope it's a non-default selectable option. On 3/16/15, James Moger james.mo...@gmail.com wrote: If you're looking for improvement ideas (unfortunately without a corresponding contribution this time), ANSI color support would be a nice usability improvement. I suppose Windows could be a problem for that. -J ___ 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] ANSI color would be nice
fwiw: libfossil has this ability, and backporting it into fossil would not be problematic. i am still on medical leave for nerve damage for the foreseeable future, so i can't personally commit (as it were) to it. - sent from a mobile device. Please excuse brevity, auto-correction, typos, and top-posting. On Mar 16, 2015 6:33 PM, bch brad.har...@gmail.com wrote: if anybody tackles this, I sure hope it's a non-default selectable option. On 3/16/15, James Moger james.mo...@gmail.com wrote: If you're looking for improvement ideas (unfortunately without a corresponding contribution this time), ANSI color support would be a nice usability improvement. I suppose Windows could be a problem for that. -J ___ 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] Fossil version 1.32
wiki-/ticket-only repos might not have a manifest at all. - sent from a mobile device. Please excuse brevity, auto-correction, typos, and top-posting. On Mar 16, 2015 5:21 PM, Ron W ronw.m...@gmail.com wrote: On Sun, Mar 15, 2015 at 11:37 AM, Andy Bradford amb-fos...@bradfords.org wrote: The requirement, specifically, is that the first artifact that the server sends during a clone, must be a checkin, or older Fossil clients will end up in this state. Could the server side be modified to insure the first artifact sent is the first manifest? ___ 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] GitHub question. Was: Git-v-Fossil.
i, for one, am glad that _our_ Benevolent Dictator behaves like an empathic human being in public. I second this statement. :-) Cheers. - Vikrant On 14 March 2015 at 18:43, Stephan Beal sgb...@googlemail.com wrote: On Sat, Mar 14, 2015 at 1:58 PM, Graeme Pietersz gra...@pietersz.net wrote: There is a long and interesting discussion between Linux Torvalds and others about the merits of the Github approach here: https://github.com/torvalds/linux/pull/17#issuecomment-5654674 If that can be called a discussion. It's Linus in his typically tactless, holier-than-thou-and-everything-else form. i, for one, am glad that _our_ Benevolent Dictator behaves like an empathic human being in public. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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 version 1.32
Thus said Stephan Beal on Mon, 16 Mar 2015 18:41:34 +0100: wiki-/ticket-only repos might not have a manifest at all. Then these types of repositories would have to be unclonable by older versions of Fossil. The server would have to refuse the clone request (similar to how it refuses to accept content from clients with an out of date schema). The clone protocol could be modified to include an identifier that allows the server to know if such a repository is incompatible with the client making the request before allowing the clone to proceed. Not sure if this is even possible, but in theory it seems to work. :-) Andy -- TAI64 timestamp: 400055071c8b ___ 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] Browser support
On 3/16/15, Tim Chase fos...@tim.thechases.com wrote: On 2015-03-16 12:04, Richard Hipp wrote: Is there an official list of supported browsers? I've been unable to find any references in the documentation. If not, can one be added? There is no official list. The correct answer, though, should be as many as possible. The idea is to keep the interface conservative and not depend on having the latest trending browser features. As someone who likes uses Dillo (a light FLTK browser[1]) and console browsers such as lynx[2]/links/elinks/w3m, and flies with NoScript on Firefox, there have been certain features that appear to require JavaScript. While I expect that full non-JS accessibility is often only a nice-to-have pipedream, if such a list of supported-browsers was created, it would be nice to catalog which parts of Fossil break without JS. The timeline graph is drawn using JS. Without JS you do not get the very nice timeline graph. I don't see any reasonable way around that. JS is also used for robot defenses. Depending on server settings, users who are not logged in see a honeypot as the href= of anchor tags. Then JS goes through and sets the correct target after mouse movement is detected. This can be circumvented by logging in. Usually logging in as anonymous is sufficient. Click-to-sort on various tables is done using JS. Opening and closing subtrees in the file tree display is done using JS. That's all that comes readily to mind. I agree that Fossil ought to be usable (though perhaps with reduced functionality, such as no timeline graph) even with very old and primitive browsers. Fossil should not *require* any of the latest HTML5 stuff. Certainly it is free to take advantage of those new features if they are available, but Fossil should still be usable without them. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] GitHub question. Was: Git-v-Fossil.
On Mon, Mar 16, 2015 at 3:45 AM, John Found johnfo...@asm32.info wrote: The first step towards such achievement is to allow all Fossil users to exists in one common username space. OpenID authentication could help to make this without big effort. OpenID support would be a nice addition. But, even in an enterprise environment where all users log in through a central service like Kerberos or MS AD, access to individual projects is still the domain of each project admin (where I work, the Project Managers). Another step is to provide some notification mechanism from the cloned repositories to the parent repository - for example, when the user make commit to the cloned repository, Fossil sends notification message to the parent repository. These automatic notifications are not so useful but may serve as a statistics mechanism and as a indicator of the project development. Of course, if the project leader has informations about the changes, he can choose to pull some/all of these changes without waiting the pull request. At least where I work, the Project Managers and Lead Developers subscribed/unsubscribe to the Fossil RSS feeds of the developers they are responsible for. I am aware of the difficulties people without enterprise resources can face - such as originating RSS feeds from a PC in one's residence. Even a service like GitHub can only partly mitigate these problems as the service only knows about changes that have been pushed to repos hosted by the service. RSS forwarding is possible. I don't know of any such service. (by RSS forwarding, I meant the originator pushes the new items to the forwarding service. Readers would then subscribe to the forwarded version of the feed.) Of course, for this to work, either the new TH1 hooks would need to be used to push to the forwarding service, or a local feed forwarder would read the feed from Fossil and push it Even more useful is if the parent repository, notifies the clones about new commits, because the cloned repository might want to merge these changes. But if the cloned repository is not hosted on a web server this can be not easy task. In this case the notification can be made by request from the cloned repository. Again, where I work, we subscribe to the Fossil RSS feeds of the repos we need to monitor The ticket system can be used as a distributed messaging engine between developers. True, but I think that would needlessly clutter the repository and its clones. FWIW, our IT department has set up some kind of email forwarder that remembers the subscriber list of the latest notification message for each issue. Any time someone wants/needs to email all subscribers of a given issue just addresses the message to n...@issues.company.com (where is the issue ID) and the message is forwarded to the remembered subscribers. Similar to Bugzilla, we treat issue subscription changes as ticket changes. The forwarder is able to reliably recognize and filter out subscription-change-only notifications so users don't get spammed. (Unfortunately, our IT people are not allowed to shared the details with people outside the company so I can't share those either.) ___ 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] Missing timeline graph above 36 timeline items (?!)
Thus said Richie Adler on Mon, 16 Mar 2015 18:53:34 -0300: JavaScript issue? Disabled NoScript and for more security restarted Firefox with no extensions enabled. Same thing. I wonder if perhaps some cross-site scripting blocking tool is blocking it? Andy -- TAI64 timestamp: 40005507b230 ___ 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 version 1.32
Thus said David Mason on Mon, 16 Mar 2015 21:35:51 -0400: Does the server fossil know the version number of the client fossil on a clone? Or could it ask? If so, it could do what Andy suggests. Not currently. The client version is not currently exchanged during cloning. The only piece of information that the server is given is the Clone Protocol which is currently 3. Even if the Clone Protocol number is bumped, that still doesn't solve the problem of what happens when someone opens a Fossil that does not have rid=1 and type=ci using Fossil 1.27 (e.g. they used scp to obtain a copy of the Fossil repository). This might require producing an slightly different schema or some incompatible change that would cause the Fossil 1.27 client to refuse to open the Fossil (or continue using it). Andy -- TAI64 timestamp: 40005507b4dc ___ 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] Xekri skin: weird dropdowns on timeline page in Opera
The current version of Opera is 28, you should probably update your Browser. You are using a 2 year old version which comes with Presto engine (development of which is now discontinued by Opera), while newer versions use Blink engine. Cheers. - Vikrant On 17 March 2015 at 04:24, Tontyna tont...@ultrareal.de wrote: Opera (12.17/Win32) produces gigantic selects -- see attached screenshot. Culprit is the display: flex property of div.submenu - Tontyna ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Xekri skin: weird dropdowns on timeline page in Opera
Opera (12.17/Win32) produces gigantic selects -- see attached screenshot. Culprit is the display: flex property of div.submenu - Tontyna ___ 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] Google code shutting down
On Mon, Mar 16, 2015 at 4:01 PM, Graeme Pietersz gra...@pietersz.net wrote: What would still be missing would be some way of letting users decide which tickets they wanted to be notified about. Customise the tickets table? We added a custom field to hold email addresses. Similar to the CC field in Bugzilla. Yes, this means that (un)subscribing to a ticket requires a ticket change, but the forwarder the IT department runs for us is able to filter out notices that only change the email list. (Sorry, our IT people are not allowed to share the details.) ___ 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] Missing timeline graph above 36 timeline items (?!)
El 16/03/2015 a las 17:10, Tontyna escibió: The weirdest thing is that I have reverted to old versions and I'm still unable to see the full graph! First idea: cached stylesheet? Cleared the cache to no avail. Although that wouldn't explain why you can see 36 items on the Fossil site but not on localhost. That stumped me too. Can't imagine that the HTML served by fossil.exe is sooo different from the HTML produced on fossil-scm.org -- what's the skin of your repo? I tried all of them -- no skin shows the arrows for a timeline 36 now. JavaScript issue? Disabled NoScript and for more security restarted Firefox with no extensions enabled. Same thing. Only the arrows and boxes of the timeline are missing? The whole graph is absent. The Footer is present? Hum. Not in the timeline, no. When I click other pages it shows, though. When you hover the empty timeline space: does the mouse pointer change? No. Does clicking on two different positions bring you to the Check-in-Differences page? No. ___ 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] Google code shutting down
On Mon, Mar 16, 2015 at 4:01 PM, Graeme Pietersz gra...@pietersz.net wrote: What would still be missing would be some way of letting users decide which tickets they wanted to be notified about. Customise the tickets table? Another option would be to use a list server. But even with one that could automatically create new lists when it sees a new topic still requires its own subscription management. ___ 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] Missing timeline graph above 36 timeline items (?!)
If you do View Page Source, does the HTML appear to be truncated? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Google code shutting down
Hi Ron, On 16 March 2015 at 14:41, Ron W ronw.m...@gmail.com wrote: On Mon, Mar 16, 2015 at 3:51 PM, jungle Boogie jungleboog...@gmail.com wrote: Yes, this is a great plan. I didn't say it was great or even good. Only that is what we were told to do. Or not be allowed to generate email from the Fossil repos. IMO, putting a private, internally worked on repo behind a firewall is good. There are many new features we'd all like Fossil to have but I'll take fewer and fewer bugs over new features. ;) -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] Google code shutting down
On Mon, Mar 16, 2015 at 5:48 PM, jungle Boogie jungleboog...@gmail.com wrote: IMO, putting a private, internally worked on repo behind a firewall is good. There are many new features we'd all like Fossil to have but I'll take fewer and fewer bugs over new features. ;) Agree on both points. ___ 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] GitHub question. Was: Git-v-Fossil.
On Mon, Mar 16, 2015 at 11:01:21PM +0100, mario wrote: Social network is a nice metaphor. But it's also just a side-effect of having a data silo. Actually, I think that's the far bigger item. GitHub has managed something which SourceForge never had -- a stable service. Most developer interactions center around the issue tracker. Which is pretty. And often just used as discussion board with ticket numbers. That's not my experience with GitHub. Until recently, the issue tracker was a bad joke. The central communication medium on GitHub was always the pull queue... Joerg ___ 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] GitHub question. Was: Git-v-Fossil.
On Saturday, March 14, 2015, Richard Hipp d...@sqlite.org wrote: On 3/14/15, Ron W ronw.m...@gmail.com javascript:; wrote: The key difference is that, in git, the puller can force the in coming commits to be remapped into branches of their own. That is, I could commit my changes to trunk in my clone, then when the other person pulls my changes, she/he can tell git to map my changes into ronw-trunk. Fossil allows that too. Even if the incoming bundle is on trunk, you can change the branch designation to anything you want after you import the bundle. But can Fossil do that with a pull directly from another Fossil? ___ 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] GitHub question. Was: Git-v-Fossil.
On Sat, 14 Mar 2015 14:02:18 +0200 John Found johnfo...@asm32.info wrote: But, for example fossil can provide some way to connect the stand alone repositories and developers in some kind of distributed peer-to-peer network and to provide some interaction - I don't know - maybe some voting, messaging, clone tracking, collaborative environment, pull requests, whatever will turn a heap of independent repositories into mutually connected developers network. No one is interested, but I will continue a little. :) The first step towards such achievement is to allow all Fossil users to exists in one common username space. OpenID authentication could help to make this without big effort. Another step is to provide some notification mechanism from the cloned repositories to the parent repository - for example, when the user make commit to the cloned repository, Fossil sends notification message to the parent repository. These automatic notifications are not so useful but may serve as a statistics mechanism and as a indicator of the project development. Of course, if the project leader has informations about the changes, he can choose to pull some/all of these changes without waiting the pull request. Even more useful is if the parent repository, notifies the clones about new commits, because the cloned repository might want to merge these changes. But if the cloned repository is not hosted on a web server this can be not easy task. In this case the notification can be made by request from the cloned repository. The ticket system can be used as a distributed messaging engine between developers. Regards -- http://fresh.flatassembler.net http://asm32.info John Found johnfo...@asm32.info ___ 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] GitHub question. Was: Git-v-Fossil.
But, for example fossil can provide some way to connect the stand alone repositories and developers in some kind of distributed peer-to-peer network and to provide some interaction - I don't know - maybe some voting, messaging, clone tracking, collaborative environment, pull requests, whatever will turn a heap of independent repositories into mutually connected developers network. I've some exciting news on this. Hang tight! (for about 5-7 days more) Cheers. - Vikrant On 16 March 2015 at 13:15, John Found johnfo...@asm32.info wrote: On Sat, 14 Mar 2015 14:02:18 +0200 John Found johnfo...@asm32.info wrote: But, for example fossil can provide some way to connect the stand alone repositories and developers in some kind of distributed peer-to-peer network and to provide some interaction - I don't know - maybe some voting, messaging, clone tracking, collaborative environment, pull requests, whatever will turn a heap of independent repositories into mutually connected developers network. No one is interested, but I will continue a little. :) The first step towards such achievement is to allow all Fossil users to exists in one common username space. OpenID authentication could help to make this without big effort. Another step is to provide some notification mechanism from the cloned repositories to the parent repository - for example, when the user make commit to the cloned repository, Fossil sends notification message to the parent repository. These automatic notifications are not so useful but may serve as a statistics mechanism and as a indicator of the project development. Of course, if the project leader has informations about the changes, he can choose to pull some/all of these changes without waiting the pull request. Even more useful is if the parent repository, notifies the clones about new commits, because the cloned repository might want to merge these changes. But if the cloned repository is not hosted on a web server this can be not easy task. In this case the notification can be made by request from the cloned repository. The ticket system can be used as a distributed messaging engine between developers. Regards -- http://fresh.flatassembler.net http://asm32.info John Found johnfo...@asm32.info ___ 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] Google code shutting down
On 16/03/15 22:30, Ron W wrote: On Mon, Mar 16, 2015 at 4:33 AM, Graeme Pietersz gra...@pietersz.net mailto:gra...@pietersz.net wrote: On 16/03/15 13:30, Ron W wrote: On Sun, Mar 15, 2015 at 3:56 AM, Graeme Pietersz gra...@pietersz.net mailto:gra...@pietersz.net mailto:gra...@pietersz.net mailto:gra...@pietersz.net wrote: 1) email notifications, the most important for me Can currently be accomplished with external (to Fossil) service, using, for example, Fossil's RSS feed to trigger emailgeneration. Not easy to do with a private repo without compromising privacy. I assume you mean the risk of enabling the RSS feed. I just looked and don't see a way to disable the RSS. Nor do I see any documentation describing how it works, in particular, how it is affected by the login state. The problem is that if you require logins to see pages, then you also require logins to see the RSS feeds. If I make the timeline accessible to logged in users, then the timeline.rss is also only accessible to logged in users. So you need an RSS to email script or service that can login to the Fossil site. ___ 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] Google code shutting down
On 17/03/15 00:27, jungle Boogie wrote: On 16 March 2015 at 11:33, Graeme Pietersz gra...@pietersz.net wrote: So you need an RSS to email script or service that can login to the Fossil site. Or permissions for nobody to view the rss feed. I cannot find a separate RSS permission. Unless that exists and I have missed it, then it means letting nobody view the timeline, at which point it is no longer an entirely private repository. ___ 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 version 1.32
On 3/16/15, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Stephan Beal on Mon, 16 Mar 2015 18:41:34 +0100: wiki-/ticket-only repos might not have a manifest at all. Then these types of repositories would have to be unclonable by older versions of Fossil. The server would have to refuse the clone request (similar to how it refuses to accept content from clients with an out of date schema). The clone protocol could be modified to include an identifier that allows the server to know if such a repository is incompatible with the client making the request before allowing the clone to proceed. Not sure if this is even possible, but in theory it seems to work. :-) Keep in mind that if everyone is using Fossil 1.30 or later, we never need to have any check-ins in the repository and the first check-in (if one exists) need not be artifact 1. The code already takes care of all of that. The problem comes up when people try to use Fossil 1.27. And we cannot go reach into peoples machines and fix 1.27. We have to work around whatever it is that 1.27 does. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Google code shutting down
On 16 March 2015 at 11:33, Graeme Pietersz gra...@pietersz.net wrote: So you need an RSS to email script or service that can login to the Fossil site. Or permissions for nobody to view the rss feed. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] Google code shutting down
Hi Grame, On 16 March 2015 at 12:10, Graeme Pietersz gra...@pietersz.net wrote: On 17/03/15 00:27, jungle Boogie wrote: On 16 March 2015 at 11:33, Graeme Pietersz gra...@pietersz.net wrote: So you need an RSS to email script or service that can login to the Fossil site. Or permissions for nobody to view the rss feed. I cannot find a separate RSS permission. No, it doesn't exist. I'm saying that could be integrated into fossil just like the previous letters on the list talked about allowing users to login but can't see code. I think this was the 'corporate' mode of fossil. Unless that exists and I have missed it, then it means letting nobody view the timeline, at which point it is no longer an entirely private repository. You're right, it won't be private, so you'll be stuck having your password in some rss fetch thing. One would have to weigh the risks. How you suggest email for tickets be integrated into Fossil? -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] Google code shutting down
On Mon, Mar 16, 2015 at 3:22 PM, jungle Boogie jungleboog...@gmail.com wrote: You're right, it won't be private, so you'll be stuck having your password in some rss fetch thing. One would have to weigh the risks. Where I work, we allow - in Fossil - nobody to view the time line because only PCs connected to the departmental VPN can access the repos. Granted this is not perfect, but our IT department told us to do it that way so they wouldn't need to code a password into the RSS-to-email forwarder. How you suggest email for tickets be integrated into Fossil? From what little I have read (on this email list) about Fossil's TH1 hooks, it's possible to write TH1 hook code to construct a URL that incorporates the info then ping an email generator using that URL. Another option would be a more traditional hook interface that can exec a program or script. ___ 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] Google code shutting down
Hi Ron, On 16 March 2015 at 12:38, Ron W ronw.m...@gmail.com wrote: On Mon, Mar 16, 2015 at 3:22 PM, jungle Boogie jungleboog...@gmail.com wrote: You're right, it won't be private, so you'll be stuck having your password in some rss fetch thing. One would have to weigh the risks. Where I work, we allow - in Fossil - nobody to view the time line because only PCs connected to the departmental VPN can access the repos. Granted this is not perfect, but our IT department told us to do it that way so they wouldn't need to code a password into the RSS-to-email forwarder. Yes, this is a great plan. How you suggest email for tickets be integrated into Fossil? From what little I have read (on this email list) about Fossil's TH1 hooks, it's possible to write TH1 hook code to construct a URL that incorporates the info then ping an email generator using that URL. Another option would be a more traditional hook interface that can exec a program or script. Ah, okay, so Fossil itself doesn't send the email but it triggers a/the script based on some trigger. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] Missing timeline graph above 36 timeline items (?!)
The weirdest thing is that I have reverted to old versions and I'm still unable to see the full graph! First idea: cached stylesheet? Although that wouldn't explain why you can see 36 items on the Fossil site but not on localhost. Can't imagine that the HTML served by fossil.exe is sooo different from the HTML produced on fossil-scm.org -- what's the skin of your repo? JavaScript issue? Only the arrows and boxes of the timeline are missing? The Footer is present? When you hover the empty timeline space: does the mouse pointer change? Does clicking on two different positions bring you to the Check-in-Differences page? ___ 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] Google code shutting down
On 17/03/15 01:08, Ron W wrote: On Mon, Mar 16, 2015 at 3:22 PM, jungle Boogie jungleboog...@gmail.com mailto:jungleboog...@gmail.com wrote: You're right, it won't be private, so you'll be stuck having your password in some rss fetch thing. One would have to weigh the risks. Where I work, we allow - in Fossil - nobody to view the time line because only PCs connected to the departmental VPN can access the repos. Granted this is not perfect, but our IT department told us to do it that way so they wouldn't need to code a password into the RSS-to-email forwarder. It would not work for me. I am a freelancer with multiple clients small clients and need my repos on internet. How you suggest email for tickets be integrated into Fossil? From what little I have read (on this email list) about Fossil's TH1 hooks, it's possible to write TH1 hook code to construct a URL that incorporates the info then ping an email generator using that URL. That would work well for me. It would also be possible to send an email from TCL, if you have fossil compiled with TCL support. Another option would be a more traditional hook interface that can exec a program or script. That world for me as well What would still be missing would be some way of letting users decide which tickets they wanted to be notified about. Customise the tickets table? ___ 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] Google code shutting down
On Sun, Mar 15, 2015 at 3:56 AM, Graeme Pietersz gra...@pietersz.net wrote: No one system has all these, but looking at multiple ticket trackers, the obvious things to me are: 1) email notifications, the most important for me Can currently be accomplished with external (to Fossil) service, using, for example, Fossil's RSS feed to trigger email generation. 2) assigning tickets to developers I have done this. The part that didn't work at the time was the list for the drop down had to be maintained manually. This might be possible, now. I don't know if the TH1 query function allows reading the user table. 3) setting a milestone (only makes sense if you have a project management features fossil does not have anyway) Still could be done via a custom field. Though maintaining the list for the drop down needs admin access to the Fossil repo. If the TH1 query function can read user defined tables, then the list could be maintained via SQL updates. 4) link user names to user pages with other activity (only useful of you have some social networking features) You mean like linking to users's walls? Tickets descriptions and comments can contain wiki mark-up. 5) edit the original report if things change Not sure I agree. While making corrections might be nice, I think comments are better for describing an evolving situation. 6) sub-tasks/child tickets/todo list for ticket In the description and comments, other tickets can be linked,, as can wiki pages and commits. Would be nice if other fields could link as well. Anyway, could create a child ticket using Javascript to populate a new ticket with defaults derived from the currently viewed ticket. 7) better UI - I am sure this can be fixed with relatively simple customisation, and its mostly nice to have features like having the comment form under the comments. ___ 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] Google code shutting down
On 16/03/15 13:30, Ron W wrote: On Sun, Mar 15, 2015 at 3:56 AM, Graeme Pietersz gra...@pietersz.net mailto:gra...@pietersz.net wrote: No one system has all these, but looking at multiple ticket trackers, the obvious things to me are: 1) email notifications, the most important for me Can currently be accomplished with external (to Fossil) service, using, for example, Fossil's RSS feed to trigger email generation. Not easy to do with a private repo without compromising privacy. 2) assigning tickets to developers I have done this. The part that didn't work at the time was the list for the drop down had to be maintained manually. This might be possible, now. I don't know if the TH1 query function allows reading the user table. Nice if it now works. 3) setting a milestone (only makes sense if you have a project management features fossil does not have anyway) Still could be done via a custom field. Though maintaining the list for the drop down needs admin access to the Fossil repo. If the TH1 query function can read user defined tables, then the list could be maintained via SQL updates. That will actually work quite well for many projects. Thanks. 4) link user names to user pages with other activity (only useful of you have some social networking features) You mean like linking to users's walls? Tickets descriptions and comments can contain wiki mark-up. That relies on people remembering to do it - procedure for something that could be painless and uniform if automated. Fossil does not have use pages as such, but it does have pages for a timeline for that user: /timeline?u=graeme for example. Ideally we would have a combination of that and contact info on one page. 5) edit the original report if things change Not sure I agree. While making corrections might be nice, I think comments are better for describing an evolving situation. In general, but if the task is changed significantly there is a good case for changing the ticket itself. To take a recent example I came across, you have a ticket to upgrade an application to work with a more recent library version. You then change your mind about which more recent version to upgrade to. A ticket that still says upgrade to version x.y when you are now upgrading to x.z is misleading. 6) sub-tasks/child tickets/todo list for ticket In the description and comments, other tickets can be linked,, as can wiki pages and commits. Would be nice if other fields could link as well. Anyway, could create a child ticket using Javascript to populate a new ticket with defaults derived from the currently viewed ticket. That does not provide the same functionality. It is a partial workaround but relies on manual intervention to ensure the links run both ways, and does not prevent the parent ticket being closed before all child tickets are closed. 7) better UI - I am sure this can be fixed with relatively simple customisation, and its mostly nice to have features like having the comment form under the comments. ___ 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] Google code shutting down
On 16/03/15 13:30, Ron W wrote: On Sun, Mar 15, 2015 at 3:56 AM, Graeme Pietersz gra...@pietersz.net mailto:gra...@pietersz.net wrote: No one system has all these, but looking at multiple ticket trackers, the obvious things to me are: 1) email notifications, the most important for me Can currently be accomplished with external (to Fossil) service, using, for example, Fossil's RSS feed to trigger email generation. Using RSS does not really work, not only because of the problems with private repos, but because it does not allow users to choose which tickets they get notifications about. Is it possible with some customisation of the tables (adding a table to store which users wants notifications of which tickets) and a script (there is a ticket change hook 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] Google code shutting down
On Fri, Mar 13, 2015 at 9:08 PM, Jan Danielsson jan.m.daniels...@gmail.com wrote: On 13/03/15 20:55, Richard Hipp wrote: Few organizations have the problem that the full power of Git solves. And yet many organizations voluntarily take on the problems that come with using Git. Weird. One shouldn't underestimate the power of because everyone else does it. I agree. People tend to move to the very next cool thing because it sounds good and modern, or better, more modern that the one they are currently using. And then we assist to group switch over technologies. Personally, I tend to use several technologies comparing them on the field before choosing the right one. In the past I had the opportunity to keep projects under git and others under hg and that allowed me to see what was better for me. I admit this is an opportunity that is not always possible (for instance, if you had to participate in a project hosted on github you are sticked on git). Today I'm using git and fossil for smaller projects (with smaller I mean where I am the only developer). I have to admit that a feature I like very much about git is the rebase: before pushing a patch it allows me for a good review. I totally understand the point of fossil against it, and I think there are cases where git behaviour is better and cases where fossil's one is. I use Emacs+magit and I have to say it allows for a very easy and automated git experience (assuming you are used to Emacs, of course). That is one thing I miss with regard to fossil, even if it is not stricly related to the project itself. Luca ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
