Re: [fossil-users] Perception of Fossil
On Sun, 17 Jun 2018 04:06:50 + Chad Perrin wrote: > On Sat, Jun 16, 2018 at 05:05:48PM +0200, Eduardo Morras wrote: > > > > I partially disagree. If you allow anonymous people to pull / > > commit / merge data to your 'central repository', you can get > > easily spammed. If I pull-request 100 images of 10MB your system > > will go down. Multiply it by several 'funny guys' on more than one > > repository and fossil credibility / reputation will be -1. > > > > People that could pull anything to any repository must be trust > > people. (Don't know if it's correct phrase) > > I think that's a matter for configuration, just like whether to allow > people to self-register through the web UI and what initial > permissions a registered user should have. It is not, in my > estimation, a matter of whether or not this is a desirable feature > *at all*. I'm not against the feature, I was pointing security defects that Dr. Hipps didn't describe in his feature description and could end being a bad implementation. Discovering them after or by third persons could destroy fossil credibility. > This could, in fact, be a very important feature for some team > workflows where there may be some devs who are allowed to do this, > and others who are allowed to commit/push directly (and given the > ability to handle a contributed branch like this, to merge or > otherwise accept). Yes, the concept of core developers with commit bit and developers that submit patches to pr or bugtrack system for commit aproval is common in opensource projects. I'm a freebsd / openbsd fan and it's how those projects work. As fossil has the bug tracking inside it's logical to add this feature. > -- > Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] --- --- Eduardo Morras ___ 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] Perception of Fossil
On Fri, 15 Jun 2018 13:35:13 -0400 Richard Hipp wrote: > On 6/15/18, David Mason wrote: > > I heartily agree with this... A flag to allow a person (including > > Anonymous) to make a commit that would automatically go into a new > > branch like "Patch-1" (each one incrementing the branch number) is > > (a) better than emailed patches, and (b) better than pull > > requests. Primarily because it puts it into Fossil so you can use > > all your standard workflows. > > > > The "Patch-?" branches should not be automatically synced, and if > > you do a sync with some special flag, it should offer each of the > > existing patch branches and allow you to agree to sync it, or not. > > Then there needs to be a way to delete the patch branches (whether > > included into the trunk or not) > > An alternative design sketch: > > (1) Anonymous clones repo CoolApp > > (2) Anonymous makes changes to CoolApp and checks those changes into a > branch named "anon-patch" on her private clone. Repeat this step as > necessary to get anon-patch working. > > (3) Anonymous runs the command "fossil pullrequest anon-patch" > > (4) The pullrequest command creates a "bundle" out of the "anon-patch" > branch and then transmits that bundle back to the server from which > the clone originated. > > (5) The server accepts the bundle and parks it in a separate holding > table, but does not merge it or otherwise make it available to average > passers by. The server then sends email notifications to developers > with appropriate privileges to let them know that a pull request has > arrived. > > (6) Developers who receive notification of the pull request can run a > command that pulls down the bundle and applies it as a private branch > on their own personal clones of the repo. Developers can then either > approve of the pull request by publishing it (marking it non-private) > and pushing it back to the server. Or they can reject the pull > request which erases it from their clone. They might also cause the > pull request to be erased from the holding table on the server. > > Additional notes: > > Prior to step (3), Fossil might require Anonymous to provide contact > information so that developers can get in touch in case there are > questions or requests for clarification. Anonymous might also be > asked to sign a contributors agreement to be included in the bundle > (as an entry in the bconfig table). I partially disagree. If you allow anonymous people to pull / commit / merge data to your 'central repository', you can get easily spammed. If I pull-request 100 images of 10MB your system will go down. Multiply it by several 'funny guys' on more than one repository and fossil credibility / reputation will be -1. People that could pull anything to any repository must be trust people. (Don't know if it's correct phrase) > -- > D. Richard Hipp > d...@sqlite.org --- --- Eduardo Morras ___ 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 performance and optimisation
On Fri, 11 Aug 2017 14:10:32 +0100 "Damien Sykes-Lindley" <dam...@dcpendleton.plus.com> wrote: > Hi, > I was introduced to Fossil about three years ago. It is the first VCS > I have actually used extensively for my own work and as such I > haven't really had much to compare it with. However, now I'm in the > realm of contributing code I am having to learn how to make use of > other systems as well. For the purposes of my experiments, I have > been comparing Fossil alongside Git, as this seems to be the popular > alternative and there is a comparison sheet describing many areas of > difference between Fossil and Git. For the most part, Fossil has many > advantages over Git. Though I couldn't help noticing there seemed to > be a silence on speed comparisons. There is a separate article on > performance statistics that again doesn't even mention speed. > Are there any configurations I may have > missed that may help to optimise Fossil in these areas? If not, are > there any plans to optimise Fossil in the future? Cheers. Damien. For big repositories, you should increase the sqlite cache. Don't know if today fossil 2.3 honors the deprecated default_cache_size pragma/header option, but on Admin tab you can run pragma default_cache_size=2147483648 to set it to 2GB always (afai understand it doesn't use negative values to set cache size in number of pages). I used to "hack" fossil source code to always use big caches for import git or svn repositories. Don't know if there are other ways to execute pragmas before the import, each fossil invocation is independent so setting it as pragma cache_size won't work. HTH --- --- Eduardo Morras <emorr...@yahoo.es> ___ 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] Progress report of Fossil 2.x
On Tue, 28 Feb 2017 21:24:42 -0500 Richard Hipp <d...@sqlite.org> wrote: > > (9) Your feedback is encouraged and appreciated. Could Fossil 2.0 change from page model to widget model? If I want to create a new page, for example a project current status, where I want to show open branchs, future events, last five commit tree graph, number of "fossil clone/pull/push/sync" received, etc..; I create a new current_status.c file and copy paste the code from other pages that implement those widgets, doubling (or worse) the code, bugs and maintenance work. Thanks for your work --- --- Eduardo Morras <emorr...@yahoo.es> ___ 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] Repo Checksum Speedup Idea: flaw in my comment
On Mon, 5 Dec 2016 20:23:50 +0200 Martin Vahi <martin.v...@softf1.com> wrote: > As it turns out, I already made a mistake > at the tree based algorithm. > > The old, proposed, flawed version: > > ... > > array_of_nodes_with_wrong_x_node_hash=unique_by_node_ID( > > clone( > > ob_AVL_tree.array_of_nodes_that_had_changes_on_path_2_root > > ).concat(clone( > > ob_AVL_tree.array_of_nodes_that_have_changed_children > > // change within children means that any > > // of the children changed during the insertion > > // or removal of nodes to/from the ob_AVL_tree > > // after the AVL-tree got (automatically) rebalanced. > > // A change between null and an existing child is > > // also considered a change. > > )) > > ).sort_by_path_length_from_node_to_root_node > > > > ... > > A newer version looks only the changes within > children: > > array_of_nodes_with_wrong_x_node_hash=unique_by_node_ID( > clone( > ob_AVL_tree.array_of_nodes_that_have_changed_children > )).sort_by_path_length_from_node_to_root_node Do you mean a Tree Hash like in dc/adc, bittorrent, emule/edonkey ? They use TTH (Tiger Tree Hash), computing hashs of chunks/flie parts, and from them calculates hash of groups of hashes. This way they know in logN steps what chunk is corrupted, and download again. If yes, I don't think it could replace current checksum. It solves a different problem. If no, I'll reread your mails. > Thank You. --- --- Eduardo Morras <emorr...@yahoo.es> ___ 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] disabled due to excessive bounces (again?)
On Sun, 16 Oct 2016 08:08:46 -0400 Steven Gawroriski <ste...@multiphasicapps.net> wrote: > On Sun, 16 Oct 2016 03:27:02 + (UTC) > "K. Fossil user" <ticketpersonnal-fos...@yahoo.fr> wrote: > > > Hi again, > > Ah I forgot something like this : > > "Your membership in the mailing list fossil-users has been disabled > > due to excessive bounces The last bounce received from you was dated > > 16-Oct-2016. You will not get any more messages from this list > > until you re-enable your membership. You will receive 3 more > > reminders like this before your membership in the list is deleted. > > " > > I would check all of the e-mails you have received and compare them > with the archive on the mailing list site. It is possible that Yahoo > is blocking the e-mails due to much mail (anyone from a Yahoo address > will get a copy of the mails). I have a similar problem from time to time on some lists. Note that my email is from yahoo too. On some lists I don't get my own messages, having "receive own messages" in mail list configuration set to yes. Yahoo is slowing falling down... --- --- Eduardo Morras <emorr...@yahoo.es> ___ 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] Files named "AUX" on Windows
On Wed, 5 Oct 2016 09:37:23 -0600 Warren Young <w...@etr-usa.com> wrote: > Windows actually has a whole pile of limitations on file names, all > of which you could warn about in Fossil under the same argument: Some years ago in Sqlite mailing list (2007?) there was a problem naming Sqlite DataBases with .sdb extension under Windows, system makes a backup of the db file each time it's modified . There are lots of restricted extensions on Windows too, not only on the name. --- --- Eduardo Morras <emorr...@yahoo.es> ___ 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-scm as an SQLite db with schema/data revision control
On Thu, 14 Jul 2016 14:31:46 -0400 Adam Jensen <han...@riseup.net> wrote: > I sent a message last night before joining the mailing list (today) > and I'm not certain if it (last night's post) was distributed to the > list or not. It's not displayed in the list archive yet. Just in > case, here it is: > > On 07/13/2016 06:18 PM, Adam Jensen wrote: > > This might be a bit convoluted but is it possible to use fossil-scm > > as an SQLite db with the schema/data under revision control? If this > > functionality doesn't already exist in fossil, would it be > > difficult, awkward, or crazy to try to implement it? > > > > It seems like such an obvious thing to do that I guess it either > > already exists or it's so technically twisted that it's virtually > > impossible. > > > > If this functionality doesn't exist, how would you do it? > > After thinking a little more about this, it seems like maybe this > isn't something that should be incorporated into Fossil [or SQLite] > but rather this could be a third system that is based on the other > two. > > To add a little more verbiage and description to the basic idea, what > I am imagining is (I'm going to assume that in this new system a > single db file can support multiple databases) an SQLite database > with version control on the schema and data. This might be > accomplished in a fashion similar to the original SCCS - every SQL > command that causes changes to the [working copy] database is saved > in the version history (a fossil-like database in this common db > file). With this, any version of the database could be recreated by > replaying the history. This process could be sped up by saving or > creating snapshots of the database at various moments in its history > (all in the common db file (and, perhaps, read-only)) and then a > specific version can be created by replaying the relevant set of SQL > changes made after the snapshot. (This description is just to get the > idea across; there are probably more clever ways to implement it). You can use the Sqlite session extension to produce patch files between db file versions. It has some restrictions on schema and documentation is scarce, but if I had the same goal as you, I'll try that way. To use it you need Sqlite version >= 3.13.0 www.sqlite.org/sessionintro.html > Another aspect of this third system is the typical fossil-like data > sharing. So basically, this could be a distributed, multi-user > database. Each user would have a local copy (fast access) with their > own branches (write control) but there could be data sharing through > merges. (This probably sounds obvious to fossil users but think about > it from the perspective of sharing database content rather than > sharing a pile of files (source code). > > For fun, and somewhat whimsically, a name for this Fossil/SQLite > hybrid might be DVCSQLite . --- --- Eduardo Morras <emorr...@yahoo.es> ___ 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] Compiling and running Fossil on old hardware
On Sat, 13 Feb 2016 22:41:33 -0700 Scott Robison <sc...@casaderobison.com> wrote: > I wonder if I could build fossil for my old Commodore 64. It would > certainly require a lot of disk swapping. Not virtual memory paging, > literal "Please insert Disk 43" type disk swapping. :) (I know it's a joke but..) A modern OS that works on Commodore64 and other nano/microdevices is Contiki, may a port to run it on an intelligent li-fi lightbulb work? --- --- Eduardo Morras <emorr...@yahoo.es> ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Error in search FTS repository
Hello, I tried to search on sqlite.org repository for 'mmap', it showed too
many results so I re-searched with 'mmap(' because I wanted the function call
(note the additional '(').
https://www.sqlite.org/src/search?s=mmap%28=all
SQLITE_ERROR: statement aborts at 8: [INSERT INTO
x(label,url,score,id,date,snip) SELECT ftsdocs.label, ftsdocs.url,
rank(matchinfo(ftsidx,'pcsx')), ftsdocs.type || ftsdocs.rid, datetime(ftsdocs
Database Error
malformed MATCH expression: [mmap(]: {INSERT INTO
x(label,url,score,id,date,snip) SELECT ftsdocs.label, ftsdocs.url,
rank(matchinfo(ftsidx,'pcsx')), ftsdocs.type || ftsdocs.rid,
datetime(ftsdocs.mtime), snippet(ftsidx,'','',' ... ',-1,35) FROM
ftsidx CROSS JOIN ftsdocs WHERE ftsidx MATCH 'mmap(' AND
ftsdocs.rowid=ftsidx.docid}
Retried on fossil repository, and get similar errors.
Thanks
--- ---
Eduardo Morras <emorr...@yahoo.es>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Css not loading when adding a '/' to url
Hello, When I go to http://www.sqlite.org//src/doc/trunk/README.md instead of http://www.sqlite.org/src/doc/trunk/README.md, the page loads without css and link I follow don't load it neither and the additional '/' is not corrected. Note the second '/' on 'org//src' Tried with '//' and get the same problem. --- --- Eduardo Morras <emorr...@yahoo.es> ___ 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 2.0 (reprise)
On Sun, 15 Feb 2015 23:49:42 -0500 Richard Hipp d...@sqlite.org wrote: Please continue to offer suggestions for improvement. Adding support for plugins/addons, using TH1, TCL, Lua or other embeddable language. Plugin code and data should reside on specific table for each plugin, and passed on push/pull/sync/clone. Examples of plugins/addons: - Project Management (Burnout graphs, TODO lists/check lists, time cost measurements, project statistics, etc...), - Bridges to non-http protocols (mail, p2p, nntp, ...), - Calendar, alarms, notices, - Compilation and test status, import these and other information from other developer tools, - Project specific needs - Cron automatizations, f.ex. deferring hash (md5) or other calculations to idle time. Not everyone will need them and their development can be parallel to fossil-scm, these means that plugins/addons code should not reside inside fossil-scm c code. -- D. Richard Hipp d...@sqlite.org --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Examples of public Fossil repositories
On Fri, 2 Jan 2015 09:34:00 -0500 Richard Hipp d...@sqlite.org wrote: I'm trying to compile a list of interesting public Fossil repositories. My list currently includes: http://www.fossli-scm.org/fossil/ http://www.sqlite.org/src/ http://www.eagle.to/cgi-bin/eagle/timeline http://core.tcl.tk/tcl/timeline http://www.androwish.org/ http://netbsd.sonnenberger.org/ Natacha's public fossil repositories: http://fossil.instinctive.eu/ And, of course, all of the repos on http://chiselapp.com/ Are there any others that I should add to the list? -- D. Richard Hipp d...@sqlite.org --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Receiving old versions
On Sat, 30 Aug 2014 15:03:32 -0500 Andy Goth andrew.m.g...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/2014 2:40 PM, Andy Goth wrote: Now I have been given a few older versions. What's the best way to go about putting them into the repository? I know I can check them in with --allow-older and the --date-override options, though this will produce a very funky timeline display. Is there a better way? I cloned my repository and did the above as a test just to see how bad it comes out. Well, it's pretty bad. Not only is the timeline bizarre, the default diffs are unhelpful too. Diffs are typically against the predecessor version, but in this situation, Fossil's concept of predecessor doesn't match the naïve user expectation. Surprise notwithstanding, this is correct behavior in face of the time paradox. I think my best course of action is to not try to put the old code into the repository unless I am given a more complete archive of historical versions, at which time it might be worthwhile to rebuild the repository with everything put in the right sequence. Of course this blows away all the artifact IDs, but that would be acceptable at this stage. Let's say I do this, using the oldest known version as the initial commit, and everything seems good for a while. But then someone finds an in-between version thought to have been lost. I would update to its predecessor version then check it in with the date override, either allowing the fork or putting it on an branch. The timeline would look mostly good, but only because the predecessor version already existed. Diffs surrounding the newfound would have to be done with explicitly selected from and to versions, but that's a small price to pay for not having to rebuild the repository and trash the artifact IDs. Then a version older than the previously oldest known version is found. Now we're in trouble again. Maybe I could have prevented that last problem by making the initial empty check-in be dated before the project was known to have started, so there would never be anything older than it. Thoughts? Can you try to do it backwards? (don't know if backwards is the rigth word). Create a new repository, import the older source files, pull from your repository. Don't sync or your repository will become fluffed. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Working with large repository
On Mon, 16 Jun 2014 23:08:22 +0200 Baptiste Daroussin baptiste.darous...@gmail.com wrote: Hi, I just want to share some feedback, for fun I tried to convert some of the FreeBSD repositories to fossil to see how it performs I first tried the FreeBSD Documentation repository, to go the easy way I took the FreeBSD git mirror (https://github.com/freebsd/freebsd-doc and run git fast-export --full-tree --all | fossil import --git ../doc.fossil The worked pretty well, and I manage to convert in a few hour the repo, the result it very usable (that wasn't the case a few years ago, some operations where slow) Result is available here: https://fossil.etoilebsd.net/doc if some want to play. At the same time I decided to try with ports and base repository which I would have expected to be a bit more complicated I cloned: https://github.com/freebsd/freebsd and https://github.com/freebsd/freebsd-ports I run the same command for the conversion git fast-export --full-tree --all | fossil import --git ../ports.fossil both are now running for more than 70H and still not finished!!! consuming 100% CPU This is running on pretty descent hardware. hw.model: Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz I guess I would have to run a svndump imported manually if I want a slightly faster conversion to happen, and given how the incremental import works with fossil import --git I cannot imagine running a fossil mirror using that tool. If anyone has ideas on how I can maintain a mirror more easily, tips welcome I tried the same in 2012 an early 2013 without --full-tree, the worse problem I had wasn't the time expended but the size of fossil file while importing. I tweaked fossil import to use 512MB-2GB of sqlite3 cache making it faster. I didn't import from git directly, I splitted it in 2 phases: git fast-export xz -vv --lzma2=preset3,dict=256MiB git.xz xzcat -vv git.xz fossil import git.fossil This way I'm less IO and CPU bounded, Check my email on this list 1st of July 2013. Bapt --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Working with large repository
On Tue, 17 Jun 2014 17:39:45 +0200 Stephan Beal sgb...@googlemail.com wrote: On Tue, Jun 17, 2014 at 5:30 PM, Eduardo Morras emorr...@yahoo.es wrote: git fast-export xz -vv --lzma2=preset3,dict=256MiB git.xz xzcat -vv git.xz fossil import git.fossil That is a _very_ interesting trick. You can pause it, view % of work done, etc... Question to you both: do you know if fossil has generated any delta manifests in the import? By default fossil does not generate delta manifests, but they can potentially save space for large repos. Once fossil has generated _one_ delta, it will allow itself to generate more, but by default it will never generate any. A delta can be forced at commit time with --delta, but i don't know if the git import feature (never needed it) supports something like that. Fossil rebuilds repository after the import and file size shrinks a lot, don't know if it's because delta encoding or something else. The openbsd import to fossil file has +300GB, and shrinks to 1.5GB after rebuild. Didn't have more time to dive in it. A final note, the import is one big transaction. -- - stephan beal --- --- Eduardo Morras emorr...@yahoo.es ___ 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] strcpy() vs strlcpy()?
On 22 Apr 2014 21:35:39 -0600 Andy Bradford amb-fos...@bradfords.org wrote: Hello, As of [2aaae64a59] compiling Fossil on OpenBSD results in a warning: bld/name.o(.text+0x11a): In function `test_ambiguous_cmd': ./src/name.c:742: warning: strcpy() is almost always misused, please use strlcpy() Is this something to be concerned about for Fossil? I know there are other parts of the Fossil build that use strcpy() but this is the first time Fossil proper has used it. Would it be better to use strlcpy()? Don't know, but strlcpy() exists only in *BSD libc, but no in GNU/Linux glibc or Windows. Thanks, Andy --- --- Eduardo Morras emorr...@yahoo.es ___ 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 CGI trick: extensionless CGIs under Apache
On Fri, 11 Apr 2014 12:54:22 -0400 Ron Wilson ronw.m...@gmail.com wrote: Still fails under IE, but I only tried it as an additional data point. (Normally I only use IE to access certain company internal websites that aggressively refuse to work with anything other than IE (any version of IE).) Check this addon for firefox https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher/ It allows change the user-agent and identify firefox as a IE. HTH --- --- Eduardo Morras emorr...@yahoo.es ___ 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 release supporting ssh access?
On Fri, 13 Dec 2013 13:37:40 -0500 David Mason dma...@ryerson.ca wrote: I am really looking forward to the release that includes the proper ssh remote repositories. I can build it for my environment, but I am teaching a course in January and I want the students to submit assignments using their own repositories (and encourage them to use fossil (and SCMs in general), and they use Windows and Linux, so it would be much easier if I could simply point them at the fossil-scm.org site! (If anyone's interested in the details, I'm going to set up accounts that can only run fossil, and give them each their own fossil with them, me, and the TA having access to the repository. Then they can do/submit assignments and the TA or I can mark them, leaving annotation files, mark files, etc.) I love everything I've seen about fossil, but have been waiting for this before using it in production. I don't use fossil through ssh, but a sshfs may do what you want. See http://fuse.sourceforge.net/sshfs.html Don't know if works on MS-Windows. Thanks ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users --- --- Eduardo Morras emorr...@yahoo.es ___ 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 I push changed authentication data? c...@apotheon.net exclusive)
On Wed, 14 Aug 2013 16:57:53 -0600 Chad Perrin c...@apotheon.net wrote: On Wed, Aug 14, 2013 at 04:31:46PM -0600, Andy Bradford wrote: Thus said Chad Perrin on Wed, 14 Aug 2013 16:07:02 -0600: Is there another option for this when developers basically do not have access to the server where the main Fossil repo is located except by way of clone/pull/push/sync? Well, technically speaking, they *do* have access to the main Fossil repo via the tunnel. Have them point their browser to http://localhost:/ As long as they have the capability to reset their own password, they can do this on their own. I guess I should consider running the web interface too, then, if that's the only way to let them change their Fossil passwords. Perhaps there's other way to do that using ldap. This ticket http://www.fossil-scm.org/index.html/tktview?name=ec667f74f8 describes current (2010) status about it. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users --- --- Eduardo Morras emorr...@yahoo.es ___ 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] self-hosted Fossil for a team
On Sat, 10 Aug 2013 20:07:41 -0600 Chad Perrin c...@apotheon.net wrote: Dr. Hipp's series of suggestions have, of course, also been informative for me, and while I do intend to expand capabilities to the point where a separate webserver (probably nginx) is involved for some purposes as described in one of his replies, for now I just need something quick, effective, and secure to get some projects underway. Nginx doesn't support cgi, and as its developers says, it will never have cgi support. --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Single sign-on (Login Group) configuration?
On 10 Aug 2013 21:54:59 -0600 Andy Bradford amb-fos...@bradfords.org wrote: Hello, After having recently discovered the single sign-on functionality provided by the Login Groups configuration, I've started experimenting with it. I must be doing something wrong because it doesn't seem to work: I started a fossil server on port serving fossils out of /tmp. In /tmp I have 3 fossils (new.fossil,one.fossil,two.fossil). I added them all to the same Login Group and added a user to new.fossil named someone. Then I tried to clone two.clone: $ fossil clone http://someone@remote:/two twoclone.fossil Password for Fossil user someone: remember password (Y/n)? y Round-trips: 2 Artifacts sent: 0 received: 1 Error: login failed missing or incorrect password for user someone What have I missed? I googled and couldn't really find any documentation for how this is supposed to work, and I even grep'ed the www directory in the fossil repository to no avail (next step sources). Here's some data from the config table in the two.fossil DB: project-code|f2b6f81f58bff6b8e6b8be1a5c1a679d7402351b|1376190998 project-name|Two|1376191759 peer-repo-3aeaa6385a3e39cf|/tmp/new.fossil| peer-name-3aeaa6385a3e39cf|New| peer-name-7844a4a7c15dad42|One| peer-repo-7844a4a7c15dad42|/tmp/one.fossil| login-group-code|03c19721921c03aa| login-group-name|Team1| And new.fossil: project-code|3aeaa6385a3e39cf1f654e4ab54f3ecd36ed1e6b|1376152719 peer-repo-7844a4a7c15dad42|/tmp/one.fossil| peer-name-7844a4a7c15dad42|One| login-group-code|03c19721921c03aa| login-group-name|Team1| peer-name-f2b6f81f58bff6b8|Two|1376191901 peer-repo-f2b6f81f58bff6b8|/tmp/two.fossil|1376191901 Thanks, User information is not cloned. If you want clone it from original server to cloned one you must use : fossil configuration pull user --overwrite original_repo_url HTH --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Random thoughts on Fossil v2
On Thu, 25 Jul 2013 08:34:02 -0700 Andreas Kupries andre...@activestate.com wrote: I'm on it now, writing a minimal png with 32bit ARGB color and a minimal graph lib. Link ? Not for now sorry. Do you know lodepng / picopng ? http://lodev.org/lodepng/ I didn't know about it, but I use zlib included in fossil for other purpouses instead of developing one myself, and only implement one mode, 32 bit argb, not full png to keep source code size an complexity as minimal as I can. --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Random thoughts on Fossil v2
On Mon, 22 Jul 2013 13:36:37 +0200 Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 22, 2013 at 1:30 PM, Eduardo Morras emorr...@yahoo.es wrote: Xcb uses an async mechanism, it creates a cookie, sends it and data to the external code, keep working. External code calls xcb, sends the cookie with the answer. Data and cookie can be exchanged through sql table. Then it starts looking like a message queue, and i personally have no intention of seeing fossil grow into such a creature. And fossil is single thread single process app and can't do any other thing while waiting. I applaud the single thread, I dislike threads too, don't understand why it must be single process. That's why I said I confused user with role. The role owns the files, not the user. Currently, a user without wiki role capabilities can't modify the wiki files. Yes he can - he simply needs to clone it. At that point any access rights fly out the window. Similar, a C developer role can modify /src dir but not /documentation or /sql, the DBA role can change /sql but not /src and similar. Role info is already exchanged in pull/push/sync, user info not. So in your scenary, a user can get the role capabilities and access them. So what happens when i (as a wiki editor) make a change to src/foo.c, commit it to my local copy (because locally i have admin access) and then try to push? i can't, and my repo then gets (permanently) out of sync. i don't think this model is possible in a DVCS. Yes it is. There's a big difference between Project and Repository. There's the fossil project, only one, but there are lots of repositories and fossil project forks that aren't the main 'Fossil Project'. I don't want to restrict what you do with your repository or your project fork, I want to restrict what you can do to main Project. The problem is that a user is admin of his own repository file and can set whatever s/he wants and access everything. A global dvcs role and user data can solve this, not allowing this user make changes in public branches or trunk directories of central repo (or other users repos) if s/he has no privileges to do so. Once i clone it, the central repository has NO say-so in what i can and cannot check out. It can only control what i check IN, or (more correctly), what i try to push to the central server. If it will not let me push the changes i have already committed to my local repo then i have a serious problem. No, I sync with fossil main repository each week, but I don't have permission to push my changes. That's because my user (anonymous) don't have the role to do so. If I want to push my changes I must convince someone who has the correct role to do so. I want to restrict that a developer user, with a defined role, can push changes only to certains files/directories of main repository and not others. For example, in Fossil, sqlite3.c, sqlite3.h, copyright file, makefile, etc... should be changed only by user drh, at least in trunk, because he is the project architect. It's true that 'it shouldn't happen if everyone follow the manual and touch the files he owns', but there are sometimes, specially with newbies, that the repository becomes unusable because they touch a file they shouldn't. --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Random thoughts on Fossil v2
On Tue, 23 Jul 2013 13:17:47 +0200 Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 23, 2013 at 1:04 PM, Eduardo Morras emorr...@yahoo.es wrote: Yes it is. There's a big difference between Project and Repository. There's the fossil project, only one, but there are lots of repositories and fossil project forks that aren't the main 'Fossil Project'. I don't want to restrict what you do with your repository or your project fork, I want to restrict what you can do to main Project. That's the problem: my clone of your project is a first-class copy of your project. There is essentially no distinction. If you copy goes up in flames me can drop in my copy, re-add the users, and we're done. So here's what happens with user restrictions: - i clone your repo - i edit some dir which you have restricted. - i check it in locally (offline) - Later i try to push to your repo and it fails. My repo is now in a state where i can _never_ push my copy to yours ever again because pushing to yours will fail as long as i have no access (on your side) for that file. I must insist here ;) There's a distinction, your repository is not the official Project repository, mine, the central one, yes. You can fork and create a new project and name it as you wish and change what you want. If you want to merge with the Only and Real True Project, your changes must be approved by the person that has the permission to do that, that's me. No, I sync with fossil main repository each week, but I don't have permission to push my changes. That's because my user (anonymous) don't have the role to do so. If I want to push my changes I must convince someone who has the correct role to do so. But for partial access ALL pushes from me to you will fail if i have edited a file to which i cannot push. There is no partial push in fossil - you can push everything or nothing. Fossil, as a piece of software, could not possibly decide which parts of my commits are safe to push, and Fossil _MUST_ fail if _any_ part of my push/sync fails because it has no heuristic which can say, oh, that was just that file under /noaccess/... which you edited 3 weeks ago and is still not writable for you (and if it could decide that, then failing is still the proper response). The only reasonable action Fossil can take there is to fail. How could it possibly know which parts are okay and which not? How can i possibly ever recover my repo to a sane state if you refuse to give me write access to changes i have already made locally (but not cannot commit, leaving my repo in an unclean/divergent state). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Random thoughts on Fossil v2
On Sun, 21 Jul 2013 21:15:56 +0200 Stephan Beal sgb...@googlemail.com wrote: a) when a user sync/merge to trunk in central server, it compile/test the code, after receive but before merge, and if compile/test fails reject sync/merge. b) project management features, global gant graphs, percentage of work done, c) source code parser, to find where a function, macro, etc... is declared d) fts of documentation If we don't want to write such hooks in C (which might not be practical) then a a scripting engine is implied. IMO the right choice, given fossil's history, would be TCL, but any option we choose brings with it long-term dependencies or maintenance (if we embed a small interpreter like jimtcl or lua). To me jimtcl would be the obvious candidate, but i was told at some point that it has too many incompatibilities with standard TCL to be of interest to the harder-code TCLers. No, not as hooks, but as plugins. I think that include a scripting engine is great, I'm a lua user, but force to use only one not. Allowing to call external have this advantages: a) Not tied to one scripting language b) In smp environments, the script will run on other processor (or even remotely) c) It can work asyncronous, fossil may not wait the script ends d) If script fails, fossil will not hang or crash or silently quit e) Fossil size keeps tiny f) Scripts can be persistent g) Update/Bug fix script engine without recompile fossil or wait for a new fossil release Of course, with security at first. About hooks, thinking more about it, perhaps something more like a trigger. For example, in our c projects, we have this on the central repositories: 1) a user syncs to central 2) after sync, we must run a script manually that 3) checkout last trunk version 4) compare trunk with trunk 5) if some change is detected, compile with clang static analyzer, it has an option to make an html report 6) add the report directory to reports branch 7) copy the new trunk to old trunk dir and rm everything else 8) close the checkout It will be great if fossil shoots the script each time trunk is modified, d) extend user capabilities Some superuser can own/lock some files in central repository or at least, in trunk. For example makefiles, binary files, project configuration, etc... i was thinking about that as well, but IMO the current system works remarkably well. It effectively offers up to 26 (or 52) roles, which is far more than projects of fossil's scale need. We could perhaps add a mechanism to allow clients to add letters to the permissions alphabet. Or toss out the mechanism and do something new. i think a full-fledged role management system would be way overkill, but if we're starting from scratch anyway... Perhaps I mixed the concept of user and role. I thought more about the concept of file owner. By default all users owns all files, but some roles, like superuser or project architect, own some files or dirs and only him/her/it can modify them. --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Random thoughts on Fossil v2
On Mon, 22 Jul 2013 12:20:44 +0200 Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 22, 2013 at 12:09 PM, Eduardo Morras emorr...@yahoo.es wrote: ...No, not as hooks, but as plugins. I think that include a scripting engine is great, I'm a lua user, but force to use only one not. Allowing to call external have this advantages: a) Not tied to one scripting language b) In smp environments, the script will run on other processor (or even remotely) c) It can work asyncronous, fossil may not wait the script ends For some checks Fossil _must_ wait on the script to end. How can it do a commit confirmation check if it doesn't wait on the results? Xcb uses an async mechanism, it creates a cookie, sends it and data to the external code, keep working. External code calls xcb, sends the cookie with the answer. Data and cookie can be exchanged through sql table. To be clear, i often use the words hook/plugin/trigger interchangeably. They are different. A hook is capability we add to a function, as a anonymous function pointer. This way we can hook the any function to program flow, changing it. A plugin is a module that adds capabilities to program. For example Sqlite3 has plugin mechanism to add external aggreagate calculations. A trigger is code that executes other code when some conditions met. So the difference is that a hook allows a plugin work when the trigger wants. Perhaps I mixed the concept of user and role. I thought more about the concept of file owner. By default all users owns all files, but some roles, like superuser or project architect, own some files or dirs and only him/her/it can modify them. i think that would be impossible to implement properly in a DVCS (it would be possible in a centralized SCM). When i clone your repo, i need access to ALL of the files i cloned. If i cannot check out or modify certain files just because you own them, the repo is useless to me. It means that if a developer dies (as they occasionally do) then all of his locks are there forever. This doesn't sound realistic to me. One of the things fossil promises which other SCMs do not is forever - it's data format is designed to outlive the software, which means that in 200 years someone could read the fossil data format, import an ancient sqlite3 fossil DB into his sqlite27 db, and get back to work. Except that now he can't make changes because the files in the repo belong to another user ;). That's why I said I confused user with role. The role owns the files, not the user. Currently, a user without wiki role capabilities can't modify the wiki files. Similar, a C developer role can modify /src dir but not /documentation or /sql, the DBA role can change /sql but not /src and similar. Role info is already exchanged in pull/push/sync, user info not. So in your scenary, a user can get the role capabilities and access them. The problem is that a user is admin of his own repository file and can set whatever s/he wants and access everything. A global dvcs role and user data can solve this, not allowing this user make changes in public branches or trunk directories of central repo (or other users repos) if s/he has no privileges to do so. --- --- Eduardo Morras emorr...@yahoo.es ___ 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] cloning / opening fails on WinXP SP3
On Wed, 19 Jun 2013 01:25:30 -0700 Edward Berner e...@bernerfam.com wrote: I'm surprised, but yeah, its looking that way. I just ran the test again using the same fossil binary on XP and Windows 7. The clone failed on XP but succeeded on (64 bit) Windows 7. It also succeeds on 32 bit Vista but fails on Windows 2000 (I had to use a different binary on Windows 2000). As a sanity check I served up a copy of Fossil's own repository in the same way as my test repository. All systems were able to successfully clone it. Some shoots in the dark... a) Can you try with antivirus disabled? b) Can you try fossil clone URL_REPO repo.fsl ? (Note that repo.fos fits in 8+3 filename) -- Edward Berner --- --- Eduardo Morras emorr...@yahoo.es ___ 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] cloning / opening fails on WinXP SP3
On Mon, 17 Jun 2013 15:20:34 +0200
Michai Ramakers m.ramak...@gmail.com wrote:
Hello,
this is the first time I try Fossil on a Win32 system, so I'm guessing
I do something wrong. Here is what I did, and what fails:
1) download fossil executable from fossil-scm.org; this is 1.25 [d2e07756d9]
2) in dir '\some_where\repo', clone
http://michai@otherhost_on_lan/my_fossil my_fossil.fossil
(otherhost_on_LAN is running fossil 1.25 [c7133bd79d], amd64 netbsd)
3) notice the cloned repo is too small; roughly 19 MB instead of
expected 311 MB as on the http host (this may be irrelevant - no
idea.)
4) in dir '\some_where\src', try to open the cloned repo anyway
5) notice only a _FOSSIL_ file is created, nothing else
6) 'fossil stat' in 'src' shows '[f34e9990ce] initial empty check-in
(user: michai, tags: trunk)' (which corresponds to the oldest timeline
entry of that repo)
I tried cloning another repo from the same host, which went fine.
Fossil as http server is running from inetd on 'other_host_on_LAN'.
The Win32 host is running Windows XP pro SP3.
Running 'fossil clone' locally on 'other_host_on_LAN' works fine for
the same repo (with cloned repo being around 466 MB, fwiw).
Running 'fossil clone' on another amd64 netbsd, cloning the same repo
on 'other_host_on_LAN' works too; the fossil version on that host
happened to be 1.24 [8d758d3715] .
Perhaps worth knowing, or not: while working on 'other_host_on_LAN', I
had trouble adding or checking in (cannot remember) files with strange
characters in them - somehow managed anyway, but later removed these
files again ('fossil addremove'). In between the initial checkin I saw
cloned on the Win32 host and the moment of adding these files, a few
other checking had happened (which perhaps means these are 2 unrelated
things - no idea).
So... that's all; any ideas are welcome. I don't currently have a
mingw32/cygwin/whatever native build environment on the Win32 host; if
it's relevant, I could install it and try new fossil-versions from
source.
Did you rebuild after clone? Try fossil rebuild my_fossil.fossil --analyze
Note that clone doesn't copy user information. I think, correct me if I'm
wrong, it doesn't copy information that can be rebuild from artifacts, like
indexes.
Michai
--- ---
Eduardo Morras emorr...@yahoo.es
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] 2 possible bugs?
Hi, revising fossil code with clan analyzer, 2 possible bugs where found, from
last trunk ( 4175c90f9522299c07ae4da5d19b93a50ce5f74c
http://www.fossil-scm.org/xfer/info/4175c90f95):
a) src/file.c line 197-201
197 if( zName!=zBuf ) free(zName);
if( symlink(zTargetFile, zName)!=0 ){
fossil_fatal_recursive(unable to create symlink \%s\, zName);
201 }
So zName may be used after free.
b) src/attach.c line 490
490 free(zDate);
@ trthUser:/thtd
492 hyperlink_to_user(pAttach-zUser, zDate, /td/tr);
Similar, zDate is used after the free.
HTH
--- ---
Eduardo Morras emorr...@yahoo.es
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Limiting committers directories
Hi, How can I limit/prevent the directories where a developer/commiter can make changes? For example, if I have this directory structure: /project /src /c /php /javascript /doc /en /sp /tools /bin /stats How can I limit/prevent the C developer to make changes in doc/en or src/php? Or modify the embedded documentation? Thanks --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Repo activity stats over time
On Mon, 6 May 2013 10:59:26 +0200 Stephan Beal sgb...@googlemail.com wrote: On Mon, May 6, 2013 at 8:59 AM, Eduardo Morras emorr...@yahoo.es wrote: You can use javascript library Raphael (MIT Licence, similar to BSD) to draw svg graphics. It's 221KB uncompressed, 31KB gzipped and is HTML4-safe. http://raphaeljs.com/ Other drawing js libraries needs a HTML5 capable browser, but IE=8 aren't. i looked at Raphael a couple years ago and it looked pretty nice - i can only assume it's gotten better since then. However, Fossil doesn't need/want any depedencies on specific 3rd-party code. A Raphael-based solution can be done client-side, but for that to work the user would need to include Raphael in his skin and get access to the reporting data via JavaScript. At the moment the reporting data is only available in raw HTML form. It would be a trivial matter to embed it in JSON form in script tags but the JSON bits are off by default, so this would not help most users. Once time allows, and we decide on what data to show via the statistics reports, i'll add an equivalent JSON API which will allow JSON-using users to fetch it and render with their preferred graphics API. The timeline view, interestingly, is drawn with DIVs - there is no canvas there (i only recently figured that out). Even the arrows are just a series of tiny DIVs. ... Thinking more about including complex graphs (more that can done with divs), If javascript, ajax or similar ways are closed, Is develop a graph.c that builds graphs on server side the way to do so? If output is done to image it will add fossil dependencies to libjpeg, or libpng or others image formats, if output to svg, gzip and svgc is needed. Images are not scalable, svg yes... Note that IE8 and below don't support svg natively, they must install Adobe SVG Viewer. It looks like i'm going to shake fossil's code this weekend. --- --- Eduardo Morras emorr...@yahoo.es ___ 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.25 Windows XP - open command 'fails'
On Fri, 05 Apr 2013 10:57:42 +0200 Jan janus...@gmx.net wrote: Am 05.04.2013 09:41, schrieb Jan Nijtmans: What's the (error-)message immediately before the Rolling back... line? That should give a clue about what's really going on here. It says fossil: unable to open file file.pdf for writing Rolling back ... This is the file name: Delagarde 2010 GrazeIn a model of herbage intake and milk production for grazing dairy cows. 2. Prediction of intake under rotational and continuously stocked grazing management.pdf Something wrong with that on XP? Seems to work on Win7 though. Max Path size is 260 chararacters under WindowsXP, the filename has 181, perhaps full path is bigger. Check http://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath Jan ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Whether or not this function examines the entire contents of the blob is officially unspecified.
On Tue, 19 Mar 2013 16:28:08 +0100 Jan Nijtmans jan.nijtm...@gmail.com wrote: This line can be found twice in the fossil source code, and it refers to the functions looks_like_utf8() and looks_like_utf16() (src/diff.c lines 233 and 336). In Fossil 1.25 and earlier, looks_like_utf8/16 bailed out as soon as either a NUL byte or a long line was encountered. Stopping at long lines is a bad idea, because a following NUL byte might not be detected. In commit [13fac7f74a]: https://www.fossil-scm.org/index.html/info/13fac7f74a this is fixed. Both NUL-bytes and long lines no longer abort the function. This has the adverse effect that even binary files containing NUL bytes are always scanned completely, even though we know already that the file is binary. So, I would like to suggest to change looks_like_utf8/16() such that NUL-bytes mean that scanning the remaing bytes/chars of the blob is aborted, but not for long lines. This has no effect on fossil: LOOK_NUL has the highest priority of all flags, it should always be checked first by all calling code. All other flags are meaningless whenever LOOK_NUL is iset. Any objections? It's a work around the real problem, that there are binary and nonbinary/text files that should be treated/used/modified in different way. A solution like mime or file extension check, can give enough information about the file, an image file shouldn't call looks_like_utf8/16() f.ex. Regards, Jan Nijtmans --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Good repository to test scalability of fossil
On Fri, 8 Mar 2013 09:09:56 -0500
Martin Gagnon eme...@gmail.com wrote:
Hi,
I found a git repository of the full openbsd src tree here:
http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/
I think this repository is good to test scalability of fossil, since it's
contain not only the kernel source of openbsd, but also all the userland of
the base system.
I know someone recently test with the NetBSD port tree, but port tree is a
bit less realistic since it contain a incredible huge number of small files
with an incredible number of commits.
I've clone the repo and start an fossil import of it.. I Start the import 2
days ago and now it is at the final step, rebuilding of meta-data is
finished and it's doing Vacuuming since a while..
Here some statistics:
- Gzipped git fast-export file:
2.58 GB
- Time for the import (before rebuilding meta-data):
22 hours
- rebuilding meta-data + Vacuuming:
18 hours
- Fossil memory usage during import:
Always increasing, up to: approx: 730MB during vacuuming.
Actually, right now during vacuuming, CPU usage of the fossil process is
about 3% and there's no progress printout during vacuuming, so I don't know
if it will finish soon...
I'll give more news when I'll try to use the repository under fossil
compared with git for the speed.
I'm doing the same experiment with it now. I clone the openbsd repository and
fast export to a file. It's 12 GB size and wc -l shows 430.083.609 lines.
I have modified fossil to know in what line is it working. I have no a diff but
its trivial,
edit import.c and add the lines marked with + in function git_fast_import:
static void git_fast_import(FILE *pIn){
ImportFile *pFile, *pNew;
int i, mx;
char *z;
char *zUuid;
char *zName;
char *zPerm;
char *zFrom;
char *zTo;
char zLine[1000];
+ sqlite3_int64 zLineNumber;
gg.xFinish = finish_noop;
+ zLineNumber = 0;
while( fgets(zLine, sizeof(zLine), pIn) ){
+zLineNumber++;
+if (zLineNumber%1000==0){
+ fossil_print( Processing Line Number: %d \r, zLineNumber);
+}
Perhaps another change can show the number of lines per minute. I will try some
tweaks and see which ones makes the import faster.
--
Martin G.
--- ---
Eduardo Morras emorr...@yahoo.es
___
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] Admin Password seems to change by it's self
On Sun, 27 Jan 2013 10:45:28 -0700 David Blanford d...@daveandval.org wrote: Hello, I am new to Fossil. I have a fossil repository set at chiselapp. Cloned it so I have a local repository as well. Everything was working perfectly. Now the password seems to have changed. This is the second time this has happened. The first time I went in and reset the admin password using chiselapp dashboard, cloned again, and carefully changed all the passwords to match. It worked for a 1.5 days durring which I did several updates and commits via the local repository. Now that password no longer works when I try to log into the remote repository via the web interface, and I am unable to do a commit that updates to chiselapp from the command line. In short the same symptoms I had the first time. Am I missing something? Is this a bug? Any help would be greatly appreciated. When you clone a repository a new admin password is created, it's showed in stdout. This is the output of a clone from fossil: camibar% fossil clone http://www.fossil-scm.org/fossil myclone.fossil Bytes Cards Artifacts Deltas Sent: 53 1 0 0 Received: 4000569 11044 1172 4361 Sent: 71 2 0 0 Received: 4496529 9283 1740 2862 Sent: 57 95 0 0 Received: 4000227 8779 1329 3067 Sent: 57 1 0 0 Received: 4000245 4733442 1927 Sent: 57 1 0 0 Received: 4026975 3664445 1389 Sent: 57 1 0 0 Received: 4505409 1610377430 Sent: 57 1 0 0 Received: 645979270 73 61 Total network traffic: 1732 bytes sent, 25677066 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 server-id: bb19027832ccec8ec34290adc124cabd90be8bb1 admin-user: gowen (password is d30ccf) As you see, there's a new admin user with a new password. This way you are the admin of your clone. If you open the repository and list the users you get: camibar% fossil user list anonymousAnon developerDev gowen nobody Nobody reader Reader As you see the user data is not populated from the original repository using clone (in timeline view you see users drh, jan.nijtmans, stephan and others). Perhaps what you want is a simply raw copy of the repository file, it will keep all users and other sensitive information and after that you can use sync, or pullpush. For now there's not a globlal admin user or global users that maintains in all clones. Perhaps in a svn like closed environment it has sense this kind of global users, the global admin will be the same for every clone and only him/her/its can admin and dominate all clones, like a sauron's ring ;) HTH Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users --- --- Eduardo Morras emorr...@yahoo.es ___ 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] howto `grep' through old revisions
On Mon, 28 Jan 2013 15:25:19 +0100 Gilles gilles.gana...@free.fr wrote: On Mon, 28 Jan 2013 11:22:11 +0100, Lluís Batlle i Rossell vi...@viric.name wrote: Is there a way to avoid writing all those files to disk, and just output data to STDOUT and read this with grep? I don't know how to do that. Thanks. I'll see if there's a way to create some kind of temporary disk in RAM. If you use FreeBSD, this is what i have in my central repository server: In /etc/fstab: md /mnt/fossiltmp mfs rw,-M-S32m 2 0 # 32 MB memory disk I use intensively this because in each sync i, or someone, make to my central repository server this script runs: #!/bin/sh cd /mnt/fossiltemp fossil open $1 makeheaders -f makeheaders.dat scan-build -o/mnt/fossiltemp/stats/ -vv make fossil addremove fossil commit -m $(date) fossil close rm -rf /mnt/fossiltmp/* This way i create the html pages from clang/llvm statical analyzer and commit them to the project when some one . It's fast, i can live without 32MB of ram on this server but not clean, because a new commit is done each sync. You can use a similar approach for your grep problem and if you are trying to find when you add something use fossil bisect --- --- Eduardo Morras emorr...@yahoo.es ___ 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 clone' from localhost is extremely slow
On Thu, 10 Jan 2013 13:57:54 +0100 Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 10, 2013 at 1:53 PM, Eduardo Morras emorr...@yahoo.es wrote: If he tries in shell 1 fossil open repository fossil server and in shell 2 fossil clone http://localhost:8080/ copy.fossil should workaround it, the repository is opened only once In theory, yes, but the web server forks a child process for each request and (as i learned via a recent thread in the sqlite list) the db must be opened by the child processes in order for locking to work properly. If BSD is not killing the child processes immediately after each request is finished then the db could be held open during the multiple requests sent by a clone operation. In theory/speculation. I thought that only in cgi mode it's forked for each request, I have to look that part of fossil code more deeply. I think in server mode fossil could/should/may keep running without exit after each request. It could make easier the xfer code for clone pull and push, so a cookie is not needed to continue the download/upload. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --- --- Eduardo Morras emorr...@yahoo.es ___ 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 clone' from localhost is extremely slow
On Thu, 10 Jan 2013 13:21:50 +0100
Stephan Beal sgb...@googlemail.com wrote:
On Thu, Jan 10, 2013 at 12:32 PM, Michai Ramakers m.ramak...@gmail.comwrote:
ah yes... forgot that :) It does not help. Note that taking 1 cpu core
offline ('cpuctl offline 1' here) makes it fly
This is just pure speculation, but ... perhaps there is a problem in BSD
multi-core cases, such that the various requests made by fossil for cloning
do not get closed/killed immediately, and each request is locking the db
for longer than it should because its process it not being killed in a
timely manner? It would be interesting to see if, when you see the
hang-ups, if the child process forked for handling a request is still alive
(on the other CPU) for a while after the subsequent request has already
started.
i.e... clone request 1 comes in and completes, but its process (or flock)
is not closed/released in a timely manner. Then comes clone request #2,
which is waiting on an flock which is still held by request 1. Ad nauseum
for requests #3 to #N. The output of lsof the_repo_file might be useful
here.
(Again, purely speculation...)
If he tries in shell 1
fossil open repository
fossil server
and in shell 2
fossil clone http://localhost:8080/ copy.fossil
should workaround it, the repository is opened only once
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
--- ---
Eduardo Morras emorr...@yahoo.es
___
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 info' feature request (a.k.a. wish)
On Thu, 10 Jan 2013 14:12:18 +0100 Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 10, 2013 at 1:57 PM, j. van den hoff veedeeh...@googlemail.comwrote: ...works like a charm and saves lots of typing (locally chronological rev. nums are much easier to memorize (and to type...) than sha1 hashes). so I still think this would be useful. Explained that way it does sound useful but i would personally be very wary of using any numbering/IDs which aren't guaranteed to be stable between CLI invocations, since a pull/update could invalidate/change the meaning of the ordering. (But that's just a sign of my own pedanticness.) You always can commit to (in my case) stable branch with a tag, f.ex. fossil commit -m Release version 5.2 --branch stable --tag 5.2 Perhaps i'm using it the wrong way, don't know, -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Right way to try something new and save/revert?
On Wed, 09 Jan 2013 12:10:35 +0100 Gilles gilles.gana...@free.fr wrote: Hello Am I correct in understanding that this is the right way to proceed to try some new code, and either save it (whether it works or not, just as a track-record) or discard it? To try some new code: 1. Commit current code 2. Try new code 3. a. if OK, commit new code : fossil commit -m New stuff b. if NOK and don't care to save it, just go back to previous code: fossil revert myfile.c c. if NOK but want to keep track of attempt, commit and go back to n-1 : fossil commit -m Failed attempt fossil finfo myfile.c : write down UUID (first hash) of n-1 revision fossil revert -r UUID myfile.c If in your step 2 you add/remove/move files you should fossil addremove before the commit. Remember to open the repository before any change to your code, if not, when you do fossil open rep.fossil, it will note it's different from fossilized source tree and undo all your changes. Thank you. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users --- --- Eduardo Morras emorr...@yahoo.es ___ 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 scalability
On Fri, 21 Dec 2012 15:02:50 +0100 Stefan Bellon sbel...@sbellon.de wrote: On Fri, 21 Dec, Joerg Sonnenberger wrote: On Fri, Dec 21, 2012 at 12:30:25PM +0100, Stefan Bellon wrote: In total, the Subversion repositories hold over 45000 revisions. The first 5000 revisions were converted in a quite acceptable time. But then things started to slow down. At the moment (at revision 8150) one Fossil commit takes around half a minute. There is one issue with commits on large checkouts unrelated to repo-cksum and mtime-changes. The SQLite database in the checkout is essentially rewritten after each commit, which can be very slow with many files. I have set mtime-changes on and repo-cksum off, like Lluís suggested, but only noticed a very minor speed improvement. But now - with those settings still in place - I decided to take a closer look at what happens at commit time. Especially I paid attention to the point when the journal file appears, the point when the New_Version hash is output and the point when the journal file disappears/fossil terminates. I made the following observation: In the vast majority of commits, it takes around 15 to 18 seconds from fossil commit till the journal file appears. Then it takes between 4 and 10 seconds till the New_Version message is output and another 11 to 16 seconds till the journal file disappears and fossil terminates. However, there are a very few commits that work differently. They take the same time till the journal file appears, but then only a very few seconds till New_Version is displayed and again a very short time till fossil terminates. So I would assume that the time till the journal file appears is used for checksum/mtime calculation and file system performance. But the phases during journal lifetime seem to be the database transaction time. Two observations: 1) It looks like fossil always takes its 15 to 20 seconds (for this specific project at this specific state on this specific machine!) till the commit actually begins. Perhaps this can be improved (as Subversion is faster regarding this respect in the same scenario), but perhaps not because checking for modifications has to work differently, I don't know. 2) The database transaction time can vary wildly. Most of the cases it takes 15 to 25 seconds, in some cases however under 5 seconds. Looking at the specific commit data I was unable to detect any suspicious difference between the slow and the quick commits: It happens for just file modifications and for additions the same. Perhaps you can use a ram based disk for the temporary directory, what does iostat tells you? Another point, plus another perhaps, to keep in mind is that database configuration is biased towards little size or low work repositories. A big or a busy or both repository may stress the db with current configuration. Again, iostat and similar tools is your/our friend. There are some pragmas that can be send to sqlite, bigger cache_size, journal_mode=memory, automatic_index=off, temp_store=2, bigger wal-autochekpoint (fossil default is 1, sqlite default is 1000), etc. Afaik, only foreign_keys=off is used. Greetings, Stefan ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
