Re: [fossil-users] A fossil library
Sorry: s/collection, UDFs/collection of UDFs/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A fossil library
But those intricate algorithms for deduplication, hash chaining, and merging, those would come in handy across the board. A bit about drift: it's a natural outcome of parallel codebases, even with something like a common standard. Without that, it's guaranteed, unless one of the forks doesn't get used. Just a thought (probably stupid, since I haven't started to study fossil and libfossil codebases yet): Is it possible and feasible (i.e. will it have serious negative impact on performance and resources usage) if fossil internal representations and algorithms gradually be ported to collection, UDFs, VTables and sqlite memdb tables where needed? If the above is possible, both fossil(1) and libfossil core layers could be written in SQL using the same sqlite extensions (eventually sharing big portions of the code). Kind Regards, Alek ___ 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] Google code shutting down
On 13.03.2015 21:55, Richard Hipp wrote: On 3/13/15, Warren Young w...@etr-usa.com wrote: Few organizations have the problem that the full power of Git solves. And yet many organizations voluntarily take on the problems that come with using Git. Weird. Аnyway, Github won that game. In fact it is a good thing - consolidation of majority of the open source code in one collaborative place, 10x more compelling to the new generation developers than e.g. late 90's sourceforge is a phenomenon which greatly accelerates moving the world forward ... I hope the next big thing will be another Github for versioning, forking and merging (i.e. collaboration) on (meta) data, along with the text artifacts. And it seems natural this thing to be born here - in sqlite/fossil community - who other has in depth, first hand expertise in both fields - structural data handling and versioning? The semi-structural software/deployment artifacts (traditional service configurations, devops artifacts like Ansible playbooks, protocols/interfaces definitions, package recipes - RPM, NPM specs, etc, etc) all have at least the same impact as the code itself, because they *enable* the deployment and reuse of already perfectly written code at the site (managed by not-developer users/admins). But currently we rely on expressing this kind of information as text (e.g. YAML in the best case), mostly because we do not have real versioning/forking/merging mechanism, common place and suitable - well known schemes for tree/graph sqlite databases as a replacement of the whole insanity. Kind regards, Alek ___ 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] commit crashes after http redirection
Hi Ashwin, On 12.12.2014 02:58, Ashwin Hirschi wrote: Are you trying to build on Unix/Mac or on Windows? Did you follow the instructions at https://www.fossil-scm.org/fossil/doc/tip/www/build.wiki ? I'm unable to build or debug Fossil because I've just switched to a new (Windows) machine. We're still in the process of putting things in place. So, at the moment, only the tools related to my regular day-to-day work are up running. In other words, for now I'm stuck at browsing the Fossil source code and hoping maybe someone on the list is able to reproduce the problem. Few hours ago, Andy committed a patch for you to test, but you say above that you lack C dev environment at this machine. If this is still a obstacle for you, we may try to build a Virtual Box VM with Linux and mingw ready for producing windows binaries, and place the image somewhere for download. Actually, Jan Nijtmans probably have something already prepared for such cases. Kind regards, Alek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem with compilation under MINGW
On 11.01.2014 20:44, Joseph R. Justice wrote: On Sat, Jan 11, 2014 at 1:24 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/4 James Turner ja...@calminferno.net: I *still* haven't sent out that message / warning yet, but I'm getting closer. Have info now for: CentOS (and Scientific Linux), Cygwin, Debian (and Ubuntu), Fedora, FreeBSD, Gentoo (and Sabayon), NetBSD, OpenBSD (can be skipped however), openSUSE, Slackware. I haven't looked up the Solaris variants yet, nor the other Linux and BSD distros (Linux: Arch, Mageia, Manjaro, Puppy; BSD: Dragonfly, Ghost, PC-BSD). Once you have collected the leading packagers contacts already, what about new, low-traffic list *packag...@lists.sqlite.org* intended for: * coordinating packaging of SQLite and Fossil * help potential new packagers working for non yet covered distributions My rationale is that the packagers often are busy with supporting few dozen packages and for some could turn out difficult to follow the whole users@l.f.o. IMHO in general, some form of packagers forum should be beneficial for any wide adopted project. Kind Regards, Alek P.S. I am trying to follow the Fedora development. As Josef pointed in a previous mail, Fedora is the main upstream of the whole family (RHEL, CentOS, etc) so most packaging decisions happen there. The Fedora Packaging Guidelines explicitly _prohibit_ bundling practices. Every single bundling exception should be proved inevitable/temporary and specifically granted by FPC (Fedora Packaging Committee). There are zero exceptions for SQLite bundling at the moment, and it would be hard to impossible one to be granted for such important system library (yum: The Fedora family (CentOS, RHEL, etc) package manager is SQLite based). ___ 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] Upgrade Fossil on Ubuntu 12.04 LTS
On 29.09.2012 15:48, Barak A. Pearlmutter wrote: Please send a proper URL for bug reports against the Debian/Ubuntu packages. Sure. You can look at http://bugs.debian.org/fossil http://packages.qa.debian.org/f/fossil.html Although bugs can be submitted by manually composing email, the reportbug(1) program is probably best, as it composes appropriate email including exhaustive version information. Thank you! At the attention of the Debian/Ubuntu users - please bookmarks these URLs and remember to use the your reportbug tool. These should serve as first level of support for you. Throwing OS specific (package version in the OP case) issues directly to the project developers often leads to suboptimal workarounds, which being recorded as-is by the archives, result in unnecessary (sometimes quiet) frustration for the future users. I'm the Debian maintainer, not responsible for Ubuntu, but I believe Ubuntu is taking the Debian package without modification. So, from the Debian package page it is obvious that you are doing your job as maintainer just perfectly - 1.23 has been packaged only a couple of days after the upstream release (month before this thread). The same for 1.22 and before + zero pending bugs in the tracker. Barak, is it possible and safe for an Ubuntu user to pull with apt-get the newest Debian package version for testing? Something equivalent of: yum --enablerepo=rawhide update fossil in Fedora. Thank you, Alek ___ 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] Upgrade Fossil on Ubuntu 12.04 LTS
[Forwarding the thread to the Debian/Ubuntu Fossil maintainer] Hi Barak, Please send a proper URL for bug reports against the Debian/Ubuntu packages. As you can see from this beautiful thread, our list seriously lacks the maintainers voice ;-) Kind Regards, Alek On 26.09.2012 16:14, Scott Meyer wrote: Worked. Thanks. On Wed, Sep 26, 2012 at 9:00 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Sep 26, 2012 at 8:32 AM, Scott Meyer dutch...@gmail.com wrote: Hello all, New to Fossil and what I see so far is perfect for our needs. I installed the Fossil package from Ubuntu 12.04 repositories using the apt-get install command. I would like to upgrade to the last version and from what I have found in the documentation it seems all I need to do is download the Linux zip file and replace the existing fossil exe with the new one. The current fossil executable is located in /usr/bin. When I unzipped the Linux zip file I put the new fossil file in the /usr/bin directory and when I try to use fossil I get an internal server error. While in the /usr/bin directory I tried fossil all rebuild and I get No such file or directory. When I type fossil in the directory I unzipped the new file I get the fossil command help, so I assume that it works. How do I get to the new version of fossil? Unfortunately, Linux seems to be devolved such that various distributions are no longer binary compatible. You have to have a executable compiled for your particular build of your distribution. Or, at least, I haven't figured out how to create an executable that works across multiple distributions On the other hand, it is easy to compile from sources on Linux. Just grab the source tarball and untar it. Then do: ./configure --with-openssl=none; make The command above will generate the fossil executable in your working directory. To install the new executable: sudo mv fossil /usr/bin The environment is Ubuntu 12.04 LTS. Thanks ___ 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] 2 questions
On 04.11.2011 11:45, Stephan Beal wrote: @Everyone else: please correct that if it's wrong. No need of correction, I use fossil this way too: cat /etc/systemd/system/fossil.service [Unit] Description=Fossil Repositories After=network.target [Service] Type=simple User=fossil Group=src ExecStart=/usr/bin/fossil server --port 39127 /srv/source/fossil [Install] WantedBy=multi-user.target ___ 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 and Git joint projects?
Hi Nolan, Stephan, I think that this is doable for a restricted subclass of usage scenarios (these conforming workflow style cited by Stephan above + bunch of other restrictions). We can benefit the fantastic opportunity of sqlite as fossil artifacts container - I think that it is possible to be implemented git protocol enabled python server with dulwich [1] on top of the fossil db, once we are able to manage fossil/git commit hashes dictionary in additional db table. Hg-git [2] also uses similar approach (but client side, It seems to me that server side is the easier one). As Fossil API, for the proof of the concept, the server can use the JSON API, Stephan ? Kind Regards, Alek [1] http://git.samba.org/?p=jelmer/dulwich.git [2] http://hg-git.github.com/ P.S. github != git, maybe tickets and wikis can be synchronized too (to some level) using the gihub API. On 04.11.2011 19:54, Nolan Darilek wrote: Thanks, but that's not really what I asked. I totally get Fossil's development model, have used it for over a year and think that it'd be a great fit for this particular community. I also read this message when it was originally posted. But I may be working with people who would rather submit a quick change via Github rather than download and install a new piece of software. Yes, I get that it's easy, I'm just thinking that it might be a barrier here. So let me make the question more explicit: 1. Can I export my project to a Git repository, push that to Github, make a few commits, export the changes to Git and push the repository again? If so, will it look identical to the repository after the first step with a few extra commits such that someone who pulls doesn't get told that the repository after the changes is different? 2. If my canonical Fossil repository advances and someone makes changes on Github, can I do an incremental import of the Git repository and only get their changes without creating an entirely new Fossil repository? 3. Has anyone else done this, and how does it work? I'd really rather use Fossil, but am worried about losing contributors who don't want to learn a new and simpler system. Since we're developing applications to meet immediate needs (software for the various occupations), the response I may get from people might be to use the tools that everyone knows to maximize the community's ability/willingness to chip in. If that response comes, hopefully I can say that Fossil interacts with Git in the manner I've described here and can meet the need. Thanks. On 11/04/2011 12:06 PM, Stephan Beal wrote: On Fri, Nov 4, 2011 at 5:43 PM, Nolan Darilek no...@thewordnerd.info mailto:no...@thewordnerd.info wrote: some pushback from Git users. Is it possible to use Fossil in a workflow with people who would rather use Git/Github? Richard wrote a nice summary of that on Oct 16th which i'll paste in here: --- Fossil does not currently support a hierarchical development model very well. It wants everybody to be a peer. It wants all developers to see everything all the time. Fossil strives to avoid a peeking order in which some developers are hidden from view behind lieutenants. This is a more egalitarian model, but also one that does not scale as well. To better support a hierarchy, Fossil would need the ability to sync individual branches in addition to its current behavior of always syncing everything on every sync request. (Recall that I asked for volunteers to implement such a thing a while back.) But adding that feature quickly gets complicated when you then try to figure out how to deal with auto-sync. You could, I suppose, put your local Fossil into a mode where it only syncs the branch you are currently working on or switching to. But what about Wiki and Tickets and Events? Do they get synced or not? Once you leave the comfort of Fossils original model of everybody sees all the code all the time then various operational questions of this kind start to come up. --- -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil and Git joint projects?
On 04.11.2011 21:01, Stephan Beal wrote: The biggest catch there is binary data, since JSON has no native way of handing it. However, my current thinking on binary data is this... from JSON we serve URL paths which, which called by an HTTP client, will return the raw content (binary or not) for the given artifact. We could handle POSTed data the same way, _theoretically_. There is a bit of proof-of-concept for that in the current timeline output: This approach (binaries via URL pointers on get/direct POST payloads on send) seems OK to me ... ___ 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 and Git joint projects?
On 04.11.2011 22:32, Andreas Kupries wrote: Does hg have something git's rebase and other history rewriting operations ? Yes - hg supports all of them and more (via various bundled [1] and endless count of community extensions), but as you know, history rewriting kills any repo/repo synchronization in any DVCS. Thus, thinking of the partial Fossil/Git bridge, let's focus on ideal case - no rebases, full DAG synchronization. If not, how do hg and the synchronizer (dulwich?) cope when the git repository they talk to undergoes such a rewrite ? Dulwich is not a merge-application - dulwich is just a well designed Git API (protocol and container format). In the case of Mercurial/Git bridge, the actual synchronizer is the hg-git itself (mercurial extension), which was started as common effort with github.com, but these days is actually maintained by hg-subversion team (with Augie Fackler [2] as lead) [1] http://mercurial.selenic.com/wiki/RebaseExtension [2] https://bitbucket.org/durin42/hg-git/changesets ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil is Awesome
On 27.10.2011 02:15, Caleb Gray wrote: @ Stephan Beal: I see the appeal in creating a separate HTML application. I will take this approach, and will see how everyone feels about having installable skins in Fossil: shipping it with only the Default skin. +1: Absolutely - optional AJAX applications as installable (in fossil DB) skins with JSON datasources, I am sure that you also follow the progress of ace.ajax.org and the other JS projects, which are good candidates for employment ;-). I think that the only missing part is feature for stored (parametrized) SQL queries, which can be called with lower privileges via JSON interface. You are exactly on track with what I was envisioning for the JS enhancements with: http://mbostock.github.com/d3/talk/20111018/#8 +1: d3 is the best for the SVG part in my eyes too, it seems even more powerful than his famous predecessor - protovis.org (and can be seen also as smart XSLT like engine - thus, can have more applications than just SVG drawing for fossil UX applications - i.e. live JSON-DOM templates for non-SVG enhanced pages also) Kind Regards, Alek ___ 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] Veracity
BTW, I just cloned Veracity source using veracity (vv) and realized that the repo consists of 13 sqlite DBs (WAL mode) + 1 external BLOB file (+ counting number simple sqlite3 files with containing table) On 19.10.2011 15:39, Lluís Batlle i Rossell wrote: On Wed, Oct 19, 2011 at 08:18:01AM -0400, Richard Hipp wrote: -- Forwarded message -- From: Yujianbinyujian...@huawei.com (2) support lock command, http://veracity-scm.org has this command. As Yujianbin mentions veracity... I saw some videos about veracity. From the web page, the author seems quite inspired by fossil, but on the presentation about veracity, he did not mention fossil at all. http://www.ericsink.com/entries/oscon_2011_video.html I saw that as a not fair presentation, on that regard. In any case, I wanted to try veracity, and for example it still lacks 'annotate', which for me is a basic command to have. Not that I like much its 'vv log' result either. The author also clearly said that veracity 'is not community software', so he is not going to accept regular contributions as his company develops the product, but he may accept patches. Whether to support locks... I think it can help some users, but I don't have use cases in my day to day. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
