Re: [fossil-users] Git-v-Fossil. Was: Google code shutting down
At Sat, 14 Mar 2015 13:33:31 -0700, Andreas Kupries wrote: On Fri, Mar 13, 2015 at 8:46 PM, Timothy Beyer bey...@fastmail.net wrote: At Fri, 13 Mar 2015 20:23:51 -0400, James Moger wrote: You have a great solution. If not then... 5. Corporate users/teams need hooks to integrate with CI notification systems. Partial check. I see there are per-repository hook points, but they seem undeveloped. 6. Corporate users/teams need active notifications: mail, Slack, HipChat, Glip, etc Semi-existing with external tools. See http://core.tcl.tk/akupries/fx/index At least in my view, the ticketing system would be more useful with more hooks for ticket editing and submission. I wrote a vastly more powerful interface to the ticketing system that we use internally, Are the sources of this interface openly visible somewhere, i.e. OSS ? Unfortunately, not yet. At some point I am going to try to persuade my boss of the merits of releasing the source code, particularly to the ticket search capabilities. Tim ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Git-v-Fossil. Was: Google code shutting down
At Fri, 13 Mar 2015 20:23:51 -0400, James Moger wrote: You have a great solution. If not then... 1. Corporate users/teams need client/server with a centralized/canonical repo. Check. 2. Corporate users/teams need multiple-repositories. Check, although configuration consistency/maintenance scales linearly with the number of repos. There appears to be shared authentication, so that is good. But authorization must be maintained for each repo. 3. Corporate users/teams need to be able to manage repo lifecycle (create/delete). Missing. 4. Corporate users/teams like to have overviews/dashboards of multiple repositorires - repository groups are a crowd favorite. Graphs are pretty. Missing. For the extent of my own open source projects, I would like a dashboard to promote awareness of my other (often related) open source projects. 5. Corporate users/teams need hooks to integrate with CI notification systems. Partial check. I see there are per-repository hook points, but they seem undeveloped. 6. Corporate users/teams need active notifications: mail, Slack, HipChat, Glip, etc 7. Corporate users/teams need LDAP/PAM/Windows authentication - especially LDAP. We use fossil extensively where I work, for almost any imaginable use, and LDAP authentication would be hugely beneficial. The other changes that you mentioned sound quite useful as well. At least in my view, the ticketing system would be more useful with more hooks for ticket editing and submission. I wrote a vastly more powerful interface to the ticketing system that we use internally, and as far as that is concerned, I don't know of a way allow inline editing of tickets on the ticket list view, at least not without using the edit page as a ticket listing page. If the JSON API supports such hooks in the future, that would be amazing. This is a non-trivial list and maybe it's beyond the scope of the intentions of Fossil. Or maybe not. Perhaps if a large company starts using fossil, then they would finance some or all of these features. Regards, Tim ___ 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] (no subject)
At Sat, 30 Aug 2014 09:57:21 +0200, Stephan Beal wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] [1.2 text/html; UTF-8 (quoted-printable)] On Sat, Aug 30, 2014 at 8:41 AM, Stephan Beal sgb...@googlemail.com wrote: Out of curiosity's sake, i went ahead and used the various existing pieces to create a standalone mini-timeilne application (to see if any needed parts are missing). It's entire implementation: And here it is with file listing support (the query for that is more than half the script): http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/finfo?name=s2/timeline.s2 I do want to reimplement the timeline view at some point, so this may prove useful. Good to know that s2 is capable of doing this task. Tim ___ 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] (no subject)
At Fri, 29 Aug 2014 08:33:13 +0200, Stephan Beal wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] [1.2 text/html; UTF-8 (quoted-printable)] On Fri, Aug 29, 2014 at 4:59 AM, Timothy Beyer bey...@fastmail.net wrote: There are some limitations that we worked around, such as the fact that the % symbol has a lot of bugs when used in JSON SQL queries (thus making most wildcard matches with LIKE useless), so I use GLOB with a regular expression for case-insensitivity. If you can post some examples i'd be happy to take a look at fixing them. Hi Stephan, Sorry about the delayed response. I'll get specific queries that failed next week, but as a summary, queries like the following have issues in JSON URLs: foo LIKE '%BAR%' I believe that there is some sort of issue with the way the % symbol is handled. Whereas the following works correctly: foo GLOB '*[Bb][Aa][Rr]*' I've been meaning to submit patches, but I haven't even looked at that part of the code yet, and you probably know it much better than I do. Thanks for the JSON API, it's been invaluable. th1 is extremely limited. libfossil is developing more powerful script bindings: https://docs.google.com/document/d/13gRSl6-bj3LV-OKgE-BsqvqF33UFYW3oa3A2OJC5QSY/view That sounds very promising. My issues with TH1 were namely that I didn't know how to use it in dynamic AJAX type applications, (to start with, I think the TH1 argv API was deprecated, am I correct in this assumption?) and that I couldn't access parts of the database that were crucial to my needs. I'll look into libfossil at some point, as I find fossil the ideal basis for applications based on a versioned datastore. I like TCL and especially TK, so I see a lot of potential in TH1, but it seems to me that JavaScript is already an ideal extension language for most fossil-based web applications. Those permssions are for a reason - imagine what happens if a user sends DROP TABLE blob via the JSON API. Even if we use authenticators which prohibit that (sqlite supports it), being able to query allows them to reach _any_ blob, regardless of access restrictions. I figured that was the reason, and it's perfectly legitimate, but I just wish that there was some way to block all JSON API URLs from outside of the fossil repository, only allowing it to be used in the application itself. Regards, Tim ___ 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] (no subject)
At Sat, 30 Aug 2014 06:46:28 +0200, Stephan Beal wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] [1.2 text/html; UTF-8 (quoted-printable)] On Sat, Aug 30, 2014 at 5:59 AM, Timothy Beyer bey...@fastmail.net wrote: foo LIKE '%BAR%' I believe that there is some sort of issue with the way the % symbol is handled. When passing anything via URLs, '%' needs to be encoded as %25 - it's a special HTTP character. I tried that encoding previously, but it only worked in some cases. I don't remember the specifics. I'll gather the examples that didn't work as soon as I find where I notated them. :) Regards, Tim ___ 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] (no subject)
At Thu, 28 Aug 2014 11:42:58 -0400, Todd Niec wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; us-ascii (quoted-printable)] [1.2 text/html; us-ascii (quoted-printable)] Hi, I am new to fossil as well as this list, so I apologize if this posting is off-topic, answered elsewhere, or inappropriate in any way. I am looking at using fossil as a low-footprint, off-line bug-tracking/ticketing system. At work I am developing a ticketing system that non-programmers will use internally, with no modifications to fossil itself. If you have similar needs to our company, you will make heavy use of the JSON API and JavaScript to get the right UI widgets, and to get things customized in a way that non-developers will use the software (one issue that they complained about in particular was the existence of the View Ticket page). I implemented full search capabilities, many new input widgets, among other things, so it is very flexible. There are some limitations that we worked around, such as the fact that the % symbol has a lot of bugs when used in JSON SQL queries (thus making most wildcard matches with LIKE useless), so I use GLOB with a regular expression for case-insensitivity. Further, TH1 is very limited, so even in the case of static SQL queries, you may still need to use SQL through the JSON API, because queries within TH1 arbitrarily prohibit many tables (I did a look up on the list of logins for a multi-select form, for example). I find it annoying that users have to be an Administrator or Super User to access the JSON api for SQL queries, as I'd like to choose which tables they are able to query or not, but then again, it is a distributed version control system, so it probably doesn't make sense to have fine-grained security in the first place. Regards, Tim ___ 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 extras] versus symlinks
At Thu, 10 Jul 2014 17:54:49 +0200, Stephan Beal wrote: i apologize if i gave that impression. i was refering to re-thinking in terms of fixing, as opposed to removing. i would not, in fact, mind if symlink support was dumped (i have always felt it falls outside of fossil's core, but i also know i'm in the minority there), but it can't be removed while retaining compatibility, and people do indeed use it. i have not added it to libfossil yet, but will indeed have to at some point, or risk alienating any repos which use them. No worries. I just wanted to make sure that the developers were aware that there are use cases for it, but perhaps it is not a popular feature, or is at least misunderstood. I use fossil for both software development and sysadmin tasks, and I while I have to admit that I only want to follow symlinks for the latter, it is a huge benefit in that case, and I strongly suspect that people who complain about it just want allow-symlinks set to on in the default configuration, which I wouldn't disagree with (and the way it is worded is counterintuitive). Regards, Tim Disorganization is a constant on my end ;). :) Regards, Tim ___ 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 extras] versus symlinks
At Thu, 10 Jul 2014 09:52:13 -0700, Matt Welland wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] [1.2 text/html; UTF-8 (quoted-printable)] What is allow-symlinks set to for you? From context it sounds like it is set to yes. If so this is *terrible* behavior and a bad bug. If it is set to 0 (IMHO an awful option that is default and should not even exist [i] ) then I think what you are seeing is the expected behavior. [i] In my opinion what you put in to a revision control system should *always* equal what you get out. The default fossil behavior of treating symlinks as extensions to the file tree fundamentally violates this principle. No need to debate this again. The fossil devs are adament that this is what they want but for the context of this discussion I wanted to mention my views on this point again. If the user doesn't want the contents of the symlink, then I would make one of the following suggestions: 1) Set allow-symlinks to on, so that it will add the symlinks as files that are not followed, IIRC. This is probably the behavior that the OP wants. I'll admit that this setting should be the default, although I find on to be fairly useless for my applications. 2) Leave allow-symlinks on off, and put any offending symlinks files in the ignore glob, which is particularly useful in the presence of a versioned .fossil-settings/ignore-glob file. I have done this for quite a while, and it has been quite effective and flexible. I don't really understand why people have such strong objections to this method. 3) If adding the file is a genuinely serious issue, consider if the symbolic link should even be in the path of the repository. I'm not trying to play devil's advocate here, but I am curious as to the scenario that the user faces. I assume that they don't have control over what is present in the working directory? (In which case, either #1 or #2 apply). What I don't really understand is, why does a user want the symlink itself? This is likely far less valuable than the data stored inside of the symlink, and likely lacks relevance on other systems. If the symlinks cannot be followed, then how is the user supposed to version data of a portion of the directory hierarchy below the current location? Further, if someone clones the repository on another unix machine, what happens if the path that it points to either doesn't exist, or points to something completely different? Second, versioning the symlink itself, rather than following it seems less portable to me. OSes other than UNIX may not necessarily have symbolic links, so when a user clones that repository from Windows, I'm not sure how the symbolic links would be represented. When they are followed, it just clones the raw files, so I see no portability issues in regard to solution #2. Someone brought up a ClearCase scenario, where the presence of versioned .fossil-settings/ignore-glob is an issue. In this case, I would presume that ClearCase doesn't have a way to exclude fossil centric files? In that case, suggestion #1 applies. But if that is an issue, then why aren't .fslckout and the repository itself issues as well? Tim ___ 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 extras] versus symlinks
At Thu, 10 Jul 2014 20:10:09 -0700, B Harder wrote: It's clear people are split on what The Right Thing To Do is re: symliks. I'm personally not sure; I don't use them in the course of development. That said, I feel like they should *not* be in indirrected-through as a matter of treatment. It's understandable those that _would_ like them to be followed say: they're there, follow them., but what if a link points to /etc? You want to publish your system config files? The funny thing is that the reason above is exactly why I want that feature. Perhaps one man's junk is another man's treasure. :) I know that a lot of people are going to object and say that fossil is not an appropriate tool for system configuration backups, but in my experience it is ideal for that purpose. My issue as far as The Right Thing To Do (TM) goes is that I'm not convinced either is more correct than the other. Although such a restriction wins in safety, it makes fossil significantly less general purpose, so it loses big in extensibility (notably, for system administration tasks). That is why I think the default should be what you and others advocated, but a non-default option should always be available so as to not artificially restrict domains of usage where fossil turns out to be very useful. Tim ___ 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 extras] versus symlinks
At Thu, 10 Jul 2014 21:31:11 -0700, B Harder wrote: It's certainly not cut and dried :) This has been a fairly thought provoking discussion, as in the process of arguing for symlinks, I'm now questioning why I like them so much for backups (I never use them for any of my development repositories). I'm even starting to think that I could work without them, although if I went that direction, I'd want a lot more scripts to ensure that everything is done consistently for security purposes. Tim ___ 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 extras] versus symlinks
At Wed, 09 Jul 2014 14:23:02 -0500, Andy Goth wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In one project tree I have a symlink pointing to a directory outside of the checkout directory. [fossil extras] lists all the files in the referenced directory as extras even though they are not actually part of the checkout. I think they should be omitted. According to the -n option, [fossil clean] would remove the files. That's rather serious. I think symlink handling needs to be reevaluated. Symlinks to files and directories outside the checkout definitely need to not have the effect of the referenced files be treated as if they were part of the checkout. I agree that is a terrifying behavior for the clean command, at least as a default (and _ESPECIALLY_ without undo), but I hope that the ability to follow symlinks remains at least as a non-default setting (eg. the ability to set allow-symlinks to off). The reason why I say this is because I depend on following symlinks to back up a lot of different directories in different places on the same machine, eg. for per system back up, but only for the most important parts of that system. Fossil works very well for this task, but if that feature were removed altogether, it would be an incredibly tedious task, and I would otherwise need about 10 times as many repositories, especially at work, where I keep configuration files under version control for over 10 separate machines (from various parts of each system). I'd hate to require nullfs just to have the ability to maintain that workflow. I think the larger issue is that clean is a pretty dangerous command in general, and probably isn't what most people want (I find addremove to be much safer), in almost any circumstance. I would go so far to say that it might be for the best if the clean command were removed from fossil altogether. I'm still unsure if fossil delete should literally delete the files as well, although that might be a better workflow for beginners (I'm not endorsing either approach on the latter). Regards, Tim ___ 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] Chiselapp.com shutting down
At Thu, 28 Mar 2013 20:52:59 -0400, James Turner wrote: After a couple weeks of debate, I've decided to shut down Chiselapp.com. As the message on the homepage states, new account and repository creation has been disabled. Access to the website and repositories will remain open until May 1st 2013. Hi James, That's really a bummer, I really liked the Chisel service. Thank you very much for hosting it for all of these years, though! Side note to list: Does anyone know of any good fossil hosts right now? I'm thinking of moving my repositories to sourceforge, since someone came up with a way to use fossil unofficially. I'm going to see if the same is possible on BerliOS via cgi, since I already use that service for binary hosting. I think that the Fossil project should aim to have at least one official host to replace chiselapp. Tim ___ 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 1.24 not working via ssh
At Sat, 10 Nov 2012 22:31:57 +0100, j. van den hoff wrote: thanks for responding. I managed to solve my problem in the meantime (see my previous mail in this thread), but I'll make a memo of sshfs and have a look at it. joerg Sshfs didn't fix the problems that I was having with fossil+ssh, or at least only did so partially. Though, the problems that I was having with ssh were different. What I'd recommend doing is tunneling http or https through ssh, and host all of your fossil repositories on the host computer on your web server of choice via cgi. I do that with lighttpd, and it works flawlessly. Tim ___ 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 question about basics of using fossil
At Thu, 7 Jun 2012 12:11:00 +0200, Stephan Beal wrote: And i would go one step further and NOT use fossil for the system files. Fossil does not support file permissions other than the +x bit and does not understand user/group ownership. Without that, using it for managing system-level files is a disaster waiting to happen. If certain files do not have exactly the right permissions... kaboom. I use sudo to edit these files as most of the files are editable only by root. How do I use Fossil in this context? i strongly recommend against it. Others on this list will just as strongly argue the opposite, however. (And we're all right ;) I personally use fossil for (among other things), managing my /etc directory on two different machines. Thus far, I've had no problems, although I took care to ensure that certain offending files were not included. I manage the repository as root, make sure that all permissions remain root only, with no group access, and made the web interface permissions never allow nobody/anonymous (there were other details that I paid attention to, security-wise, as well). That said, I primarily just use it to revert or backup certain files when they change unexpectedly. I don't think that managing the '/' directory under fossil seems like a great idea, but I've been wrong before. :) Tim ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] SSH commands run as user nobody
Dear List, All of the remote ssh commands that I execute (pull/push/sync/clone) try to run as the user nobody. This is a big problem, because I need to make sure that other users on my machine cannot login to the web interface, (eg. I want nobody and anonymous to have no capabilities) and I want to use my named username of beyert. After performing the clone over sshfs, which works fine (although sshfs gives database errors for pull/push/sync), I set the remote-url command as follows: ssh://beyert@[my-domain]:[my-port]//the/remote/path/scripts.fossil I have tried every variation of the password notation that I know of, namely: ssh://beyert@[my-domain]:[my-port]//the/remote/path/scripts.fossil ssh://beyert:*@[my-domain]:[my-port]//the/remote/path/scripts.fossil ssh://beyert:[my-password]@[my-domain]:[my-port]//the/remote/path/scripts.fossil With my secure settings for nobody with no capabilities, I get the following error: Error: not authorized to read I only was able to get the pull/push/sync to work once I gave nobody gio capabilities, which allowed other users on my machine to see the repository. When I looked at the usage logs, that sync operation was recorded as belonging to user nobody, whereas all of my other repository commands belong to beyert. I don't understand why it isn't using the user beyert, which has s capabilities? I also tried setting the environment variable REMOTE_USER to beyert, which didn't help. On both sides, the command fossil user default gives beyert, and my UNIX user on both machines is beyert. I'm using FreeBSD 9.0-RELEASE on both machines, with a snapshot from 2012-03-17. Should I use a newer snapshot? Regards, Tim ___ 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] SSH commands run as user nobody
At Mon, 7 May 2012 05:48:54 -0400, Martin Gagnon wrote: I'm using FreeBSD 9.0-RELEASE on both machines, with a snapshot from 2012-03-17. Should I use a newer snapshot? Yes, this as been resolve recently. Now you have all capabilities via ssh, since one which have ssh access can do whatever he want with the .fossil file. -- Martin G. Thanks! I'll update fossil right away. Tim ___ 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] SSH commands run as user nobody
At Mon, 7 May 2012 05:48:54 -0400, Martin Gagnon wrote: Yes, this as been resolve recently. Now you have all capabilities via ssh, since one which have ssh access can do whatever he want with the .fossil file. -- Martin G. I just tried the version from fossil (2012-05-05 13:53:37 UTC), re-cloned via sshfs due to the same issues, and then set the remote-url to the appropriate ssh path, and the Error: not authorized to read remains. I also did a rebuild on the repository. Tim ___ 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] SSH commands run as user nobody
At Mon, 7 May 2012 06:51:19 -0400, Martin Gagnon wrote: Have you update server side as well? Here is the output of fossil version on the server: This is fossil version 1.22 [7fb59a67dc] 2012-05-05 13:53:37 UTC Here is the output of fossil version on the client: This is fossil version 1.22 [7fb59a67dc] 2012-05-05 13:53:37 UTC I just issued another fossil all rebuild on both the client and the server to make sure that I didn't miss anything. I am still getting the Error: not authorized to read error. First I tried just rebuilding on the client side, then trying the sync, which didn't work, giving the same error. Then I tried closing the repository on the client side, re-cloning under sshfs again, changing the remote-url (where it prompted me for the password as normally, then issuing the fossil sync command. Basically, it displays the Sent: packets as it should, then it gives the Error: not authorized to read, then it prints the received packets. In my testing, the sync never actually updated the repository until I gave nobody expanded permissions, in which the latest revisions were updated on the timeline command. Maybe the fix is in a branch other than trunk? Should I try another branch when installing from the fossil repository? Possibly unrelated: Maybe my issue is specific to FreeBSD? I am testing this under /bin/sh shell (I have my shell even changed to /bin/sh at the moment on the server side to ensure the proper behavior) because the ssh commands do not work under tcsh at all... Tim ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
