On Fri, Sep 17, 2010 at 10:01 AM, <saulgo...@flashingtwelve.brickfilms.com>wrote:
> In the following message, Schlomi Fish requested that a representative > of Fossil assist in maintaining a Fossil entry for his Better SCM > website. > > http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg02478.html > > While I am relatively inexperienced with Fossil and probably not > qualified for fulfilling those duties, I think it'd be beneficial for > Fossil to be represented. If nobody else wishes to undertake this > task, I'd certainly be willing to do so; barring any objections. I > will defer to anybody who'd rather do it themselves, or otherwise > objects to me coordinating this activity.. > > I have attempted to address the request for information on Fossil's > capability; and edited a copy of the XML file. The diff for creating > my edited XML is available at > http://www.flashingtwelve.brickfilms.com/Temp/fossil.diff > > I have answered the questions to the best of my knowledge, but admit > that my knowledge of Fossil yet complete. I have included a plain text > version of my responses at the end of this post. > Thank you for taking on this task - my plate is full at the moment. Please see my edits below > > Criticism of the responses are welcome, whether they be wrong or just > poorly worded. > > ============================ > > Repository Operations > > --------------------- > > > Atomic Commits > > > > Support for atomic commits means that if an > > operation on the repository is interrupted > > in the middle, the repository will not be > > left in an inconsistent state. Are the > > check-in operations atomic, or can > > interrupting an operation leave the > > repository in an intermediate state? > > Commits are not atomic. > Commits are *very* atomic in Fossil - far more so than they are in git, hg, or any other VCS that I am aware of (other than perhaps monotone). Fossil commits leave the repository unmolested even if you lose power or take a system crash in the middle of a commit. Further information: http://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki > > > Files and Directories Moves or Renames > > > > Does the system support moving a file or directory to > > a different location while still retaining the history > > of the file? <b>Note:</b> also see the next section > > about intelligent merging of renamed paths. > > Moves and renames are supported. History is retained. > > > Intelligent Merging after Moves or Renames > > > > If the system keeps tracks of renames, does it support > > intelligent merging of the files in the history after > > the rename? (For example, changing a file in a renamed > > directory, and trying to merge it). > > No, renames are not intelligent. > Currently true. This could be fixed in a future release.... > > > File and Directory Copies > > > > Does the version control system support copying > > files or directories to a different location at the > > repository level, while retaining the history? > > Copying is not directly supported. Duplicating > the file and adding it to the tracking would not copy > the original file's history. > > > Remote Repository Replication > > > > Does the system support cloning a remote repository to get > > a functionally equivalent copy in the local system? That > > should be done without any special access to the remote > > server except for normal repository access. > > Yes. Entire repository can be downloaded without special > permission (the copy will not track upstream changes). > More traditional cloning requires authorization (this > is typically provided to 'anonymous'). > > > Propagating Changes to Parent Repositories > > > > Can the system propagate changes from one repository to > > another? > > Yes. > > > Repository Permissions > > > > Is it possible to define permissions on access to different > > parts of a remote repository? Or is access open for all? > > Permissions are set for the whole repository. > > > Changesets' Support > > > > Does the repository support changesets? Changesets are a way > > to group a number of modifications that are relevant to each > > other in one atomic package, that can be cancelled or > > propagated as needed. > > Not directly. Changeset information is available in > "manifest" files but no commands are provided to > automate changeset operations. > > > Tracking Line-wise File History > > > > Does the version control system have an option to track the > > history of the file line-by-line? I.e., can it show for each > > line at which revision it was most recently changed, and by > > whom? > > No > Yes - there is the "annotate" buttons on the web interface and the "fossil annotate" command. I use this daily in SQLite development. > > > Features > > -------- > > > Ability to Work only on One Directory of the Repository > > > > Can the version control system checkout only one directory of > > the repository? Or restrict the check-ins to only one > > directory? > > No. Checkouts are of the entire repository, however, > commits can be limited to any subset of files (e.g., just > the contents of a subdirectory). > > > Tracking Uncommited Changes > > > > Does the software have an ability to track the changes in the > > working copy that were not yet committed to the repository? > > Yes. Using 'fossil diff'. > Also "fossil status" and "fossil changes" and "fossil gdiff" > > > Per-File Commit Messages > > > > Does the system have a way to assign a per-file commit message > > to the changeset, as well as a per-changeset message? > > No. Commit messages are per check in. > > > Technical Status > > ---------------- > > > Documentation > > > > How well is the system documented? How easy is it to > > get started using it? > > Fossil is well documented. Manpage-type help is available > for all commands using 'fossil help'. Fossil also includes > a built-in web interface permitting easy visual exploration > and administration. There are also tutorials, user guides, > and WIKI available on the Web. > > > Ease of Deployment > > > > How easy is it to deploy the software? What are > > the dependencies and how can they be satisfied? > > Fossil is a single, stand-alone executable file that > can be installed anywhere in the user's execution path. > Precompiled binaries are available for GNU/Linux, Windows, > and Mac OS X. Fossil has only the ZLIB compression tools > library as its only dependency. > > > Command Set > > > > What is the command set? How compatible is it with > > the commands of CVS (the current open source defacto > > standard)? > > Basic command set with most all core commands identical > to CVS (though the option switches are often different). > > > Networking Support > > > > How good is the networking integration of the system? > > How compliant is it with existing protocols and > > infra-structure? > > Excellent. Fossil integrates both server and client into > a single application. A built-in webserver permits > graphical administration and navigation over HTTP and > HTTPS; as well as providing a bug ticketing system and > a simple WIKI for documentation. > > > Portability > > > > How portable is the version-control system to various > > operating systems, computer architectures, and other > > types of systems? > > Fossil integrates both server and client into > a single application which can run on any POSIX-like > operating system (e.g., GNU/Linux, Mac OS X, MS Windows, > et al). > > > User Interfaces > > --------------- > > > Web Interface > > > > Does the system have a WWW-based interface that can be > > used to browse the tree and the various revisions of the > > files, perform arbitrary diffs, etc? > > Yes. Fossil also includes a web-based bug ticketing > system and built-in WIKI. > > > Availability of Graphical User-Interfaces. > > > > What is the availability of graphical user-interfaces for > > the system? How many GUI clients are present for it? > > Fossil includes a built-in graphical interface which > users would access with their webbrowser. > > > License > > > > What are the licensing terms for the software? > > BSD (open source). > > > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
