> 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?
This is available from the web interface, under file history. Each checkin has an 'annotate' link to the right of it that displays line by line history with update time and the owner of the change. -----Original Message----- From: saulgo...@flashingtwelve.brickfilms.com Sent: Friday, September 17, 2010 10:01am To: fossil-users@lists.fossil-scm.org Subject: [fossil-users] Discussion of Better 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. 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. > 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. > 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. > 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'. > 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 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
