Re: [fossil-users] New features for merging
On 8/12/2011 1:09 PM, Joerg Sonnenberger wrote: * Relative pathname listings Not something I agree with. I think you want to implement the git behavior? I find that utterly confusing and it doesn't add any real value. It's tremendously useful for, e.g., my fossil_php_lint script that I use to run `php -l` on all modified or added PHP files before I commit. It means you can pipe (or xargs) the output of any of the affected commands to other processes no matter where you are in the repo and have it actually work. From dealing with large repositories, it makes a lot more sense to follow CVS/SVN here and restrict the operation to the directory currently in and have an option to make it default to the whole tree. fossil is more like git in expected repo layout than it is like SVN. In SVN you *have* to treat everything as directory-relative, since branches and tags are also modeled as directories. I think we're past the point in history where taking design cues from CVS looks like a good idea on the face. It's not hard to turn the new output into what you want, though. E.g.: fossil extras | grep -v '..' -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On 8/12/2011 1:50 PM, altufaltu wrote: 1. Versioned settings: I'd prefer having all settings in a single text file with name=value kind of one-setting-per-line format (although I don't mind a value spanning multiple lines for readability) rather than one file per setting. I thought this at first, too, but one file per setting makes it easier to manipulate with other tools, and it makes it easier to get an idea what happened from the commit log. I haven't tested your branch but would like to know if following would work: fossil commit -m comment ../parent.file ../parent/child.file local.file sub/file.name ... also for other commands like rm, add, etc. This already works, so I would certainly expect it to keep working! -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] Timestamps should be in local time.
On 8/20/2011 10:46 AM, Vikrant Chaudhary wrote: Timestamps should be recorded in local timezone rather than in UTC. 1. It hurts eyes and brain to see the time in UTC and then calculate it in local time. The timestamps in the timeline can be configured to be shown in local time via the web ui: Admin Timeline Use Universal Coordinated Time (UTC). If there's anywhere else that UTC is used and one can't choose the local time view instead, I'd call that a missing feature. 2. For forensics. I'll be able to know which timezone I was while committing that change. But I believe you're asking for time zone information to be stored along with commits so that, e.g., the timeline could show a mix of timezones. I'm a little confused as to when you would not be able to establish where in the world you were for a commit, e.g., by your calendar combined with the date and time. If you routinely switch timezones during the course of a day *and* routinely need to know which you were in when you made a commit, I could see it becoming inconvenient, but I submit that this is probably a *very* fringe use. And if you did this often, you either switch your laptop's timezone a couple times a day, or else you're using different machines, in which case you could just create another fossil user for yourself and associate it with the other machine. And we can always calculate the UTC time anyway. And by storing the time in local time we'll only gain the timezone information in history and loose nothing. If this were determined to be worth doing, it would probably better to keep the storage in UTC so that the DB could readily compare the dates and also store the local timezone at commit time. But I really don't see it. I can see someone wanting the timeline in their own time zone. I can see a distributed team standardizing on UTC so everyone sees the same thing. But it's confusing to show times from more than one zone in the same view. I don't see many people wanting that. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] Testing for a release
On 8/26/2011 2:58 PM, Stephan Beal wrote: * branch-3.7.2 → #9abda6 * branch-3.7.4 → #99bca5 These really are too close--only 1 away in each of RGB so that the first is just an indiscernible smidgen lighter than the second. maybe there should be a minimum distance between color values? But we can't know that without comparing against all existing values, which is of course too much effort. I have no idea what the current algorithm is, but you can enforce minimum distance just by making the algorithm only generate values in steps of 4 (or something like that) instead of 1. Of course this increases the likelihood of outright collisions and not just apparent collisions. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] Testing for a release
On 8/26/2011 3:11 PM, Martin Gagnon wrote: It *could* be a feature, not a bug.. I mean.. if 2 branches have so similar name.. it might be wanted behavior to have very similar color... If two branches have almost the same name, it's much more likely that I actually meant them to be the same and typo-ed at some point than if they aren't similar. In that case, obviously distinct colors are more useful to me. If two branches have almost the same name, more mental effort is required to distinguish them based on name. The colors should help with that job, not make it harder. I consider it likely that I will care about when check-ins occurred on 3.7.4, or whether a given check-in was actually on 3.7.2 or 3.7.4. I consider it much less likely that I would be content to know about the check-ins on both 3.7.2 and 3.7.4 without distinguishing between them. I'm not arguing against the auto-coloring. I like it and I think it will be a real help. I do think that making similar names similar colors is an anti-goal or at least a non-goal. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] Dealing with the mistake branch
On 9/7/2011 12:42 PM, Konstantin Khomoutov wrote: I mean, I fire `fossil ui`, navigate to that commit, click its link, click edit link and now what? Should I go with Make this check-in the start of a new branch named... and enter mistake there? Yes. But what if I already have a commit on that mistake branch? What is the sense of that new word then? It's not a problem. It is a new branch based off whatever branch you were on before, it just happens to have the same name as an existing branch. If for some reason you checkout or update to 'mistake', you'll get the most recent commit tagged with mistake. If you really wanted to go back in time to a previous mistake branch, you'd need the id of the commit to go back to. P.S. I really miss `git reset --hard HEAD^` there. Why jump through all of these non-obvious hoops just to zap the just created commit which is not pushed anywhere yet? I'd welcome a command line method of moving a commit to a new branch, but I prefer the fossil method of making it very hard to destroy your work. You could also just update back to the previous commit (id would be shown as parent of the current commit when you `fossil status`) and keep going. (Creating a fork.) Not as clear to others as moving the erroneous commit, but AFAIK other people updating to your latest work will get the latest commit. So long as you make a correct commit before syncing, the correct commit will be latest. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] First Fossil/REST proto-demo
On 9/12/2011 1:01 PM, Ron Wilson wrote: In my own experience with my personal website, I have found that some service providers (not my web hosting provider, but ISPs between the web host and the browser), inject their own content into anything that looks like text regardless of the file extension or MIME type. I've heard of [free] web hosts that would add advertisements to your content, and I've heard of filtering proxies that would add stuff to your content [to assure you that you're protected!], and I've heard of server worms that would add content to pages, and desktop viruses and browser extensions that would add to web content (to show you more ads or install other malware or other BS). Some of these wouldn't plausibly affect a JSON web service, but I'll buy that some could. HOWEVER, the mere fact that wrapping JSON in a bogus tag protected it from a horribly misbehaved system in the case Clark knows about is no guarantee that it would help in other cases. If you abandon the assumption that HTTP mostly works, on what basis could you possibly decide where to stop in defensively designing this? (Even HTTPS isn't enough--some people live with networks that by design man-in-the-middle all HTTPS connections.) I would strongly oppose breaking compatibility with every JSON processor in the world (and, frankly, looking like idiots to people curious about fossil's web services) to possibly protect against some badly behaved proxies. A cool thing about open source is that people with batshit crazy environments can tweak a system so it works for them if they really can't fix their environment. I'm happy that open source can help people who live with crazy, but I don't want it to make me live with crazy. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] Ignoring CVS/*
On 9/12/2011 4:01 PM, Gé Weijers wrote: Is there any way I can get fossil to ignore all the CVS directories and anything under it? I can't seem to get ignore-glob to do anything useful here. /CVS/*,*/CVS/* should do it -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] First Fossil/REST proto-demo
On 9/12/2011 6:11 PM, Ron Wilson wrote: I am surprised that none of the major JSON parsers would not have any means (either directly or by being called by an XML/HTML parser) to process JSON embedded inside XML or HTML. JSON can be embedded in HTML, but to do this reliably, you must do a lot more unicode and HTML character escaping than is necessary for serving plain JSON. Rails will output JSON formatted that way since some version (but not since always), and PHP added the capability to their encoder in 5.2 or 5.3. The only decoders I know that can natively handle such JSON embedded in HTML are, of course, web browsers. But the parsers for web browsers are monsters, and JSON is designed to be extremely simple to parse. And JSON inside HTML has no inherent meaning--the HTML context obscures the simple here's-an-object concept--so of course what's really happening is that JSON in HTML is plain old JavaScript. Without accompanying code (an assignment statement, at a minimum), it does nothing and means nothing. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] JSON authentication: meshing with the cookie mechanism
On 9/14/2011 4:22 PM, Ben Summers wrote: HTTP basic authentication is widely supported in HTTP client libraries, and much less hassle to use than passing tokens around. The three major downsides with HTTP Basic Auth are: 1) No pretty login page 2) No reliable way to logout in most browsers 3) Requires sending the username and password over the wire 1 and 2 are irrelevant for a JSON API, and fossil's web ui already sends the username and password in the clear over the wire unless you're using HTTPS, so this is no greater risk, and it inherits the protection that an HTTPS setup provides. I vote for HTTP Basic Auth, provided that someone can confirm the major browser AJAX functions support it. (Curl and other libs certainly support it.) -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] conflict between HTML5 and Fossil
On 9/15/2011 8:16 AM, Stephan Beal wrote: (Granted, i don't honestly believe that any existing browsers will remove the TT tag or the A.TARGET attribute, but they are officially deprecated.) The target attribute for the a and area elements is no longer deprecated, as it is useful in Web applications, e.g. in conjunction with iframe. http://www.w3.org/TR/html5-diff/ Deprecating 'target' was a mistake of xhtml and html 4--it's back in html 5. (In fact, there's official support for the target attribute on more elements!) In contrast, tt and other purely presentational tags and attributes are not just deprecated but out completely. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] JSON login demo: is this interface acceptable?
On 9/15/2011 10:18 PM, Ron Wilson wrote: For the password on GET, you could mimic what HTTP-Auth-Digest does. AFAIK, in every programming context where you'd want to make a JSON request, POST is as easy to do as GET. The main reason to support GET at all is to make it easy for people to experiment with the API manually, which would be completely defeated by requiring a two-request login process and hashing. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] Feature request: edit files via web interface
On 9/19/2011 3:57 PM, Stephan Beal wrote: One of the eventual planned features of the up-coming JSON API would be performing a commit. (This can't work nicely with binary data, but that's a limitation we can live with.) If you support base64 encoding, then it leaves open the possibility for people to build binary file capabilities later (e.g., canvas-based image editor or some completely-non-web-browser integration). Also, I wonder if stash commands could be manipulated to put together multi-file commits. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] Feature request: edit files via web interface
On 9/19/2011 5:54 PM, Stephan Beal wrote: i'd like to (at least initially) not consider binary data, nor any features which require that a given client implement (correctly) any given decoding algorithm other than JSON. Any time any algo is added to the client-side interface, the portability drops. base64 encoding turns binary data into an ASCII-safe (and hence UTF8-safe) string, so it could be used to prepare binary data for transmission as a JSON value of string type. Clients could safely treat it as just another string if they don't understand base64 encoding. I'm not trying to tell you what you have to implement, but supporting base64 for sending and/or receiving binary data doesn't really add much to the complexity of the API or client requirements. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] Feature request: edit files via web interface
Last I'll say on the subject, since this is your code after all. On 9/19/2011 7:15 PM, Stephan Beal wrote: But they're then limited by what they can do with it. base64 is useless if you don't have a decoder. But they're not any *more* limited than they are if you don't support binary at all. To the C side it's pretty easy, but adding any sort of encoding inherently limits the clients which can use it. Well, unless you only use it for stuff that fossil treats as binary anyway, in which case no one's limited, because the alternative is not having access at all. and JS cannot natively deal with binary data (that's coming in v5 or whatever new version is coming soon). Standard javascript doesn't have this ability yet, but individual impl have relevant capabilities. E.g., privileged JS in XUL has access to files and can get base64 strings from them, and the canvas element has a toDataURL method that returns base64 encoded data plus a tiny amount of metadata. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] binary in JSON: maybe there is some hope...
On 9/21/2011 9:29 AM, Stephan Beal wrote: his proposal adds binary support to JSON without actually extending JSON with new data types. It won't help you any. All that proposal is about is an alternate, non-text serialization for JSON data to avoid the expense of converting to text and back again, e.g., for an object database or some wire transmission scenarios. Precisely because it adds no types, it doesn't have anything to say about what do I do if the data I want to send isn't one of the JSON types? -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] Scalability, a single file commit and lots of disk reads
On 9/28/2011 11:40 AM, Mike Buckler wrote: my test repo at 40 MB is border line unusable even when run from a fast solid state disk. I have a 1 GB repo that has some irritating lag on my netbook with 5400 RPM drive. But I regularly use 4 repos between 30 and 90 MB and they're all quite snappy. So whatever's causing your problem, I'm pretty sure it's not the physical size of the database. Sorry I don't have more useful info, though. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] ignoring files
On 9/28/2011 1:19 PM, Stephan Beal wrote: But from the wording it sounds like only the fossil extra command is affected. I think this used to be the case, but since some time, the ignore-glob also affects fossil add, which is very helpful. I still type fossil add `fossil extras` most of the time out of habit, but 'fossil add .' now has the same effect. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
