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
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] 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] 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] 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 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] 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] 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] 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] 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] New features for merging
On 8/12/2011 6:47 AM, Ben Summers wrote: * Versionable settings +1 This looks like a good way to do this * SSL improvements I have no use for this at the moment myself, but it looks good. I think it's reasonable to expect people who want to use certs to already have the tools for it. * Relative pathname listings I would really like to see this on by default. It's the right way, and the sooner we fix it, the better. I expect tool impact would be minimal since running all commands from the repo root is the only sensible way to make use of the existing output, and output from the repo root is unchanged, right? * empty-dirs setting This is the only one I don't like. I don't hate it, but it feels like an odd hack. -- 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: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] Why do people create branches as a separate step? Was: Unable to sign manifest
On 8/9/2011 10:58 AM, Richard Hipp wrote: Change the subject: Please help me to understand why people want to create a new branch before adding changes to that branch, rather than just waiting until they check-in their edits? In SVN (and possibly others), you have to create the branch first. In Git I still try to make the branch first, because I don't know how to move a commit to a new branch if I forget to add the new branch argument when I commit. The GUI tools I've used for SVN and Git didn't make it easy to put a commit on a new branch. In fossil I often just work and worry about branches later, sometimes several commits later, because I know it's really easy to change it. In those cases, I've usually started working on something and realized part way in that I had better branch for this--a totally stress-free realization with fossil. But sometimes I still make the branch first, because sometimes my thought process begins with Now I'm going to start on New Feature X, and since I've just decided that, I may as well make some manifestation of my intention. I like that both ways are supported, along with the ability to make new branches after the fact. -- 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] Why do people create branches as a separate step? Was: Unable to sign manifest
On 8/9/2011 11:04 AM, Gour-Gadadhara Dasa wrote: Maybe the way how other DVCS work? Which DVCS can create branch along with the commit? I was thinking it was possible and I had done it in git, but I don't remember how or see it in the documentation, so I think I was mistaken. -- 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] Why do people create branches as a separate step? Was: Unable to sign manifest
On 8/9/2011 11:19 AM, Matt Welland wrote: Note: It is annoying to me that fossil branch new foo won't simply branch from the current node. +1 By the way, how does update differ from co in your step 2 below? If you have no edited files, they have the same effect. But if you have some edits that are not yet committed, co will fail unless called with --force, in which case it will overwrite, whereas update will merge your uncommitted changes in to the new branch's files as uncommitted changes. -- 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] The fossil service command
On 7/19/2011 11:27 AM, Paul wrote: Is service really that confusing? I'm more concerned that `fossil serv` becomes ambiguous. (fossil allows unambiguous short versions of all its commands.) -- 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] Fossil not removing files when switching branches
On 7/13/2011 3:45 PM, Richard Hipp wrote: My recommendation is that you never use the close command. It really is not needed for anything. Maybe I should simply remove the close command to avoid confusion? Considering the number of messages we've had over time where someone was expecting open and close to be used together in their daily workflow the way they would open and close a project in an IDE, perhaps, and given that close at most deletes three files, I say, yes, remove the command. -- 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] Fossil not removing files when switching branches
On 7/13/2011 5:48 PM, Brian Smith wrote: I might suggest amending the help command to list commonly used commands by default, and a new switch --all that will display the uncommon ones (such as close). Fine, I guess, but many a smart person trying to learn a new system would use the --all option, so a really helpful help text for 'close' would include THIS COMMAND HAS NO PRACTICAL USE, and since that's the case, it should really just go away and not be hidden. -- 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] Fossil not removing files when switching branches
On 7/13/2011 7:13 PM, Brian Cottingham wrote: was wondering if some of the Fossil internals could be refactored to not need an explicit 'open' command. I.E., Git and SVN don't need an open command- you just cd into a repo's directory and stuff works. Could Fossil be reworked to act similarly? Ok, now I see. In git the repo is a hidden directory containing many files stored in the same directory as the 'working copy' (to use a SVN term). The fossil repo, however, is a single SQLite database file with a special schema. So there is no repo directory to CD into until you open a repo in a directory. Once you've done that (one-time operation), all the commands do work in that dir without further fanfare. I don't see this changing anytime soon, as drh (I believe) regards this as a feature. I agree, fwiw. Besides the coolness of a very portable and backup-able repo file and among other things, it makes it really trivial to have different branches of the same repo open at the same time in different directories without recourse to an outside server (or indeed any server). I expect that's possible in git, too, but of all the git users I know personally, I'm pretty sure none of them know how. (I don't.) -- 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] changes status cmds within sub-directory
On 7/10/2011 9:11 AM, Ben Summers wrote: $ fossil status In sub-directory two: ADDED world.txt EDITED src/display.c 1 other change. Use --show-all option to list all changes. I would rather it work like git and show other changes as well, but relative to the current location. E.g., ADDED ../one/hello.txt ADDED world.txt EDITED src/display.c In SVN it makes sense to have commands act on specific directories only, since any directory can be checked out by itself. With an all-or-nothing approach as is common in the DVCSes, I think adjusting the output so that the paths are useful wherever you are now is helpful, but hiding some changes is a mistake. -- 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] Fossil halts before push.
I sometimes have this problem, but AFAICT it's because I have a couple large repos and sometimes the server is under pretty heavy disk io load. Have to wait a few minutes sometimes. -- 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] Zipping a packaged release -- option to ignore specific folder?
On 5/30/2011 10:46 AM, Tomek Kott wrote: I'm thinking specifically about things like JavaScript that makes the web ui slightly nicer (diff coloring / source coloring). Unless I'm missing an easier way to deal with that? If it works for your project, you could keep your fossil UI tweaks available on a webserver somewhere, and your fossil templates could simply refer to them by fully qualified URL. The niceties would be missing when you're offline, of course, but personally I'd rather have that than fossil ui support files in my project. -- 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] Zipping a packaged release -- option to ignore specific folder?
On 5/30/2011 11:25 AM, Tomek Kott wrote: True, and I do have a website, but to me that kind of ruins the whole self-contained nature of Fossil which I love... Once you have a dozen or more fossil repos, though, it just gets silly to duplicate SCM ui code in each of them. -- 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] [newbie] Can't get started
On 5/25/2011 7:29 AM, Gilles wrote: 1. Should the repository be located at the very top of the directory tree where files will be added and commited? For instance, if the files I'll be adding/committing live below C:\, should the repository be C:\myrepo, or is it OK to locate it anywhere on the hard drive, eg. D:\whatever\lmyrepo? It doesn't matter what drive or folder you put the repo database in, except that you don't want to put it inside your working copy. E.g., if your project is in c:\myproj, the only place your repo shouldn't be is in c:\myproj. Also, you want to avoid storing the repo on a network drive most of the time. 2. Is it OK to have spaces in the path leading to the repo and the files, eg. C:\This is a directory\myrepo, and D:\This is where my files are\some file.txt? Yeah, it's cool. 3. Is it possible _not_ to be prompted for a comment when committing a file? I'd just like to type fossil commit, and be done with it. Every commit has to have a comment, but you can specify it on the command line like this: fossil commit -m my comment 4. Is it possible to open the repository in a DOS box (C:\fossil.exe open c:\myrepo), and add/commit from a Windows application such as a text editor? When I tried this, I got this error: C:\fossil.exe: not within an open checkout I don't really understand what you're trying to do there. At the very beginning of a project, do something like this: fossil new c:\fossil-repos\myproj.fossil cd c:\myproj fossil open c:\fossil-repos\myproj.fossil There is now a _FOSSIL_ file in c:\myproj and nothing else unless you had some files there already. (And it's ok if you did!) You won't need to do the above steps again until you start a new project (or a few other things, but relax for now). 'fossil open' is not a daily activity. Now, say you have some work you want to commit. Assuming you're still in c:\myproj... fossil add . to add all the not-yet-checked-in files here to your commit or... fossil add some-file some-other-file Then... fossil status Make sure that the output matches the branch you thought you were on and shows the files you thought you changed. (Not that fossil will ever be wrong about this, but that you might be.) fossil commit -m Lovely work. Wahoo! So I have no idea what you mean about adding or committing from a test editor. If you have a text editor that will give you a command prompt inside it, then I would expect fossil to work fine so long as you first cd to the project directory. -- 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] [newbie] Can't get started
On 5/25/2011 9:59 AM, Gilles wrote: For instance, with the repository file at the root of C:\ (so I can add any file below that, even in sub-directories), trying to add D:\test.txt triggers the error message: C:\fossil.exe: not within an open checkout. This is correct behavior. If you took your repo and opened it on another computer, either in the c:\ root or in a folder, fossil could restore all the files in exactly the same relation to each other as you had them. They might have a different root or be on a completely different drive, but if you had a file in \foo that referred to ..\bar\otherfile, the reference would still work. But what if you were allowed to add d:\test.txt? What's fossil supposed to do when you open that repo again somewhere else? I don't have a D: drive. Lots of computers have a DVD drive under D:. And even if I have a D: drive, what if I open your repo twice in two different folders on my system? (E.g., assuming it's software, to keep one behaving normally and make my weird changes in the other copy to compare.) So, yeah, all your repo files have to have a common root. It's by design and can't be worked around except by moving files into a common root. (And check out http://en.wikipedia.org/wiki/NTFS_junction_point) And you should really think about your entire-c-drive-is-my-working-copy thing. Maybe it makes sense for your use case, but it's at least a very unusual use of fossil. -- 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] Add/commit from script?
On 5/25/2011 6:07 PM, Gilles wrote: 1. Check if the document has already been added to the repository, and add it if not 2. Commit changes You can just add it every time. Adding a file that's already in the repo is a no-op. -- 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] ticket-groups and creating events from commandline
On 5/4/2011 2:58 PM, Stephan Beal wrote: As i understand, tickets are normal versioned artifacts. Would that not imply that children could be modeled as forks of a parent ticket? Except then you've overloaded forking. Tickets can fork already, there's just no interface to resolve the fork and latest wins. If you make forking mean something else, what do you do with real forks? -- 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] Leaves Now Open By Default?
So this sounds like maybe has more to do with the changing definition of leaf? FWIW, I would *not* expect that merging a branch would close it. In fact, I routinely assume that it does not, as I merge back and forth sometimes between trunk and feature branches to apply bugfixes or freestanding subfeatures from one to the other. -- 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] Leaves Now Open By Default?
On 4/25/2011 4:08 PM, Richard Hipp wrote: I can change that definition so that a leaf is a node with no children of any kind in the same branch. This revision seems to be what Zed wants. But Joshua seems to think that the current definition is better. I'm now pretty sure I don't prefer the current definition--I did get a bit muddled in the leaf vs branch definitions, though. I'm perfectly fine with things working as Zed described. If I'm now following it right, reverting the leaf definition will solve Zed's problem and not create any problems for me. (No version of fossil I've used has caused any problem with this part of my workflow, so I think I'm safe.) (I've not ever experienced Zed's problem with getting leaves to close using the UI. It always WFM, but since I'm the only one working on almost all of my projects and I keep autosync on, I basically never end up with multiple leaves on one branch. Maybe there's a bug with closing leaves in that context.) -- 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] Leaves Now Open By Default?
On 4/25/2011 4:58 PM, Richard Hipp wrote: let's not go thrashing back and forth in a vain effort to please both Zed and Joshua at the same time, which is not possible. What shall it be? Just in case it got lost in the shuffle, I want to reiterate that my initial concern was misguided. I only wanted to make sure branches wouldn't get closed unless I explicitly close them. Pleasing Zed here won't discomfit me in the least :-) -- 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] How can I get the Fossil CSS to show RTL text properly?
On 4/22/2011 2:05 AM, Ron Aaron wrote: When I try to add a .hebrew style (or div.hebrew or p.hebrew), the style does not seem to take effect when I type in for example:div style=hebrew some hebrew/div (nor forp tags). Well, it would need to be class=hebrew rather than style=hebrew. But besides that, you may need to turn on full HTML mode for fossil: otherwise it strips tag attributes like class IIRC. -- 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] About reconstruct command
Not sure about the problems you ran into at the end, but fossil reconstruct is the complementary command to fossil deconstruct. It works on a directory full of artifacts dumped by fossil deconstruct, not on your source code. If you want to add all your files quickly to a new repo, you'd do something like: cd /my/source/tree fossil new ~/fossil/my.fossil fossil open ~/fossil/my.fossil fossil add . fossil commit -m here's all my files -- 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 idea? (not request, just idea)
On 4/11/2011 2:09 PM, Stephan Beal wrote: When viewing the timeline using custom options (e.g. specific date and count parameters), then leaving the timeline (e.g., to log in so that the timeline links are visible), it would be cool if the next click on the timeline line restored my previous state. With persistent sessions, that type of thing would be possible. That would be nice, sure, but you don't need sessions for it. A simple cookie could handle it fine, and you wouldn't have to maintain state on the server. E.g., there's no reason not to provide that convenience to not-logged-in users or to anonymous logged-in users, too, except that if you used sessions for it you could potentially end up with a lot of temporary junk stored in your repo db to handle 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] fossil add somefile.rs = Error
On 03/28/2011 04:33 PM, sky5walk wrote: I get the following error attempting to add a file with the Ampersand() in the file extension. Try with single or double quotes around the file name. -- 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] Ticket 305143bd876f693f446f78d12dbef143c46eec58
On 03/23/2011 01:01 PM, Michael Richter wrote: I'm not sure why the bit rot with Firefox happened Did you just upgrade? 4.0 final came out in the last couple days. We really need that wireshark packet capture to make sense of this. -- 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] Fossil omits the updates through update command.
On Mar 17, 2011, at 11:00 AM, johnfound johnfo...@evrocom.net wrote: On Thu, 17 Mar 2011 16:22:22 +0300, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: That is, my understanding is that it's check-ins (changesets) that are versioned, not files, and so it's the relations between check-ins which are considered when doing merges. If so, then using fossil update ?VERSION? ?FILES syntax violate the Principle of least astonishment. The trouble with the principle of least astonishment is how unpredictable people's astonishment can be. Changing a particular file or files in my checkout to the version of those files in some past or other branch is not a daily need, but I wouldn't call it rare for me. SVN actually does keep track of the revision of individual files, which I always found actually got in my way when all I want to do is replace a file with a previous version. There may be an easier way, but in SVN I always ended up copying and pasting the file contents from a graphical history view. So a former SVN user could easily find the fossil behavior astonishing. It wasn't astonishing to me, and it was a welcome change, but then I had some intervening DVCS experience. Git has no 'update' but uses the checkout verb for switching to a different commit, and like fossil git allows you to checkout only specific files of a given revision. When you do, it behaves just like fossil update VERSION FILES--the file is changed, but no record is kept of what version it came from. I don't consider this a bug, and I would really hate to lose this capability I don't care if it gets a different name, though, if that satisfies others ___ 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] submodules
Wow, didn't know about that either. For your original question, the command is not extract but export. As specified, it just creates the files, which don't then contain any marker that they came from fossil. Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 On Mar 16, 2011, at 3:36 PM, trash tr...@tekwissusa.com wrote: Ok, I think I found the solution. The submodule must be integrated by using fossil open --nested That's not documented, but I'm happy there's a solution. From: tr...@tekwissusa.com Sent: Tuesday, March 15, 2011 3:39 PM To: fossil-users@lists.fossil-scm.org Subject: [fossil-users] submodules I was trying to add to the discussion about submodules in the archives, but not being a power mailing list user I don’t know how. So I apologize for starting this new thread. /myprj/src/... /ip/... whereas ip.fossil is a wholly independent fossil repository In “/myprj/ip” I ‘d like to execute something like fossil extract VERSION|—latest ip.fossil which would not open the repo, but just extract the files. Doing it that way will of course never allow to make changes to /myprj/ip and propagate them back into ip.fossil, since all connection to the repo has been lost. Update of the ip is only by manually executing again fossil extract ..., which is a critical requirement for me. So the question is, does such an ‘extract’ function exist, I wasn’t able to find anything, but maybe I’m just blind. I guess it would be the same as ‘fossil open’ followed by ‘fossil close’ without the complaint that it’s already within an open tree ‘myprj’. Best Regards, Daniel ___ 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
Re: [fossil-users] submodules
On Mar 16, 2011, at 6:11 PM, Ron Wilson ronw.m...@gmail.com wrote: Sorry, export dumps the repository in git-fast-export format, for the purpose of exporting commits from Fossil to git (or other VCS that can import git-fast-export format). Oops--thanks for the correction. I must have been having flashbacks to my SVN days. Surprisingly, fossil won't export a copy of the files without repository info. Closest thing is the zip command, which will create a zip of all files at a given revision. You could combine it with an unzip command line utility to achieve a file export, but it's awkward and a little silly. ___ 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 equivalent commands
On Mar 12, 2011, at 10:57 AM, Federico Ramallo frama...@gmail.com wrote: we are trying to work the fossil way considering our workflow. So we are learning. I just added the git commands to easily explain the actions we are trying to run, It's all good. Since many of us are familiar with git, too, it's a very reasonable way to proceed. The grep command is a really great deal for us because: * is more flexible than Ack (considering searching on .wiki, README and any other file that is not code) You probably know that ack can optionally search all file types or configurable file types. You might also try writing yourself a one-line shell script that makes use of `fossil ls` (to list all files in the project) and one of the text search tools for more control. If the large binaries aren't checked in, then this will automatically avoid searching those. If they are, you'll probably want to filter the list with grep before searching. I believe there has been talk of adding search to fossil, but I don't know about progress on that if any. I think is interesting to know how to rollback a commit. I'm used to just add a new commit removing the changes. That way we keep the history (made a mistake, fixed the mistake) I thought this just came up, but I can't find it. Of course in fossil you can still just add a commit reversing the changes, but another option is to make the mistaken commit the start of a new branch named 'oops' or 'mistake' and immediately close that branch. The record of the error still exists, but the branch timeline is a clearer reference on the actual progress of the code. (To do this, run `fossil ui`, go to the timeline, click on the mistaken commit, click on 'Edit' by 'Other Links:, and use the checkbox and textbox by Branching to move the commit to a new branch. You'll want to mark the Leaf Closure checkbox as well.) Also, What we couldn't find out is how to delete a branch (or at least close it) Branches cannot be deleted (nor can much of anything be completely deleted in fossil!), but to close the branch, use the Leaf Closure checkbox on the details page of the latest commit in the branch. ___ 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] Bug viewing ticket
That's a pretty fossil theme. Is that built-in to chisel, or is it something you added? -- 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] Changing/adding the execute bit to a file...
Only thing I've been able to do is commit a deletion, then add it again. (Just delete and add without actually committing in the middle has no 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
Re: [fossil-users] Deploying A Web Application with Fossil and FTP
On 02/04/2011 04:11 PM, Ondrej Nemecek wrote: Is there some simple way to list files changed between two versions? Then can be upload procedure easily scripted (using common command-line ftp client). `fossil update -n VERSION` shows a list of file changes made when updating to VERSION from the current VERSION, but does not actually make any changes. Since you can also 'update' to revisions in the past, you can use this to see the differences between a past revision and the current. (Though you'd have to reverse the add/remove logic if you keep on the current version and parse the output of updating to the past version.) -- 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] How to deal with ,,submodules''?
I believe you can do it with a bit of a hack-around, but I'm not sure: In your existing repo, set the ignore-glob to ignore the not-yet-existing directory you're going to put the sub-repo in. fossil open the sub-repo in another dir outside of the existing tree. Move the sub-repo working copy directory to the desired location in the existing repo directory. There won't be any integration between the repos, but I believe that this way they won't step on each other's toes. (But test first!) -- 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] value of a just added column
On 02/04/2011 08:01 PM, Ron Wilson wrote: I added a new column to my tickets table, one that I want to use in the WHERE clause of a SELECT. in SQL, anything = NULL is always false. Try where column_name is null -- 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] demo of jsonized timeline
Your format is certainly lighter over the wire, but it's very much not how users of JSON generally do things and expect things to work. I think it's worth some bytes to be unsurprising. (And you can always gzip it over the wire, which will remove most of the size difference.) -- 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] An annecdote on screwing up (and recovering) a broken fossil repo
On 12/23/2010 09:28 AM, Stephan Beal wrote: i was doing some old-school-style refactoring I have done this exact thing (except I used sed and ack instead of perl and find :-) in the last week. I just deleted my _FOSSIL_ file and re-opened the repo in the same dir. -- 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] An annecdote on screwing up (and recovering) a broken fossil repo
ack in default mode ignores both _FOSSIL_ and .fos. ack -u searches both, so changing it wouldn't have helped me either -- 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] overwrite file (a=always/y/N)?
On 12/22/2010 01:33 PM, Russ Paielli wrote: Does that mean I should not close fossil even when I logout or restart my computer? Correct. Fossil does not stay running when you `fossil open`. Open means 'create a working copy', not 'start a background process'. If you have any fossil server or fossil ui commands running (those do create a longer-running process), fossil close will not close them. You can kill them manually if you like (from a process manager or by issuing kill commands on *nix), but it's also fine to let the system kill them when you restart--it won't hurt anything. -- 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] Stash. Was: How should Fossil handle this merge conflict...
To this point all my fossil usage is mostly-solo, whereas I've been using git on small teams. So when I said I miss it from git, I more properly meant it really comes in handy in my usage of git, and I know fossil doesn't have it, and if I were using fossil in the same contexts as I'm using git, what would I do without it?. I was thinking I would need stash if I were using fossil in a team, but I'm now pretty well convinced that I would need stash only if fossil weren't fossil. However, I've never yet used commit --private. I'm not sure whether it would meet my needs or not. My git workflow when pulling updates from my teammates often goes like this: $ git stash $ git pull # look around at what changed, make sure everything I'm interfacing with still works correctly $ git stash pop Granted that fossil will allow `fossil update` even if I don't commit first, still I think I would often want to use a workflow like the above. How does that look in fossil? My best guess is: $ fossil commit --private $ fossil update previous-branch-name # look around ... $ fossil merge private That's not quite as smooth as the git version, and it requires more attention--e.g., I actually updated to the wrong branch when I tried it out just now, forgetting that I was on 'experimental' instead of trunk in the repo I used before I tried it. And now my working copy and repo are in the desired state, except that foo.txt I added is ADDED_BY_MERGE instead of just ADDED, and I've got a private leaf still hanging around. I can live with those, but for once I think the git command is well named: I use it when I want to 'stash' some stuff away for a bit, then bring it back out again. I don't mean it to be a history event, much less one that appears picked out in gold on my timeline--I'm just shoving some stuff aside on my work table and taking it back out again. If I ignore that private branch and later do the same thing again, will everything still work well? Or should I close the existing private branch first (which requires bringing up the gui and at least 4 clicks)? In tentative conclusion, I think `git stash` really does offer something that isn't convenient to do in fossil, but I doubt it's the number one most important thing to add, and I could accept that it might be more complexity than is worthwhile. BTW, I just noticed that there's `fossil merge --backout`. That's not related to this, but it's cool. -- 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] How should Fossil handle this merge conflict...
If I have local changes that I haven't checked in, and the merge would conflict with those changes, including by deleting my file, fossil should say something like: Hey, this merge will conflict with your uncommitted changes to: * File X * File Y Commit your changes or use --force to merge anyway. It's nice that `fossil undo` can back out a merge, but if I accidentally clobber some of my work with a merge, it's entirely possible I won't notice until it's too late to use undo. (E.g., much of my work is in PHP, where even syntax errors or missing 'require'd files won't be apparent until I actually try to use the page that the error is on.) It would be nice to have something like `git stash`, too. Probably the biggest thing I miss from git. -- 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] Problem with Fossil and CGI
On 11/20/2010 11:01 AM, Søren Enevoldsen wrote: The developer of Hiawatha suggested that using URL rewriting might be a better method than PATH_INFO. What is your thoughts on that? PATH_INFO is a very, very common requirement for CGI programs. In Apache and Lighttpd (at least) it 'just works'. Even in Hiawatha it worked fine once you turned it on. It's true that (e.g.) PHP frameworks tend to rely on URL rewriting for prettier URLs, but URL rewriting is done differently on every server. For integrating a CGI program into just about any web setup with minimal configuration changes, PATH_INFO wins easily. -- 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] Is there any mechanism for determining page 'hits' in fossil?
This is a neat hack. There's a race condition where the download count may not increment correctly if two or more people download at approximately the same time, but if the site is low-traffic and nothing too much is riding on these stats, that's probably fine. -- 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] small suggestion for fossil update
+1 -- 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] why would you give out only clone rights?
On 11/02/2010 04:28 AM, Rene wrote: I have some one who wants to clone my repo. If one just want source code then the Time line, Zip Archive is your option. If they want the history, too, then cloning is the way to get it without having to come back to your site all the time. -- 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
[fossil-users] wish we were using fossil
With one of my several hats on, I'm in a small team using git. Another team member just checked some stuff into trunk that should have been on a branch. Nothing else had happened since, so in fossil I would have just edited that commit and put it on a new branch. In git that can't actually be done without danger once other people have pulled, so I had to create a new commit rolling back the changes, then branch and cherry pick the earlier changes, then figure out how to make my new branch shared instead of private. Just want to say thanks for fossil making my life easier on most of my projects, and being able to move commits to another branch after the fact and shared-by-default branches are good features. Also not having a misanthropic command line interface. -- 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] Managing file attributes of repository files
The only way I've been able to reliably set the execute bit when it isn't set already is to: $ fossil rm filename $ fossil commit -m you put your file in, you take your file out $ chmod +x filename $ fossil add filename $ fossil commit -m you put your file in and you shake it all about -- 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] Managing file attributes of repository files
On 10/19/2010 10:00 AM, Richard Hipp wrote: The main complication is getting the permissions to be transmitted reliably through a windows checkout. (Why is it always windows that gives trouble?) Going between *nix and windows systems, it seems every file windows touches gets an execute bit set. SVN handles this by having an svn:executable flag you can set on files. When checked out on a system with *nix-like permissions, the file gets the execute bit flipped, otherwise not. I like fossil keeping track of my actual permissions, but maybe add a `fossil chmod [+-]x filename` for windows only? On windows, the execute bit would be off on new files, untouched on modified files unless they've been fossil chmod'ed. -- 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] In a script, knowing about changes
Seems like you'd need to parse `fossil status`, but it should be quite straightforward to do. Also note that the mixed version scenario that SVN support/inflicts isn't really a possibility in fossil, so you just need the line that looks like: checkout: d2faac0b1aa953d6e29ec188eb8d7f897351fca4 2010-09-30 19:52:05 UTC And then you could check if there were any lines beginning with capital letters, or you could just make an additional call to `fossil changes` and see if there's any output at all. -- 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] Beginners question
The thing that gives me pause is that fossil would not jump branches just for fun. Perhaps you had accidentally opened trunk in your stable directory and didn't notice? (I usually run `fossil status` before I commit, in part to avoid such errors.) Or else is it possible you've come from SVN, and you actually have only opened your repository once (in ~/project) and are trying to use the two directories withing a single checkout as branches? If the latter, fossil (like most everything that isn't SVN) doesn't work that way. To work in two different branches, you'd do something like: $ fossil new ~/myrepo.fossil $ mkdir -p ~/project/trunk ~/project/stable $ cd ~/project/trunk $ fossil open ~/myrepo.fossil $ # add some files $ fossil commit -m my first checkin $ cd ~/project/stable $ fossil open ~/myrepo.fossil $ # change something $ fossil commit -m a stable bugfix --branch stable If you've gotten started in the SVN style, with both branches in separate directories of a single checkout, I don't think there's any way to correct it other than to start over. If, however, you just accidentally ended up on the wrong branch: `fossil undo` only works on update/merge/revert. You can effectively cancel a check-in by using `fossil ui`, going to the timeline, clicking on the commit, clicking on 'edit' (by 'Other Links:'), and using the checkbox and textbox by 'Branching' to move it to another branch (e.g., 'oops') and marking the Leaf Closure checkbox as well. I don't know what happens if you try to use the branching section to try to move a commit to trunk or another existing branch. If your changes are not easy to recreate, follow these steps after the above fiddling in fossil ui: $ fossil checkout branch-you-were-accidentally-on --keep $ fossil status You should see that you're on trunk with a list of changed files $ fossil extras you should see the new files that aren't yet added to the repo $ fossil update branch-you-meant-to-be-on $ fossil status $ fossil extras these should show the same files as before, but should indicate that you're on stable $ fossil add all-the-new-files-you-wanted-to-add $ fossil commit -m hey, now these changes are on the right branch -- 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] Multiple repo setup getting Internal Server Error on Linux
On 09/23/2010 01:42 PM, Arnel Legaspi wrote: Dr. Hipp, some of our developer guys wanted me to ask if there are any plans in the future to create anything that would allow them to convert Subversion repos over to Fossil. Are there any? I looked at doing this myself, and it's complicated by Subversion's everything-is-a-directory model. There aren't actually branches or tags--there are just copies of source trees in directories which you may choose to treat as a branch or tag. -- 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
[fossil-users] How to move everything into a new subdir
I inherited a couple of CVS-stored websites that had the web root as the root directory of the repo. At least they were using version control. I converted the repos to fossil a while ago, and now I'm getting around to moving everything out of the root dir into a www subdir. In case you need to do the same, here's how I did it: $ cd ~/dir-with-open-repo $ mkdir www $ ls -A | grep -v www | xargs -Ixxx mv xxx www/ $ mv www/_FOSSIL_ www/manifest* . $ fossil ls | xargs -L1 -Ixxx fossil mv xxx www/xxx -- 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] user/pass login with https?
On 09/09/2010 10:03 AM, Richard Hipp wrote: I see. Right - fossil sync does not have any idea how to do LDAP authentication. AFAICT, mod_ldap lets Apache use an LDAP directory for authentication information instead of a .htpasswd file. So if I'm reading right, fossil sync wouldn't need to know how to do LDAP authentication, the client would need to do HTTP Basic Auth. And the fossil server would need to trust or be configurable to trust the REMOTE_USER env variable for sync as well as www interface. From memory and packet sniffing, it looks like fossil currently uses its own authentication protocol when syncing. You can test this with basic Apache .htaccess/.htpasswd access controls--no LDAP needed. -- 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] ticket/checkin automatic email
Would be interested in that and in receiving email when tickets are created. 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] Projects Structuring
I used to do the one big repo thing with subversion, but the main reason for doing it that way was that it was a pain to setup a repo in the first place. I have any number of JavaScript and php libraries that I use periodically in different projects, but I don't use the same set each time. Until recently I would just try to remember which was the project that I used a file in most recently and copy that hopefully-current version to the next project. Recently I've started a repo for all my proprietary libs, and I do any development on them there. I copy the current version into a project as needed, or more commonly I run a small build script to create an appropriately concatenated and minified version for use in each other project as needed. I think this is the most prudent path for the including libraries case, since you're really never going to want to just upgrade the libs to the latest version--if the old version is working for this project, you don't need to change it, and if it's not working you'll probably need to make some other changes along with the library upgrade. But I've also been building several web sites/apps from a common foundation recently, and I don't yet have a good way of keeping track of the best version of that foundation in one place. 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] How best to control access to certain files or pages?
If you made wiki access private and source code access public or vice-versa you could do your public stuff as wiki format files to be accessed via /doc (you could set the repo homepage to a /doc file view, too) and keep the your private info in the wiki. Or vice-verse. But if you mean protecting some wiki pages and not others, AFAIK there's no way to 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] Hosted fossil solution
What about give me the option to enter a password on repo creation? Depending on the form layout, my browser will fill in the same one I've used on the site automatically. 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] Why has fossil stopped signing things?
Little while ago fossil stopped signing by default--Richard concluded it was confusing and/or irritating to more people than liked it. Should work again if you turn it on (by GUI or command line). 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] Hosted fossil solution
On 07/31/2010 10:11 AM, James Turner wrote: Alright, I think I have a decent enough solution. I will just mimic fossil's way of storing passwords, which I believe is either in cleartext or a sha1 of the password. The repo id (and maybe the username?--can't recall) is hashed together with the password. You should look at the fossil source for this part. -- 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] Hosted fossil solution
On 07/28/2010 02:37 PM, Wolfgang wrote: I cannot clone the repo to my own machine, because i have to use the published windows version without https support :-( This is why I have concluded it's not practical to use HTTPS with fossil. If I'm going to be working with someone from a client on an app, they probably aren't familiar with SCM at all or at least aren't familiar with fossil, and I can't make it any more cumbersome or sketchy-looking by asking them to download fossil from anywhere unofficial (and I sure don't want to maintain a windows build of my own--not that that would solve the problem, as it would make fossil look like my own pet thing). -- 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] i know i'm doing this wrong (from local to remote repository)
On Jul 17, 2010, at 8:54 PM, Jeremy Suntheimer jsunthei...@yahoo.com wrote: What is the best way to take a local fossil repository and then later creating a remote repository on a remote server? Twice now, i've used ftp to put the fossil file on a remote server, then opened it, then deleted my local repo and cloned from the remote repo. There must be a better way. Instead of deleting your local copy and cloning, keep your local copy and fossil sync it with the remote. Several months ago that didn't work, but it has for some time now. I'm using a mid March build that definitely wasn't the first to support it. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] lost commit message in failed commit
Here's what happened: I have fossil diff up in one window, and fossil commit has popped up vim to edit the commit message in another window. I'm writing a very detailed commit message based on the diff, and I notice along the way that there's a security flaw in the code I'm about to checkin. So I fix the flaw, test the fix, and finish the commit message. Fossil apparently chokes on the fact that I changed something between the time I started the commit and the time I finished writing the message. (Which makes sense, I just didn't anticipate it.) This is the console output: ~~~ $ fossil commit Autosync: http:// Bytes Cards Artifacts Deltas Send: 130 1 0 0 Received: 414 9 0 0 Total network traffic: 328 bytes sent, 462 bytes received vi /--/ci-comment-BDEC06C2866D.txt Reading passphrase from file descriptor 3 You need a passphrase to unlock the secret key for user: Joshua Paine jos...@letterblock.com 1024-bit DSA key, ID AA5058A3, created 2010-01-15 New_Version: 03094b02bc6483cba3660069f83d50bede42790a fossil: tree checksum does not match repository after commit ~~~ All this makes sense, *but* now that ci-comment-BDEC06C2866D.txt file is gone with my very detailed commit message. Output of fossil version is: This is fossil version [73c24ae363] 2010-03-18 14:20:33 UTC -- 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] add empty directory
I have needed this also, and I do: `touch empty_dir/dir; fossil add empty_dir` -- 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] Features request
On 06/30/2010 01:52 AM, Ruslan Popov wrote: When I use git I like its feature to do 'more' showing huge diff. Especially it would be convinient for fossil on Windows. `fossil diff | more` Windows doesn't have much of a command line environment, but that much at least works on my Windows XP test machine. -- 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] ticket notifications
On 06/24/2010 02:39 PM, Jacek Cała wrote: Regarding tickets notification, it would be nice if opening/closing tickets allow starting/stopping time measurement. In this way fossil could count up how long it takes to complete tasks. IMO this is way, way out of scope for fossil, but it wouldn't be hard to build such reports yourself by reading the fossil db or just checking the timeline rss periodically. http://yourserver/path/to/repo/timeline.rss?n=200y=t gives you the last 200 ticket-related events, and it would be trivial to parse with an RSS lib, an XML lib, or just a couple regex. -- 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] scgi for Linux
Only 127.0.0.1 is privileged, right? So can we just not trust X-Forwarded-For: 127.0.0.1 no matter who says it, and not worry if X-Forwarded-For is abused otherwise? -- 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] Praise for fossil
On 05/31/2010 04:59 PM, James Bremner wrote: It is in a little button on the browser navigation toolbar when at the timeline. Wow, that is obscure! That's the pretty standard place to find an RSS feed, actually--not obscure at all... *if* you know that an RSS feed is what you need. Well, this should simplify the design of a timeline monitor tool, if I can find some handy code to consume RSS feeds so I can consolidate and filter out my own updates. In PHP, I have used the feed reading classes from Zend Framework with success. If possible, please share the solution you come up with. This is one of those things I've been hoping to get around to doing eventually. -- 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] A note and some questions multiple users and fossil
On 05/11/2010 07:40 AM, jim Schimpf wrote: This document repository is a very degenerate case since there is really only one file in work. With multiple users they are going to be editing the same file at the same time. I think breaking up a long document into chapters is a common practice. But even with one file, if you're working on different parts of the same document, you should be fine. Fossil should automatically merge non-conflicting changes. Of course, it's possible to have changes that conflict at the human meaning level without conflicting as far a program can tell. E.g., if someone reworks an earlier paragraph that you're trying to reference later. This problem is not unique to proper revision control systems--it happens any time people collaborate and on a document and can even happen when working all by oneself if the work is large enough and/or spread out over enough time. -- 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] Fossil now uses the Simplified BSD License
Thanks, drh. Makes me even more excited about contributing more when I can make 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] ticket assignment
On 05/12/2010 10:37 PM, zachtodd wrote: Jeremy, a per project security attribute that allows all developers to assign to each other is an interesting idea. That's not what's being asked for. In fossil there are a set of available capabilities. For each user, admin can check a box whether that user has a given capability. There are some convenient groupings of capabilities to make it easy to assign common sets to users, and admin can change what capabilities are contained in each grouping. So if there's a capability to be added that doesn't wholly belong to any existing capability, to be consistent with the rest of fossil it should be its own capability that can be assigned or not to any actual user or capability group. E.g., On some of my projects, the repos are private. I've disabled all public and anonymous access, and I've added those capabilities to Reader. Who are Readers for me? They're the several other stakeholders who work with the software I'm developing but aren't developers. I give them source reading access so they can see the timeline, and they can create tickets to document issues they find. I also create tickets for them sometimes when there's some related information gathering, etc.. that needs to be done. In my case, I would give ticket re-assign capability to Readers (them) as well as to Developers (me), since if I create a ticket for the wrong person or someone else has the free time first, I want them to be able to reassign tickets as needed. But this brings up the issue that apparently to use your new ticket assignment system--which lists developers only as possible assignees--I would have to make all my other users developers, even though they shouldn't have write access to the source. I think may be assigned tickets should be one capability belonging to developers by default, and may reassign tickets should be another capability belonging to admins or developers by default. In the small-team proprietary projects I've worked on and the larger open source ones I've observed, reassigning would have been a capability of any developer, limited by group expectations, but if you work with the existing capability system, who gets the capability is easily changed, so I have no strong opinion on whether reassign should be admins-only by default. -- 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] The case for Markdown (yes, I rtfm)
On 05/05/2010 10:53 AM, Twylite wrote: That said, if you really want Markdown, why don't you use something like Attacklab's Showdown (http://attacklab.net/showdown/), which is a Markdown implementation in JavaScript. Write your Wiki pages in plain text, include Showdown in the site header, and with a little fiddling you should be able to have the Markdown rendered into HTML on the browser. That's the plan, though my intention is to render the markdown to HTML at post time and store both the markdown and HTML text. -- 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] Fossil Failing to Clone 170 Meg Repo over 3G Link
What kind of error do you get? If you need a workaround, you can transfer the repo file with scp or rsync (which can pick up where it left off when interrupted) and then fossil sync them. -- 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
[fossil-users] unexpected ticket behavior
I tried to reassign a ticket and append a comment at the same time. (I have an assigned-to field. I'm not sure if I added that or if it's standard.) My changes silently failed--I just ended up viewing the unchanged ticket. After trying this several times, downloading the latest snapshot, and rebuilding my repos to no avail, I eventually did it in two separate steps, and it worked. This is contrary to what I would expect and how other systems work. (E.g., used to be in bugzilla that you couldn't make any other changes unless you added a comment at the same time!) If there's a good reason for having it this way, it definitely should let me know why it's ignoring my changes. (If the reason is to make a clearer history trail, I'd rather fossil just generated two history events from my two-changes-in-one submission.) -- 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] praise/questions for fossil
On 04/08/2010 04:57 PM, Wes Freeman wrote: - Is there a way to host a repository publicly, but make it so that anonymous (or non-logged in) people can't see anything in timeline, etc.? Most of my projects are personal or commercial and I don't need people seeing anything (even a timeline) except people I'd like to share the code with. In the web interface, go to Admin Users. Click 'anonymous' and uncheck all the Capabilities. Click 'Apply Changes'. Do the same for 'nobody'. -- Joshua Paine LetterBlock LLC http://letterblock.com/ Web applications built with joy. ___ 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] can this be done in fossil: hyperlinking to subdir of fossil repo
On 04/07/2010 02:16 AM, Stephan Beal wrote: i tried that, but in CGI mode my index.cgi _is_ my root dir (as far as Fossil CGI is concerned). Wait... so if on a fossil wiki page, you type a href=/fooFoo/a (the leading slash being essential), when you view that page in the browser, fossil has converted your link to a href=/Project/index.cgi/fooFoo/a ? Are you sure? I can't reproduce that at all--for me fossil isn't messing with my hand-written links. 'Cause if it's not messing with the HREF of your links, it doesn't matter what fossil or Apache or the CGI gnomes think your root URL is--a href=/foo is still going to be a link to 'http://this-domain.com/foo'. Locally i don't use CGI, but use fossil ui instead (much more convenient), which of course is rooted in the repo. Right--so such links won't (and never could) work in fossil ui. To make them work in production and on your local dev machine, you'd have to use CGI for fossil on your local machine, too--on the same domain as your local demo pages. -- Joshua Paine LetterBlock LLC http://letterblock.com/ Web applications built with joy. ___ 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] can this be done in fossil: hyperlinking to subdir of fossil repo
On 04/07/2010 06:37 AM, Stephan Beal wrote: i've put a link in the form [/repos] there and it resolves to: http://fossil.wanderinghorse.net/repos/JSONMessage/index.cgi/repos Sure... but if you just write the link in HTML (which fossil wiki allows and allows to be mixed with wiki) instead of wiki markup: a href=/repostest link/a Then you'll have a link to http://fossil.wanderinghorse.net/repos -- Joshua Paine LetterBlock LLC http://letterblock.com/ Web applications built with joy. ___ 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] can this be done in fossil: hyperlinking to subdir of fossil repo
On 04/06/2010 06:10 PM, Stephan Beal wrote: THAT i didn't think of: i could move the demo path outside of the CGI's path while still keeping it in the webroot. That would almost solve my problem, except that i still have to (a) hard-code the server name in the Wiki link and You do not have to hard-code the server name so long as its the same as the fossil repo is being served through. Just linking to /foo/bar means http://whatever-domain-we-are-on-now.com/foo/bar;. It's the / at the beginning that does that--just like a *nix filesystem path: `cd foo` changes to 'working_directory/foo', but `cd /foo` changes to /foo. -- Joshua Paine LetterBlock LLC http://letterblock.com/ Web applications built with joy. ___ 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 GUI for local source tree operations
On 04/04/2010 01:40 PM, Eric wrote: As for the case of removing illegal insertions, I think it is far better to have the real history saying we had these from this date to that date, as you can see, but you can also see that they were removed at a particular time and not used thereafter. That would be better in a lot of ways, but if the problem is copyrighted material, even if the repo duly shows that the project doesn't use X anymore, distributing the repository still means making copies of X and distributing, which (by hypothesis) you don't have the legal right to do. Hence the necessity of shunning or some other equivalent mechanism. -- Joshua Paine LetterBlock LLC http://letterblock.com/ Web applications built with joy. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] be careful what you wish for
So, I was one of the people asking for passwords to be stored hashed (or if I didn't ask out loud, I certainly agreed). Now as I'm trying to admin a small collection of fossil repos for a small collection of users, a problem comes up. At this org, we have three projects that I've put into three fossil repos. I thought I would just copy the passwords from one to the others, but I see that the project-code is also hashed into the stored password, so the password wouldn't work if copied to another repo. Digression Some people were skeptical of hashing the stored passwords at all, since it wouldn't protect the passwords while traveling over the wire: briefly, the idea was to protect users from anyone who has access to the repo file--in case users used the same password elsewhere, as they often do. /Digression All things considered, I'd rather have what we now have than plain text storage, but I don't think the current way is quite right either (apologies for explaining things that most probably already know): * The more common way to store hashed passwords is to add a pseudorandom salt to the text to be hashed and store the salt together with the hash (depending on the system there may be a convention for how to join them, but just concat is fine if they're fixed length or pipe-separated or whatever), so that given a plaintext username and password the salt used for the hash can be retrieved and the submitted username, password, and salt can be hashed and compared to the stored hash. * Adding the project code to the hash means a prefab rainbow table cannot be used to crack the passwords in a repo. * But using the same project code on all passwords means that it's easier to build a custom rainbox table to attack at once all passwords stored in a given repo. * The only plausible benefit of using the project code instead of a random salt that I can think of is to make stored passwords non-portable across repos. (With salt and hash stored together, the lot could be copied to a user in another repo with the same name and used.) But for my use case this is a hinderance, not a benefit, and I can't think of any situation in which it would actually help. So for improved utility (for certain uses, anyway) and slightly improved security, the project code in the hash should be replaced with a per-row random salt. -- Joshua Paine LetterBlock LLC http://letterblock.com/ Web applications built with joy. ___ 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] be careful what you wish for
On 04/03/2010 05:52 PM, D. Richard Hipp wrote: Another (important) benefit of using the project code instead of random salt is that the client already knows the project code, and hence it does not need to do a preliminary round-trip to the server just to get the salt prior to encoding the users password whenever it does a push or pull. D'oh--I forgot that the hash is sent over the wire for authentication as well. Nevermind--I withdraw my argument/request. So if you want to add a user to multiple repositories, you can simply write a script that inserts entries into the USER table of the various repositories with a cleartext password. Or, if you are writing scripts, your script can invoke fossil user password LOGIN PASSWORD --repository REPOSITORY-FILENAME which will cause the password to be inserted hashed instead of cleartext. These don't really solve my problem, as I've only just created the latest project repo. I'll probably add another one or two later on. It would be really nice to be able to copy the users from one project to another in some cases (or have a delegated single source for authentication--maybe the CGI REMOTE_USER variable as someone mentioned recently), but I now agree that my suggestion wouldn't be a good way to achieve it. -- Joshua Paine LetterBlock LLC http://letterblock.com/ Web applications built with joy. ___ 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 GUI for local source tree operations
On Thu, 2010-04-01 at 14:07 -0400, Stephan Beal wrote: If i'm in my src tree under a/b/c and run svn status, i see only the status of stuff under that branch of the tree This makes some sense in SVN because multiple projects and branches are all represented in a single tree. I prefer the way fossil currently works: it hasn't caused me to make a mistake yet, whereas in SVN more than once I've accidentally checked-in only part of my work b/c I happened to be too deep in the folder hierarchy when I typed commit. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil operations deadly slow
So, I had a fossil repo for a web app that has a lot of hands in it. I'm the only code developer (though not the first by many years--repo converted from CVS), but the application serves hundreds of clients, and images and other such customizations for each client are done by others. The directory with these custom images etc. is large, so I left it out of the repo initially. But now those others need to do a lot of work replacing old graphics, so I added the images dir and subdirs so there'd be a safe place for them to get their old versions back and we wouldn't end up with dozens of files renamed to OLDfoo.bar. Now that I've added these image dirs, fossil is inconceivably slow. `fossil status` takes 45 sec on my dev machine, 4.5 minutes on the server. Trivial commits take minutes. The fossil repo is about 1GB. Is this expected-ish behavior for a repo with many files at 1GB? If I delete all these images from any branch I work with, will it get fast again? -- 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] workflow glitch
On Tue, 2010-03-16 at 17:53 -0400, D. Richard Hipp wrote: Seems like I fixed this bug a few weeks ago. What version of Fossil are you using? [02f638a16f] 2010-02-13 12:30:48 UTC Should I be good with the 3/8 snapshot on fossil-scm.org? -- 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] Extra files and new files
What I could really, really use is a way to persistently ignore files and entire directories. It's great to keep all your files that shouldn't be version controlled out of your project dir, but I'm working on someone else's existing website (converted from CVS to fossil, thanks to a handy script posted on this list), and it's years too late now to move the thousands of non-controlled files to a different file tree. -- 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
