On Thu, Apr 26, 2012 at 01:11:32PM +0300, Zeev Pekar wrote: > On Wed, 2012-04-25 at 14:18 +0000, Tzafrir Cohen wrote: > > On Wed, Apr 25, 2012 at 01:35:09PM +0300, Zeev Pekar wrote: > > > Shalom, > > > > > > just in a case that somebody haven't heard about it yet... > > > > > > There is a cool distributed software configuration management called > > > Fossil ( http://fossil-scm.org/ ): " In addition to doing distributed > > > version control like Git and Mercurial, Fossil also supports distributed > > > bug tracking, distributed wiki, and a distributed blog mechanism all in > > > a single integrated package" + more interesting stuff. Its like (apache > > > +git+github) in one app. Ideal both for one_man_projects and for > > > collaboration (especially in combination with dynamic dns). Switched to > > > it from git. Very satisfied. > > > > In what way id it better than Git and Mercurial? Apart from a built-in > > trac/redmine, that is. > Apart from built-in trac/redmine?! For me it was the major reason to switch. > Install/configure/integrate/maintain 3 apps (apache/trac/git) is a pain. > And after all you don't get the consistency of one monolith tool. > Besides that I find fossil(escpecially conflict resolution) more intuitive > than git. > See also: > http://fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki > > > It does not seem to be highly popular (besides the mother project, > > sqlite). > > + Tcl/Tk Project and also (maybe) NetBSD.
For NetBSD, I guess it's the license issue. If so, it's a bit sad, unless they fork it: see what I have to say about the license later on. > > > > > > And then again, there are a number of distributed bug tracking > > systems: > > http://dist-bugs.branchable.com/software/ > > yes, but they are not integrated in one tool... Do you actually have a single wiki and VCS per project? See http://core.tcl.tk/tcl/reportlist http://core.tcl.tk/tcl/wiki http://core.tcl.tk/ I've searched that site and the TCL site on a place where they explain how to clone the fossil repo. Couldn't find it. In fact, they don't eat their own dog food: http://www.fossil-scm.org/fossil/wiki?name=Fossil > > Furthermore I have no problems with not going mainstream (as long you > follow the principle from Pirkei Avot: "רַבִּי אוֹמֵר, אַל תִּסְתַּכֵּל > בַּקַּנְקַן, אֶלָּא בַמֶּה שֶׁיֵּשׁ בּוֹ."). > > The reason why git is so popular (besides the fact that it is indeed > better than svn and cvs) When Git was created, Bazzar was already better than CVS and SVN. > is because it was initiated by Linus Torvalds > and is used in Linux Kernel project, however 99.9% of projects using git > are neither of the size nor do they have the requirenmets of it. Git (and Mercurial) were created initially as a version control system that can replace BitKeeper for the Linux kernel, which is a relatively large code base. Bazzar, Darcs and such simply did not perform well enough to work with a project of the size of Linux kernel. Git has been gaining popularity everywhere. Recently even the Apache projects (who have been long time Apache Subversion users) finally decided it's time to switch to a distributed VC system, and chose Git. A repository is a single sqlite database. Here's what happened when I tried importing my kernel Git tree into it: $ (cd ~1 && git fast-export --all) | fossil import --git kernel.fossil warning: Tag points to object of unexpected type tree, skipping. warning: Tag points to object of unexpected type tree, skipping. fossil: SQLITE_FULL: statement aborts at 27: [INSERT INTO blob(uuid, size, content) VALUES(:uuid, :size, :content)] fossil: SQL error: database or disk is full Let's look at http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki or rather the specific revision: http://www.fossil-scm.org/index.html/artifact/8caffe08ca790491bac1a88e10e7fbcb386174be 1. file versioning vs. also other things Do you actually use distributed bug tracking? Anybody here used distributed bug tracking? Distributed blogs (ikiwiki and such)? 2. Sharding versus Replicating This is completely misunderstanding. The defaults of Git are that work is done in private branches. However you can always make your work much more in sync. I actually use Git to mirror a central Subversion server and then add some of my own feature branches. Do I really need to expose and replicate those to the central server before they are ready for public consumption? The whole point of a distributed system is to allow me to keep my own version. The authors here seem to confuse "encourge" and "allow". Git is designed to allow a diverse set of workflows. Indeed quite a few projects work with a central repo where a core team has a commit access. Note that Mercurial also defaults to encourging public development. 3. Branches More of the above. 4. Complexity Just like Git (and unlike Bazzar and Mercurial), Fossil invents its own vocabulary in the command line: $ fossil help Usage: fossil help COMMAND Common COMMANDs: (use "fossil help --all" for a complete list) add clean gdiff mv rm timeline addremove clone help open settings ui all commit import pull sqlite3 undo annotate diff info push stash update bisect export init rebuild status version branch extras ls remote-url sync changes finfo merge revert tag This is fossil version 1.22 [ab461f39af] 2012-03-29 08:48:38 UTC $ fossil help --all add co info remote-url tarball addremove commit init rename ticket all configuration leaves revert timeline annotate deconstruct ls rm ui artifact delete md5sum scrub undo bisect descendants merge search unset branch diff mv server update cgi export new settings user changes extras open sha1sum version checkout finfo pull sqlite3 whatis ci gdiff push stash wiki clean help rebuild status zip clone http reconstruct sync close import redo tag (No bash completion, BTW) Let's get started: $ fossil clone http://www.fossil-scm.org/ fossil.fossil Bytes Cards Artifacts Deltas Sent: 53 1 0 0 Received: 4000616 10903 1139 4323 Sent: 71 2 0 0 Received: 4543000 9424 1790 2883 Sent: 57 95 0 0 Received: 4012455 8519 1346 2920 Sent: 57 1 0 0 Received: 3873229 3050 347 1178 Total network traffic: 964 bytes sent, 16429948 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 server-id: 3b19ec8e8276ce41c35b02a98be73c2155658f60 $ ls -sh fossil.fossil 24M fossil.fossil $ mkdir fossil $ cd fossil/ fossil$ fossil open ../fossil.fossil BUILD.txt COPYRIGHT-BSD2.txt Makefile.classic ... Note the need to cd into the directory, unlike what I'm used to from CVS and just about any other VC system. The browsing capabilities seem fairly limited. I found no way to get a log for a directory ('svn log [-rNNNN] DIRNAME' or 'git log [REVISION:]DIRNAME'). OK. I checked out the fossil code. Now let's test-commit: fossil$ fossil commit Autosync: http://www.fossil-scm.org/ Bytes Cards Artifacts Deltas Sent: 177 2 0 0 Received: 538 12 0 0 Total network traffic: 317 bytes sent, 471 bytes received # Enter comments on this check-in. Lines beginning with # are ignored. # The check-in comment follows wiki formatting rules. # # user: tzafrir # tags: trunk # # EDITED src/gzip.c # # Since no default text editor is set using EDITOR or VISUAL # environment variables or the "fossil set editor" command, # and because no check-in comment was specified using the "-m" # or "-M" command-line options, you will need to enter the # check-in comment below. Type "." on a line by itself when # you are done: Tzafrir's test commit . New_Version: 9481c3aee7b568d7561bf739cd1511e608a3a4d7 Autosync: http://www.fossil-scm.org/ Bytes Cards Artifacts Deltas Sent: 1309 16 0 2 Error: not authorized to write Received: 571 1 0 0 Total network traffic: 867 bytes sent, 503 bytes received fossil: Autosync failed Now what did we have here: 1. no editor is used by default. Back to the the good old Berkeley mail. 2. I checked out code and made a small change. It tried to commit to the main repo. Yuck! Before I can stand on my own feet I have to know what branches are. I think Fossil is too simple. At least right now. We'll have to see how complex it is when it matures. Here is the command set I get from git: $ git add dch instaweb request-pull am describe log reset annotate diff merge revert apply difftool mergetool rm archive fetch mv shortlog bisect filter-branch name-rev show blame format-patch notes show-branch branch fsck pbuild stage buildpackage gc pbuilder stash bundle get-tar-commit-id pbuild-sid status checkout grep pull submodule cherry help push svn cherry-pick imap-send rebase tag clean import-dsc relink whatchanged clone import-dscs remote commit import-orig repack config init replace Some of those commands (buildpackage, pbuild*, import*, dch, svn, and maybe some others) are part of other packages. 5. Web Interface Well, Mercurial comes with a built-in web interface. Go and use it if this is what gives the VCS the edge. 6. Implementation Strategy Git has been designed to be extenable. As you can see in the above, it has been extended to do many things. 'git svn' is written in perl using the perl bindings of Subversion. ' . git-buildpackage is written in python and helps in building Debian packages. All I needed to do to "extend" git is to drop a script named "git-foo" in the PATH and then I got the command 'git foo'. $ dpkg -S git-buildpackage | grep -v /doc/ git-buildpackage: /usr/share/python-support/git-buildpackage.public git-buildpackage: /usr/share/doc-base/git-buildpackage git-buildpackage: /usr/share/man/man1/git-buildpackage.1.gz git-buildpackage: /etc/git-buildpackage git-buildpackage: /etc/bash_completion.d/git-buildpackage git-buildpackage: /etc/git-buildpackage/gbp.conf git-buildpackage: /usr/bin/git-buildpackage A single binary that does everything, including listening on the network interface sounds like CVS (the original one. Good thing I don't have to implement all of this as part of the original C code. Mercurial allow extensions through python modules you can drop. You're basically limited to python, but I figure that its python programers don't consider this a limitation ;-). 7. Repository Storage Storing everything in a single sqlite3 file? Oh well. When fossil is able to handle a database the size of the Linux kernel, we'll revise that design decision. There are several backup systems built on top of the Git storage. While it has its limitations (a single file > 4GB), it has proved itself over time. 8. Audit Trail You cannot rebase with Fossil. Even Mercurial figured out lately that rebasing is a handy tool (when used properly). As for an audit trail: if one wants to cheat, one can manually copy and not record that in the VCS. You trust your programmers to record the information in the VCS just like you should trust them not to rebase a public branch. I suspect that this is also part of the vision of "global synced database". 9. License Git, Mercusrial and Bazzar are GPL. Git and Mercurial don't require copyright assignment or something similar. Bazzar and Fossil do. So if you are a big corporation and have fixes to Fossil, you will either keep a private fork, or go through the legal department and have them sign http://www.fossil-scm.org/index.html/doc/trunk/www/copyright-release.html (Note the part about the patents. What about patents you can license but not sublicense to others?). Contributing to the kernel requires signing something that is basically only their article (4) - that you are actually the author/copyright holder/<legalese equivalent> of the code. I'm not sure of Git uses something similar. In short, if you think those are shortcomings, also give Mercurial a shot. -- Tzafrir Cohen | [email protected] | VIM is http://tzafrir.org.il | | a Mutt's [email protected] | | best [email protected] | | friend _______________________________________________ Discussions mailing list [email protected] http://hamakor.org.il/cgi-bin/mailman/listinfo/discussions
