Integrated version control with Fossil SCM


Published on

Published in: Education, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Sqlite is hosted on fossil, actually Hipp works in his own Company hwaci, mostly in TCL/TK development motto: immutability
  • CGI = common gateway interface
  • Das erste nicht-ambige Prefix reicht zur Angabe von AIDs, min. ist hierbei 4 zeichen
  • Server doesn't start up the local browser
  • SQLite very mature (FF. TB) and relatively safe for single file-based DB
  • All hat bestimmte maintenance befehle
  • When using the web UI tickets: 1. because bugs can be attached to artifacts later (and they're immutable) 2. we don't want to clutter the source tree 3. are synced with others, since they exist in the global configuration state
  • Leaf = youngest check-in of a branch
  • Integrated version control with Fossil SCM

    1. 1. Integrated version control with Fossil SCM Tech Talk 2009-12-01 Arne Bachmann
    2. 2. Overview <ul><li>Web address </li></ul><ul><ul><li> </li></ul></ul><ul><li>Author </li></ul><ul><ul><li>Dr. D.R. Hipp - Author of </li></ul></ul><ul><li>License </li></ul><ul><ul><li>GPL v2 </li></ul></ul><ul><li>Motto </li></ul><ul><ul><li>No information gets ever lost </li></ul></ul>
    3. 3. Fossil principles <ul><li>In Fossil, a revision is called check-in </li></ul><ul><li>Every file, branch and check-in is an immutable artifact with an artifact identifier (AID), which is a SHA-1 hash </li></ul><ul><ul><li>E.g. f3859e6842b68349fe52128767e64c4329e4a4 </li></ul></ul><ul><ul><li>But it suffices to use prefixes (e.g. f385 , usually 8 letters) </li></ul></ul><ul><ul><li>Additionally you can tag (name) branches for easier access </li></ul></ul>
    4. 4. Fossil principles <ul><li>Fossil is leightweight </li></ul><ul><ul><li>Compilation is a matter of seconds, including SQLite code </li></ul></ul><ul><ul><li>One executable 787kB including self-tests & documentation </li></ul></ul><ul><ul><li>No dependency whatsoever on external libs or tools: gzip, diff, rsync, Python, Perl, Tcl, Java, Apache, Dbs, patch, … </li></ul></ul><ul><li>Fossil is self-hosted </li></ul><ul><ul><li>The website runs on fossil as CGI </li></ul></ul>
    5. 5. Usability: Command line interface <ul><li>Comfortable command-line interface </li></ul><ul><ul><li>Prefixes suffices for commands & AIDs </li></ul></ul><ul><ul><ul><li>fossil commit -> fossil com </li></ul></ul></ul><ul><ul><ul><li>fossil rebuild -> fossil reb </li></ul></ul></ul><ul><ul><ul><li>Fossil reconstruct -> fossil rec </li></ul></ul></ul><ul><ul><ul><li>fossil co = checkout -> fossil che </li></ul></ul></ul><ul><ul><li>Symbolic names for check-ins </li></ul></ul><ul><ul><ul><li>Simple tags on a check-in, starting with sym- </li></ul></ul></ul><ul><ul><li>No tab-completion integrated, since there's no fossil shell </li></ul></ul>
    6. 6. Usability: Web interface <ul><li>Fossil runs as a web server, provides a comfortable interface </li></ul><ul><ul><li>fossil ui or </li></ul></ul><ul><ul><li>fossil server </li></ul></ul>
    7. 7. Usability: Desktop interface <ul><li>… not yet available </li></ul>
    8. 8. Features <ul><li>Distributed version control system </li></ul><ul><ul><li>Similar to Mercurial & Bazaar (Python), Git (C), BitKeeper </li></ul></ul><ul><li>Very fast (pure C code) </li></ul><ul><li>Data-efficient (stores and syncs (binary) deltas, zlib'ed) </li></ul><ul><li>Fossil is safe: </li></ul><ul><ul><li>SQLite manages all data + BLOBs, transactional </li></ul></ul><ul><ul><li>Extensive self-testing upon each action (zlib-(de)compress), checksumming for every artifact and every action </li></ul></ul>
    9. 9. Features <ul><li>Very simple and persistent data structures for deltas, tables and file formats </li></ul><ul><li>No need to dump data off a repository, because each repository is always exactly one file </li></ul><ul><ul><li>Migration very easy: close , <move> , open </li></ul></ul><ul><li>No need to import dumped data, because upgrading a repository to a younger fossil executable is that easy: </li></ul><ul><ul><li>fossil all rebuild </li></ul></ul>
    10. 10. Fossil: Main building blocks (SCM) <ul><li>Fossil is a VCS, but additionally each repository contains </li></ul><ul><ul><li>A ticket system (bugtracker) </li></ul></ul><ul><ul><ul><li>History independent of check-in history </li></ul></ul></ul><ul><ul><li>A simple Wiki with edit-inside-the-browser </li></ul></ul><ul><ul><ul><li>Each wiki page has its own history, independent of check-ins </li></ul></ul></ul><ul><ul><ul><li>Pages can theoretically be branched and merged </li></ul></ul></ul><ul><ul><ul><ul><li>But currently no UI or API for that </li></ul></ul></ul></ul><ul><ul><li>Embedded documentation linked with check-ins </li></ul></ul><ul><ul><ul><li>Reachable by <server>/ doc /<dir>/<page>.wiki </li></ul></ul></ul><ul><ul><ul><li>CSS can be changed via admin options from the UI </li></ul></ul></ul>
    11. 11. Tags <ul><li>… can be attached to any leaf </li></ul><ul><li>Can have a value (= property), but mostly need none </li></ul><ul><li>Can be symbolic (starting with sym- ) </li></ul><ul><li>Are passed on to descendants </li></ul><ul><ul><li>Unless cancelled ( fossil tag cancel <name> ) </li></ul></ul><ul><ul><li>Unless merging with another branch </li></ul></ul><ul><li>There are two default tags: </li></ul><ul><ul><li>branch=trunk represents the current branch </li></ul></ul><ul><ul><li>sym-trunk (= NULL) symbolic name of branch </li></ul></ul><ul><li>After branching </li></ul><ul><ul><li>sym-trunk : cancelled </li></ul></ul>
    12. 12. Branching <ul><li>Forking vs. Branching? </li></ul><ul><ul><li>Fork defined as an &quot;accidental&quot; split of the check-in tree </li></ul></ul><ul><ul><li>Branch defined as deliberate </li></ul></ul><ul><ul><ul><li>e.g. a test branch is often merged into the main development branch, point of branch = branch point </li></ul></ul></ul><ul><li>Merging </li></ul><ul><ul><li>No integrated conflict editor (but the usual in-file notation) </li></ul></ul>
    13. 13. Configuration <ul><li>Local configuration state </li></ul><ul><ul><li>Not shared when pushing, pulling, (auto) syncing </li></ul></ul><ul><ul><li>Contains settings regarding </li></ul></ul><ul><ul><ul><li>Used tools </li></ul></ul></ul><ul><ul><ul><ul><li>commit message editor </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Web browser </li></ul></ul></ul></ul><ul><ul><ul><ul><li>(Graphical) diff tool </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Encryption </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Proxy </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Sync options </li></ul></ul></ul></ul><ul><ul><ul><li>Behaviour (autosync …) </li></ul></ul></ul>
    14. 14. Configuration <ul><li>fossil help settings </li></ul><ul><li>Shows integrated help </li></ul>
    15. 15. Server mode <ul><li>Fossil allows to quickly sync with other developers' repositories </li></ul><ul><ul><li>fossil server or fossil ui (opens local web browser) </li></ul></ul><ul><ul><li>fossil push offers changes to remote fossil instance </li></ul></ul><ul><ul><li>fossil pull loads changes from a remote fossil instance </li></ul></ul><ul><ul><ul><li>But doesn't change current check-in state (use update) </li></ul></ul></ul><ul><ul><li>fossil sync pulls and pushes </li></ul></ul><ul><ul><ul><li>As above </li></ul></ul></ul><ul><li>Autosync mode offers operation similar to working with a central subversion repository -> fossil is very flexible </li></ul>
    16. 16. Server mode <ul><li>Comprehensive web interface allows easy administration </li></ul><ul><ul><li>Of users and user rights (+ inherited group rights) </li></ul></ul><ul><ul><li>Settings </li></ul></ul><ul><ul><li>Appearance </li></ul></ul><ul><ul><li>Logs </li></ul></ul><ul><ul><li>Statistics </li></ul></ul><ul><li>CGI integration </li></ul><ul><ul><li>Serving multiple repositories </li></ul></ul>
    17. 17. Additional advantages of Fossil <ul><li>User rights management </li></ul><ul><ul><li>Uses current login name under Windows/Linux </li></ul></ul><ul><ul><li>Separate rights for check-ins and web interface users </li></ul></ul><ul><li>Integrated check-in signing </li></ul><ul><ul><li>Via PGP/GPG keys or similar </li></ul></ul><ul><ul><li>Or use --nosign upon commit and branch </li></ul></ul><ul><li>Robust and reliable </li></ul><ul><ul><li>Several years of experience in multi-project, multi-GB source trees with thousands of files and check-ins </li></ul></ul>
    18. 18. Drawbacks <ul><li>Commercial support from a very small company (only 2 persons?) </li></ul><ul><li>No graphical Windows client available yet </li></ul><ul><ul><li>Especially no conflict editor and explorer integration </li></ul></ul>
    19. 19. Questions?