Re: [fossil-users] Why do we need a fossil hosting service?
On 03/30/2013 02:59 AM, Stephan Beal wrote: On Sat, Mar 30, 2013 at 4:06 AM, Steve Havelka yo...@q7.com mailto:yo...@q7.com wrote: You're saying that Fossil is intended to be used by few people, or that Fossil is intended not to have a user community? Fossil _repos_ are indeed intended to be used by relatively few people at a time. Fossil is designed for small, relatively tight-knit teams. It does not directly support deep hierarchies of developers like git does. I think the original poster, in mentioning community and the momentum that can come with it, was not referring to the number of contributors to any given project. My suspicion is that most of the repositories on Github have one or a few contributors, too. I think--and speak up please, Matt, if I'm misinterpreting or have misunderstood you--that Matt was obliquely referring to how much better off a tool is when there are lots and lots of people using it, improving it, building auxiliary tools around it, thinking on it, etc. I think it'd be just grand if lots more people used Fossil, and brought their ideas, code, and improvements to the table too. I can't really see a downside to this. That's the sort of stuff that Github has helped do for git, that we'd do well to have built around Fossil. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Why do we need a fossil hosting service?
On 03/29/2013 09:29 AM, James Bremner wrote: Just wondering why we need a dedicated fossil hosting service. I have managed for years without. For example: Copy fossil repository to dropbox folder; make folder publicly available, or privately share it. Done! Am I missing something? Hmm...could I clone a repository directly from your Dropbox-hosted one? Or push changes back to it? James ___ 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] Why do we need a fossil hosting service?
On 03/29/2013 05:56 PM, Richie Adler wrote: Matt Welland decía, en el mensaje Re: [fossil-users] Why do we need a fossil hosting service? del Viernes, 29 de Marzo de 2013 14:38:25: Ability for loosely coupled collaboration (i.e. fork). Not exactly what Fossil was designed for, I believe... Community and the momentum that can come with it. And as far as Hg/Git lovers keep telling everybody how awful Fossil is because is different from their pet tools, it will never happen... ... which I don't think is entirely unintended. Just to clarify... You're saying that Fossil is intended to be used by few people, or that Fossil is intended not to have a user community? Project life beyond the initial developer. Consequence of the one before. ___ 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.?
On 12/31/2012 06:21 AM, Jan Danielsson wrote: On 12/31/12 11:17, Nico Williams wrote: [---] But I feel I must at least address this insinuation that I was trolling. It's obvious that you aren't trolling. You don't have to defend yourself against such nonsense. I agree with Jan. I also think this thread and the mv/rm hostility suggest a change in tone for the mailing list which is more than a little embarrassing. I'm sorry you felt compelled to unsubscribe, Nico. ___ 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.?
On 12/30/2012 03:26 PM, Michael Richter wrote: If I had written a ten-page post explaining in excruciating detail what rebase is, why it matters, and how to adapt it to the Fossil philosophy, who -but who!- would have read that first post? I, for one, would have. I wouldn't necessarily have agreed, mind, because the disagreement may be philosophical, not technical, but I appreciate people putting in actual explanatory effort over it's too much work. I was being (I thought!) considerate. And judging by last night's 30 posts, would it have made any difference to post a thesis-length argument for rebase? And if so, how was I to know that? Or should I have given up at the very first sign of trouble? I'm still baffled, frankly, as to why you don't just use the DSCM that does what you want now instead of tilting at windmills with the one that doesn't do what you want. The Erlang community faces this kind of problem on an almost monthly basis. I really like Erlang, it invariably starts, but I don't like immutable variables, and I want module-level mutable state, and I'd like to be able to overload default function implementations with customized ones, and I'd like a more imperative syntax, and... In the end what they *really* want is Ruby (or Python (or C++ (or ...))) with one added feature from Erlang: easy concurrency. They don't understand that the features of Erlang were set up the way they are for a specific purpose, and a purpose that gets undermined when you remove those features. The easy concurrency is the *least* important of the architectural decisions that went into Erlang, it's just the most visible of them. (Erlang isn't intended as a language for easily writing concurrent systems. It's intended as a language for easily writing *reliable* systems. The fabled nine-nines.) You want rebase (or equivalent) because you want a clean history. I appreciate Fossil *because* of the messy (where for me /s/messy/honest//) history. Because that messy history is a warning. It's a flag saying something went wrong here that shows possibly complicated code issues or problems in work flow or even problems with a developer's habits. If understanding why something got that way is a problem, we enter with another concept that's sadly all too lacking in software: we *document* it. We explain it. We don't just brush it under the carpet and pretend it didn't happen. Except in the case where that messiness occurs in a private branch, and isn't ever pushed back to the central repository. Then the messiness is concealed. It sounds like Nico wants a better UI for managing private branches than a not-in-Fossil's-philosophy history-rewriting mechanism. Especially since, for a few days now, he's been talking about not rewriting history, but doing the rebase-like operations by always making new branches, and not interfering with the existing ones. If I've got this much right, what would that kind of UI look like? -- Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot. --Sergey Brin, demonstrating the emptiness of the don't be evil mantra. ___ 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] why does `fossil rm' not do the real thing?
On 12/15/2012 03:52 AM, Jan Danielsson wrote: On 12/15/12 05:26, Joe Mistachkin wrote: My opinion is that backward compatibility should be retained because various people, including several that may not be involved in this discussion, have existing scripts and other automation that relies upon the current behavior. I'm going to speculate that this will affect very few users in the end (and that they'll survive the change without any problems). Do you actually know of any such cases; if so, would you care to explain the work-flow so we get a better understanding of how they are used (more importantly; so we understand how dangerous such a change would be)? In particular, with the proposed change there's no chance of loss of data as I see it. If the scripts fail, the data is still in the repository (again, no one is suggesting fossil blindly remove files). Throughout all of this, I've been a little at a loss how data loss is _ever_ possible with drh's proposed mechanism. According to the latest proposal, the file will be removed from disk iff it's removed from fossil AND is unchanged from its state in the last checkin. So... the user has checked in this file. It's managed. It's in the fossil repo. They decide they don't want it, and fossil rm it. Fossil removes it from the checkin and from the disk...oh crud, they did want it after all! Well, it's still in the previous checkin, isn't it?? When is it _ever_ going to happen that the user's going to actually lose data under this scenario? ..while the proposed change will affect many users (in a positive way). (And yes, I do believe that numbers matter. Not entirely, but sufficiently in this case). 1. Retain the existing behavior for all current commands and aliases. It is far too dangerous to change the DEFAULT semantics of these commands now. I don't agree. Of those I have introduced to fossil most of them have complained about the mv/rm command (I think I've found a bug..). One user in particular has never used SCM's before, so he had no preconceived ideas with regards to SCM's. I know how bad anecdotal evidence is in a universal discussion, but I firmly believe my friends and acquaintances are representative enough for me to make a somewhat valid extrapolation. If every user that I introduce to fossil who uses mv or rm comes to me and says they've found a bug, then I feel it's a problem in fossil, not the users. Not to mention the times it's been brought up on the mailing list and other Internet-forums. 2. Add entirely new commands named relocate (for mv) and obliterate (for rm) that will perform actions on the repository itself as well as the file system. Obliterate has shun connotations for those who have used Perforce, If we go with different names, I would prefer another name for the commands. mv and rm are good, because they make sense in Unix. As a new user, I would have expected relocate and obliterate to be a database only operations. For me, then rather than two commands which has behavior which doesn't make sense, we'd have four. I vote no, and again reaffirm my vote for the suggestion drh wrote last night (local time). ___ 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 does `fossil rm' not do the real thing?
On 12/15/2012 06:28 PM, Joe Mistachkin wrote: Jan Danielsson wrote: First, I feel you're inventing problems to make arguments in order to exclude features which address real world issues. (A little like the script issue brought up earlier). Straw man argument. Five yard penalty, still first down. Second (slightly off-topic), What's the problem with SSD and large files? I have been using SLC SSD's since 2007, and since 2008 almost exclusively mixed SLC and MLC SSD's on both servers and clients. On two machines I regularly handle multi-GB files, and have not encountered any issues which I haven't encountered with spinning-platter disks. I fail to see why I would suddenly start having issues with large files because I'm using fossil on SSD:s? (which, I'll admit, I have not). The point here is wear-and-tear on the SSD, which have a finite limit of the number of bytes they can write during their useful lifetime. Sorry if this point was not clear in my previous response. So, you're saying that we wouldn't want to remove files from disk when they're removed from the repository, because that action--which probably wouldn't be a daily occurrence, and in my own personal use is a once-every-week-or-so kind of thing--would be potentially bad for SSDs? I'm sympathetic to the idea that software should be written with a certain efficiency or hardware-awareness in mind, but this seems like a bit of a stretch. ...and also, when you revert a deleted file, doesn't fossil need to scan through the entire file to see if it has changed? If you revert a multi-GB file, you'll still need to spend some time waiting for it, no? I was not referring to the performance, see above. There are lots of ways you can screw up, but the important thing is that you can recover. I also think we have to assume that the normal case is that people won't screw up, and assume that normally people double check before they do something. (Wasn't that one of the insults directed at those of us who want real mv/rm? That we just blindly do things without thinking things through? Ironic twist (yes, I know you weren't the one to say it, but someone else did)). I just think there should be a clear division between Fossil commands that interact with the file system and those that do not. I expect the clean and revert commands to deal with modifying files in the file system; however, I would not expect the add, mv, and rm commands to do that. Frankly speaking, I'd expect the opposite, but more than anything else I'd expect that the documentation can tell me what commands do what. And, again, if the user issued the 'fossil rm' and it removed the file from the repo and from disk, couldn't the user just pull it back out of their last checkin, if for some reason they wanted to unmanage it but retain it? Or, put another way, how often have you wanted to delete a file from a repo, but not delete it from disk? Or move it within the repo, but not wanted to move it on disk? Is there any practical reason you're opposed to this minor change in how the command works, or is it an adherence to a principle of making as few incompatible changes as possible? Plus, if you know you're setting yourself up for such a situation, then don't use the real rm; use the command which has retained the old behavior (unmanage, for instance). Bike shedding. The new command, say realrm (or whatever) could just as easily be made to perform the semantics you desire instead of breaking backward compatibility by modifying existing commands. Yes. (I recommend you read through the threads; some of the issues you raise have been discussed previously). Frankly, I've been trying to avoid getting involved in this discussion at all. If people really want mv and rm to perform file system operations, they can already: 1. Write a wrapper script that performs the operations. 2. Customize their local Fossil binaries to include the necessary code. Also, I have read most of the messages in this thread; however, I think it may be next to impossible to read them all. I do not even know how many messages there are in total. Stage 1: (a) fossil rm -f deletes from disk (if it is safe to do so) (b) fossil rm works as currently, but prints a warning message that it will delete from disk in a future release. (c) fossil delete works as currently (d) fossil unmanage added as an alias for fossil delete Stage 2 (after a stage 1 has been released for a while): (e) fossil rm works just like fossil rm -f I agree with (1a), (1c), and (1d). I disagree with all the others, especially (2e). How come all these points you listed aren't issues with other source management systems which have real rm/mv? Frankly, I don't use the those other systems on a regular basis and I really do not care what they do. Sorry. -- Joe Mistachkin
Re: [fossil-users] Obvious solution to the rm/mv problem?
On 12/14/2012 06:15 PM, Richard Hipp wrote: On Fri, Dec 14, 2012 at 8:58 PM, Themba Fletcher themba.fletc...@gmail.com mailto:themba.fletc...@gmail.com wrote: Could I humbly suggest unmanage for the name of the remove-from-repo-and-leave-the-disk-alone command? This would be consistent with the status messages emitted by fossil (I think on merge?) and it's pretty clear from its name what it would do. I thought of that. In fact, I typed it into my previous posting to this list, but then deleted that paragraph before I pressed send. I could support unmanage as an alias for delete. It is suggested to me (off-list) that it would be too disruptive to abruptly change the meaning of fossil rm to start deleting from disk. So I propose a staged implementation: Stage 1: (a) fossil rm -f deletes from disk (if it is safe to do so) (b) fossil rm works as currently, but prints a warning message that it will delete from disk in a future release. (c) fossil delete works as currently (d) fossil unmanage added as an alias for fossil delete I like this a lot, especially (b) as a reminder to delete the file, in the even that I'd forget the -f. Will the 'mv' behavior be changed to work the same way? Stage 2 (after a stage 1 has been released for a while): (e) fossil rm works just like fossil rm -f Yep, +1 to this too. thanks! Steve This could leave us with the following commands: 1. unmanage -- remove from repo 2. delete -- unmanage and attempt to bring the disk to that state 3. rename -- change the name / path of a file in the repo 4. move -- rename as above, and bring the disk up to date I think this could be a pretty nice middle of the road compromise. As for what rm and mv are aliased to at that point -- I for one don't care. It's the continued existence of known safe (repo only) commands that keeps me smiling. -- D. Richard Hipp d...@sqlite.org mailto: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] why does `fossil rm' not do the real thing?
On 12/13/2012 07:38 AM, Richard Hipp wrote: FWIW, I am following this thread with great interest. I think I understand the various points of view. I think most everybody brings up good points, and I encourage this kind of discussion. My current leanings are to change rm and mv as follows: I like these proposed changes. I don't think I've ever done one rm/mv without the other (i.e. rm in fossil without also rm'ing on disk), so this'd save me some steps and typing 100% of the time. thanks, Richard! (1) fossil rm xyx.txt will remove the file xyz.txt from disk if and only if an exact copy of xyz.txt exists under control. If xyz.txt has been modified or if xyz.txt has never been checked in (and the fossil rm is simply to reverse a prior fossil add) then xyz.txt is unchanged. Either way, there are probably no error or warning messages, though I am sympathetic to the argument that there should be a warning message if the file is not deleted from disk. (2) fossil mv abc.txt xyz.txt will rename abc.txt to xyz.txt on disk provided that xyz.txt does not previously exist on disk or if xyz.txt does already exist and its content is identical to abc.txt. If xyz.txt does previously exist and is different from abc.txt (and hence would be overwritten) then the operation just fails out-right with an appropriate error message. It seems to me that the behaviors above are the most intuitive and provide developers with the least amount of surprise. The goal of Fossil (as it should be for any VCS) is to get out of the developer's way and just do the right thing, so that the developer can devote maximum brain-power to working on their application, and expend a minimum number of brain-cycles thinking about Fossil and how to control it. And I think the behaviors outlined above probably best achieve this goal. But I am far from certain of that, so please do continue debating the issue. We want to get this right. -- D. Richard Hipp d...@sqlite.org mailto: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] Fossil design error and possible ways to fix it
On 11/22/2012 05:05 AM, Richard Hipp wrote: (2) Always assume text/x-fossil-wiki for check-in comments that were entered prior to some cut-off date (say 2012-12-01) and assume text/plain thereafter. Perhaps the cut-off date can be changed for individual repositories using a configuration option, with a default value of 2012-12-01 or 2013-01-01. Could new versions of Fossil assume the old behavior on any repository they encounter... unless this configuration option is set, or another internal-to-the-repository flag is set? And then, the only way this flag will be automatically set is when you issue a 'fossil rebuild' under the new versions? Or is this getting to be too cumbersome, just to maintain some backward compatibility? ___ 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] Help improve bot exclusion
My guess is that you don't really want to filter out bots, specifically, but really anyone who's attempting to hit every link Fossil makes--that is to say, it's the behavior that we're trying to stop here, not the actor. I suppose what I'd do is set up a mechanism to detect when the remote user is pulling down data too quickly to be a bot/non-abusive person, and when Fossil detects that, send back a blank Whoa, nellie! slow down, human! page for a minute or five. I'd allow the user to configure two thresholds, number of pages per second to trigger this, and number of seconds within a five-minute window that the number of pages per seconds threshold is exceeded. I'd give them defaults of 3 pages per second and 3 times in five minutes. So, for example, if a user hits 3 links in one second, which can happen if you know exactly where you're going and the repository loads quickly, it's ok the first time, even the second, but the third time, it locks you out of the web interface for a little while. Command-line stuff, like cloning/push/pull actions, ought to remain accessible under all circumstances, regardless of the activity on the web UI. What do you think? On 10/30/2012 03:17 AM, Richard Hipp wrote: A Fossil website for a project with a few thousand check-ins can have a lot of hyperlinks. If a spider or bot starts to walk that site, it will visit literally hundreds of thousand or perhaps millions of pages, many of which are things like vdiff and annotate which are computationally expensive to generate or like zip or tarball which give multi-megabyte replies. If you get a lot of bots walking a Fossil site, it can really load down the CPU and run up bandwidth charges. To prevent this, Fossil uses bot-exclustion techniques. First it looks at the USER_AGENT string in the HTTP header and uses that to distinguish bots from humans. Of course, a USER_AGENT string is easily forged, but most bots are honest about who they are so this is a good initial filter. (The undocumented fossil test-ishuman command can be used to experiment with this bot discriminator.) The second line of defense is that hyperlinks are disabled in the transmitted HTML. There is no href= attribute on the a tags. The href= attributes are added by javascript code that runs after the page has been loaded. The idea here is that a bot can easily forge a USER_AGENT string, but running javascript code is a bit more work and even malicious bots don't normally go to that kind of trouble. So, then, to walk a Fossil website, an agent has to (1) present a USER_AGENT string from a known friendly web browser and (2) interpret Javascript. This two-phase defense against bots is usually effective. But last night, a couple of bots got through on the SQLite website. No great damage was done as we have ample bandwidth and CPU reserves to handle this sort of thing. Even so, I'd like to understand how they got through so that I might improve Fossil's defenses. The first run on the SQLite website originated in Chantilly, VA and gave a USER_AGENT string as follows: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET_CLR 2.0.50727; .NET_CLR 3.5.30729; .NET_CLR 3.0.30729; Media_Center_PC 6.0; .NET4.0C; WebMoney_Advisor; MS-RTC_LM_8) The second run came from Berlin and gives this USER_AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Both sessions started out innocently. The logs suggest that there really was a human operator initially. But then after about 3 minutes of normal browsing, each session starts downloading every hyperlink in sight at a rate of about 5 to 10 pages per second. It is as if the user had pressed a Download Entire Website button on their browser. Question: Is there such a button in IE? Another question: Are significant numbers of people still using IE6 and IE7? Could we simply change Fossil to consider IE prior to version 8 to be a bot, and hence not display any hyperlinks until the user has logged in? Yet another question: Is there any other software on Windows that I am not aware of that might be causing the above behaviors? Are there plug-ins or other tools for IE that will walk a website and download all its content? Finally: Do you have any further ideas on how to defend a Fossil website against runs such as the two we observed on SQLite last night? Tnx for the feedback -- D. Richard Hipp d...@sqlite.org mailto: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] Wiki naming limitations
It seems like, at least for now, you ought to patch your own copy--I'm not seeing any strong general response that that's a good or needed change to make, so you could be waiting a while if you're waiting on the main devs for this. On 10/28/2012 09:57 AM, K wrote: On Oct 26, 2012, Carlo Miron ca...@miron.it wrote: On Fri, Oct 26, 2012 at 4:11 PM, K k...@lightpowered.org wrote: On Oct 26, 2012, Carlo Miron ca...@miron.it wrote: On Fri, Oct 26, 2012 at 1:28 AM, K k...@lightpowered.org wrote: On Oct 24, 2012, Ron Aaron r...@ronware.org wrote: Wouldn't it be better to make this a parameter the user can adjust rather than permitting any length? While this is a more complex solution, I would support it. Perhaps in the Admin area, some option to control the minimum wiki name length, defaulting to 3. Input from others? To me, it seems completely YAGNI. I'm not familiar with that acronym. Would you please clarify? Sorry. http://en.wikipedia.org/wiki/You_ain't_gonna_need_it So should we then just integrate the diff into the official branch which reduces the length requirement of wikis from 3 characters to 1? ^K © -- R K-M-S L ___ 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] bug in error message
Can someone with commit privileges fix the help message on fossil scrub? [steve@localhost ~]$ fossil scrub fossil: use --repository or -R to specify the repository database [steve@localhost ~]$ fossil scrub -R myrepo fossil: Usage: fossil scrub ?REPOSITORY? aaand... [steve@localhost ~]$ fossil scrub myrepo Scrubbing the repository will permanently information. Changes cannot be undone. Continue (y/N)? y [steve@localhost ~]$ will permanently information? thanks! Steve ___ 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 there both a checkbox and text field for adding tags?
Not all of them, I don't think - just the one directly adjacent to the new tag input field. I actually had the same experience as Nolan yesterday..I typed in a new tag name on the edit screen, hit the 'save' button, and the tag text I'd just typed wasn't there. I went to the edit screen again, and saw that there's a checkbox next to that new tag input field, and realized I'd neglected to enter the text AND hit the checkbox. A third solution might be, if the user types something into that input field, automatically select the checkbox? On 07/19/2012 10:55 AM, Richard Hipp wrote: I think I would be very confused about how to operate the edit screen if the check-boxes were removed. Perhaps we can add some javascript that grayes out the text boxes until after the check-boxes are enabled? On Thu, Jul 19, 2012 at 11:24 AM, Nolan Darilek no...@thewordnerd.info mailto:no...@thewordnerd.info wrote: Asked this before but never got an answer, and it seems like an annoying usability issue. When I'm editing a commit, why is there both a checkbox and a text field for adding a new tag to a commit? Would it not make sense to assume that if I've typed text in the add a new tag box, then I intend to add that tag? If it is left blank, then I don't? There is an accessibility issue in that the form labels aren't matched with entries, primarily because there are no label/ elements. So this screen doesn't render terribly well for screen reader users, and it is unclear whether I am canceling a tag or adding a new one. There are two solutions: 1. Use label elements correctly throughout the UI or 2. Just drop the checkbox here. While label everywhere would rock, I think this checkbox is redundant, so seems like removing it would be the easiest accessibility fix here. Thanks. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org mailto:fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org mailto: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] Why is there both a checkbox and text field for adding tags?
On 07/19/2012 10:28 AM, Stephan Beal wrote: Seems to have been just a long-term oversight (no pun intended). i can't say it's ever crossed my mind that a programming tool should need to be screen-reader friendly. It had never occurred to me that the fossil ui wouldn't play nicely with screen readers, so I downloaded a web accessibility add-on[1] for Firefox to see if there were any shortcomings that could be easily fixed. It looks like fossil's already in pretty good shape, and minor adjustments would fix things like: * Most web pages should contain at least one navigation bar. (we have this, but it doesn't seem to be indicated as a navigation element?) * The i element must not be used to italicize text content, instead use heading (h1-h6) elements for heading text or the em element for emphasizing words, phrases or sentences. (easy to fix) and a few others. Anyone else want to give this a try? Does anyone know any visually-impaired programmers, who we could ask to take a look at the fossil ui via their screen reader or braille terminal? [1] this one: https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/ In any case, i've added it to the weekend's todo list, using option #2: 2. Just drop the checkbox here. It is completely redundant, as you say. i'm not yet that removing it will make the intended usage clearer (how do i NOT set the tag once i accidentally typed something?), but it's worth a try. While label everywhere would rock, I think this checkbox is redundant, so seems like removing it would be the easiest accessibility fix here. If i get ambitious i'll do both, but i won't promise. ;) i won't have access to my dev machine until tomorrow night, though. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Why is there both a checkbox and text field for adding tags?
What happens now, if the checkbox is checked but the text field is empty? On 07/19/2012 11:28 AM, Stephan Beal wrote: On Thu, Jul 19, 2012 at 8:26 PM, Steve Havelka smh...@gmail.com mailto:smh...@gmail.com wrote: Would something simpler do the trick? Like this - http://pastebin.com/7k2B5iW9 That's 90% of it, but ignores the special case of the user emptying the value (that case probably increases the code by 8x ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Why is there both a checkbox and text field for adding tags?
Perfect!
On 07/19/2012 11:29 AM, Stephan Beal wrote:
On Thu, Jul 19, 2012 at 8:28 PM, Stephan Beal sgb...@googlemail.com
mailto:sgb...@googlemail.com wrote:
On Thu, Jul 19, 2012 at 8:26 PM, Steve Havelka smh...@gmail.com
mailto:smh...@gmail.com wrote:
Would something simpler do the trick?
Like this - http://pastebin.com/7k2B5iW9
That's 90% of it, but ignores the special case of the user
emptying the value (that case probably increases the code by 8x ;).
Again too soon...
input
type=text id=text onkeypress=document.getElementById('check').checked
= !!this.value/
:-D
i'll wedge that in over the weekend if i don't forget.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Why is there both a checkbox and text field for adding tags?
Actually, use onkeyup instead of onkeypress - the onkeypress event
seems to need an extra keypress to update the checkbox (at least, on
FF10 and ie7/8). onkeyup works as expected.
On 07/19/2012 11:29 AM, Stephan Beal wrote:
On Thu, Jul 19, 2012 at 8:28 PM, Stephan Beal sgb...@googlemail.com
mailto:sgb...@googlemail.com wrote:
On Thu, Jul 19, 2012 at 8:26 PM, Steve Havelka smh...@gmail.com
mailto:smh...@gmail.com wrote:
Would something simpler do the trick?
Like this - http://pastebin.com/7k2B5iW9
That's 90% of it, but ignores the special case of the user
emptying the value (that case probably increases the code by 8x ;).
Again too soon...
input
type=text id=text onkeypress=document.getElementById('check').checked
= !!this.value/
:-D
i'll wedge that in over the weekend if i don't forget.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Markdown engine integrated into fossil
On 05/30/2012 02:28 PM, Natacha Porté wrote: Hello, on Wednesday 23 May 2012 at 15:26, Richard Hipp wrote: Nevertheless, though attached by fraud, the name is still inappropriate, and must be changed before being added to Fossil. Thanks to some invaluable help, I finally managed to get it done (I think). My markdown C library shall henceforth be known as libsoldout. Name chosen in the same theme as markdown and discount, as one of the possible aims (and the one I know best of) of real-life markdowns and discounts, to make room for the new collection. Hey Natacha, Thanks so much for leading the fork of this project! I followed, with some dismay, the news when the whole project name thing blew up a few years ago. I hoped someone would just do the right thing (i.e. forking it, what you've done now) to put that kind of unpleasantness in its place. So I'm happy to see it's finally been done. Now, if only someone would do the same with the GIMP..;) Steve The new repository is available at http://fossil.instinctive.eu/libsoldout/home and unless I misconfigured something, old links should be automatically redirecting to valid equivalents in the new repository. As far as I know, all the unfortunate references have been purged from the code. If there is any traces still lingering, please inform me and I will deal with them as promptly as I can. I have not changed anything in the proposed integration into fossil ( http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown ) since there was no reference whatsoever to the original project in the first place. Known traces still lingering are: + the history of the project, but I'm strongly against rewriting history in general, and I don't believe this case is extreme enough to warrant a breach in the principle; + the static archives of v1.1 of the library, linked from http://fossil.instinctive.eu/ which will be replaced when I release v1.2 (which has just entered beta), probably in one or two weeks; + the reference to a fork in the home page, but since the it's the name of the fork I have no control upon it. That fork should probably not be mentioned at all, it will be removed in the next overhaul of the page, leaving only a reference to sundown, probably within a few weeks too. I there anything else I should do? Thanks for your attention, Natacha Porté ___ 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] Help finding download links. Was: SQLite and Windows Metro Style
I've heard the same complaint a couple of times. I'd suggest, underneath Timelines:, a new line, Source code: browse | download .tgz | download .zip. I'd then put the manifest link after the hash on the SHA Hash: line. I'd also rename the edit link to edit checkin properties and leave it in the right-hand column underneath all the rest, but remove the left-hand Other links text. So, something like: SHA1 Hash: xxyyzz (Record ID: 200) (manifest) ... Timelines: [as it is now] Source Code: browse | download .tgz | download .zip [empty space with same width as the left column] Edit checkin properties On 03/16/2012 09:09 AM, Richard Hipp wrote: Email below, from the SQLite mailing list, demonstrates a common problem with the Fossil user interface: people who are not familiar with Fossil cannot easily find the tarball and zip-archive download links. They seem to be too well hidden. Any suggestions on how we might improve this? -- Forwarded message -- From: *Richard Hipp* d...@sqlite.org mailto:d...@sqlite.org Date: Fri, Mar 16, 2012 at 10:00 AM Subject: Re: [sqlite] SQLite and Windows Metro Style To: General Discussion of SQLite Database sqlite-us...@sqlite.org mailto:sqlite-us...@sqlite.org On Fri, Mar 16, 2012 at 9:49 AM, Philipp Kursawe phil.kurs...@gmail.com mailto:phil.kurs...@gmail.com wrote: Hello How can I download the current WinRT efforts and compile them myself into a WinRT component? Download the latest winRT code from http://www.sqlite.org/src/timeline?r=winrt All I see there is a checkin history. Clicking on files does give me files but no tarbar or something to download the winrt branch. Click to get to http://www.sqlite.org/src/info/cd70bc4b78 then look beside Other Links: and click on either Tarball or ZIP Archive. Phil ___ sqlite-users mailing list sqlite-us...@sqlite.org mailto:sqlite-us...@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- D. Richard Hipp d...@sqlite.org mailto:d...@sqlite.org -- D. Richard Hipp d...@sqlite.org mailto: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
[fossil-users] command line help question
Dear list, I built 1.21 from source tonight (no 64-bit prebuilt binaries), and noticed this in testing: steve@pewter ~/src/tmp/fossil-src-20111213135356 $ ./fossil Usage: ./fossil COMMAND ... or: ./fossil help -- for a list of common commands or: ./fossil help COMMMAND -- for help with the named command or: ./fossil commands -- for a list of all commands So far so good... steve@pewter ~/src/tmp/fossil-src-20111213135356 $ ./fossil commands ./fossil: ./fossil: unknown command: commands ./fossil: use help for more information Huh. So..is fossil commands supposed to list the commands? thanks, Steve ___ 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] problem with illegal characters
If it is just three lines of code that filter out those characters, how difficult would it be to wrap those into a configurable option, enabled by default but with an option to disable for those who really know what they're doing? best, Steve On 3/8/2012 6:22 PM, Matt Welland wrote: I'm in the mood for some long winded editorializing Bob Coder is moving his development team off of AntiquatedSCM and on to one of the fancy new distributed SCMs that are all the rage. They look at git but it seems kinda complicated and one of the devs suggests Fossil. Wow, nice, simple, elegant, reliable, data storage design that looks trustworthy, solves multiple problems with one executable. Cool. But in the evaluation it comes to light that some legacy files with funky characters can't be checked in and the only two solutions are to throw away or rewrite multiple megs of test cases or to maintain a private branch of the Fossil source. Neither option is tenable and Fossil is eliminated. So Fossil loses another potential advocate due to being devoted to a philosophy of enforcing adherence to the lowest common denominator and the ever pragmatic (albeit, bloody complicated) git gains another user. Sure, it is a silly story and who cares, fossil was not written to be everything to everyone. But still, we've seen at least one real world variant of this story reported to the list A strongly worded warning makes sense but I personally think a no-alternative enforcement does not. IMHO a more viable philosophy is to use documentation and methodology to make seamless interoperability between Windows and Unix/Linux possible for teams that need it. Otherwise where possible and where the code cost is not too high, independently make fossil work perfectly on Unix and perfectly on Windows. On Wed, Mar 7, 2012 at 3:16 PM, Leo Razoumov slonik...@gmail.com mailto:slonik...@gmail.com wrote: On Wed, Mar 7, 2012 at 14:30, sky5w...@gmail.com mailto:sky5w...@gmail.com wrote: because of the hassle of re-working their multitudes of files or create/maintain Fossil branches using Richard's suggestion. If square bracket limitation is the only thing that make fossil unacceptable to you then, please, consider making your own fossil branch as Richard suggested. Actually, I found maintaining my own fossil branch quite easy. And my changes are larger and more intrusive that commenting out couple of lines of code. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org mailto: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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A little self-promotion
On 11/16/11 4:11 PM, Ron Wilson wrote: On Wed, Nov 16, 2011 at 4:15 PM, Jacek Całajacek.c...@gmail.com wrote: and wonder why fossil is by default so humble to not include a link to its web site in the footer. Maybe to encourage users to contact their project leader first? In my team, I've been handling the questions. For public-facing repos, this is a great idea. It's like how Wordpress has its link at the bottom of the default theme, a cheap and easy way to bring more people to the project. I'm not sure if anyone would actually be confused about whose project it is, just by the presence of that link. ___ 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 is Awesome
On Tue, 25 Oct 2011 18:51:05 -0700 Caleb Gray ca...@calebgray.com wrote: [trimmed ...] What are the community's feelings on jQuery? I get the gist that externals are trying to be avoided, so that's why I'm asking, I would love to write a library that turns the current site in to a highly interactive version without touching the HTML or CSS at all. I think a well-made js-enabled UI could be a wonderful improvement over the current static one. I'd love to see what you have in mind. (in other words, I'm not one of those noscript people..;) ) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] wiki page names can't be less than 3 letters
Hi all, Today, while playing around with an experimental repository, I ran up against the character length limit (3-100 bytes) on wiki page names. The limit is not, I discovered, on the number of characters in the page name, but just the number of bytes, i.e. unicode page names consisting of a single character (such as localhost:8080/wiki?name=☃) are allowed. I asked about submitting a patch (world's smallest, ha) to remove the lower limit and it was suggested I run it by the list. So I'd like to ask, how do you all feel about keeping or removing a lower limit on wiki page name? Want to keep the lower limit, remove it, or mostly indifferent? thanks much, Steve ___ 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?
On 10/5/11 2:19 AM, Eric wrote: On Wed, October 5, 2011 6:14 am, Matt Welland wrote: ... Every time pragmatism loses to philosophy someone, somewhere, is gonna get screwed. But pragmatic decisions made by someone who doesn't understand the philosophy/principles/rules can also cause problems, Sure, but come on. It's a version control system, and the idea I'm talking about is never delete anything. This isn't a particularly heavy philosophy, nor are we treading on particularly new ground. It's an idea that, in daily practice, has some irritating consequences (and the occasional list chatter seems to indicate this, too). And besides, Fossil's already made one acknowledgment that, if it's spam/unwanted/etc, you can delete it, it just doesn't make it easy. I'd just suggest that it could be made easier for other use cases (accidentally-checked-in password file, etc) as well, even if it remained officially discouraged. It is noble to have a philosophy of don't rewrite history but only to an extent. Some obvious and perhaps not so obvious examples have been mentioned in this thread. Those who rewrite history are condemned to repeat it perhaps. I'm not trying to be snarky, but I'm having a bit of trouble following how this familiar aphorism apply here. Are you saying that, if I accidentally committed a password file, and wanted to delete it from my and all other repos, if Fossil let me, then I might accidentally do so again later? But if I had to shun it and then chase down all the other repos and shun it from them all, then I wouldn't? I think fossil has a nice balance here. It is possible to remove stuff but it takes a little effort. Never deleting stuff is just silly. An record of the past that stores irrelevant data is quite likely less useful than a record that has been cautiously cleaned up. Define irrelevant, including how you can be absolutely sure that it applies to any particular case. I'm also not sure why it would be necessary to present a universal definition of irrelevant. How about, instead: Fossil's a good program already but it has one non-technical limitation that causes some occasional friction in use, which has inspired at least one inelegant workaround (export to git, modify, import from git). Or I'd try, we're probably mostly professionals who use the software daily, and we're generally good at what we do but because we're also human, we still make mistakes from time to time, and the software could be more forgiving in helping us fix those? Don't get me wrong, I use fossil on a near-daily basis and I'm generally quite pleased with it. But I also don't think it's a mature program or has finished its development, and I'd just like to toss my two cents in as a mostly-satisfied user, about where I think it could be further improved. ___ 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?
On 10/4/11 4:11 PM, Dmitry Chestnykh wrote: Found it. In the UI, go to the Files section, select a file, click on Shun in the menu bar, and finalize with Rebuild. As has already been said, you don't really want to do that. If you think you do, you do not understand what Fossil is for, nor do you understand the principles of software engineering, nor what you will do in nearly two years time when you need to figure out what on earth you were thinking two years earlier to make you write something so silly, and the only thing that might help you is those files you threw away. If you don't care you don't need Fossil anyway. If someone is paying you to do stuff, you need to care, and you need Fossil or something like it and you need to use it properly. This reply should be shunned from the mailing list. Agreed. Given that we all make mistakes from time to time, like checking passwords into a repo or checking in huge files, and given that there's at least one hacky, clumsy workaround for deleting stuff (export to git, modify, import from git), and given that these sorts of requests (to delete files, branches, etc) do recur, maybe the philosophy of never delete anything still needs further amendment? What I mean to say is, it kinda seems like the software should serve the users first, and the philosophy second. We've already got the shun because it was found to be kind of necessary. And deleting things is a pretty natural kind of operation (... and one where there certainly isn't a technical limitation against it). Saying don't do that is already leading to a certain amount of friction, and I don't imagine that that will diminish as time goes on. It's of course not my software, and I don't have patches to contribute, but I'd still encourage the development team to consider that maybe a delete function wouldn't be such a bad idea. (It could still, of course, be officially discouraged.) ___ 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?
On 10/4/11 4:35 PM, Dmitry Chestnykh wrote: Oh, sorry, I'm not talking about Fossil's philosophy (I'm okay with not deleting stuff), I'm talking about about the tone of the message (nor do you understand the principles of software engineering). Well, I agree with you there, too. : ) ___ 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] any interest in integrating jimtcl w/fossil?
Excuse my bluntness: that sounds like a terrible idea. Tcl is huge compared to fossil, and certainly not installed everywhere by default. And for what benefit? To have a full-blown programming language built in? That of course isn't a benefit in itself. If an organization needs some sort of sophisticated processing attached to a hook, e.g. some verification on commits, let them call an external program, a shell script, a tcl script, whatever. Embedding an interpreter into Fossil itself, to run code called by the hook, seems like entirely the wrong approach. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Escape characters in the wiki
Hi all. This might be a very simple question, but I've poked around a bit to try to find an answer and have come up empty. How do you escape the square brackets [ and ] in wiki-markup, so that they're not turned into links? E.g., array[x] = 1; -- don't want [x] turned into a link. I tried \, [[, and the HTML entities #91; and #93;, but nothing seems to work. Thanks, Steve ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
