On Fri, Aug 9, 2013 at 4:19 AM, Chad Perrin <[email protected]> wrote:
> On Thu, Aug 08, 2013 at 10:48:36PM +0200, j. van den hoff wrote: > > > > 1. > > the "Unlike most popular DVCSes..." is a bit misleading. all of them > have > > a database for each checkout, of course, but not in a single file. > backing > > them up is not really that much more complicated. I would try to > emphasize > > a bit more that the difference is indeed that fossil uses a "monolithic" > > database, i.e. a single file instead of a directory tree and that has > > indeed some advantages if you only use `cp' since you don't run into > > permission issues. > > I was trying to point out the distinction between the checkout and the > repository file -- not to say that Git (for instance) doesn't have any > "database" of version control. I tried to clarify the text, though, > without overcomplicating things, given the very simple approach I'm > trying to maintain. > Fossil and Monotone uses a relational database whereas Git uses an ad-hoc "pile-of-files" database. Fossil provides a rich set of views of the project history, such as timelines that can be between particular dates or around a particular date or associated with a particular user or branch or tag or file, and things like the activity reports that Stephan recently added. Fossil also provides wiki and ticketing. Git does not provide those facilities. I suspect the reason for this is that providing these rich reports in Fossil is simply a matter of a five- or ten-line SQL query followed by a little code to reformat the results for display, whereas in Git one has to write and debug hundreds or thousands of lines of procedure code to sift through the pile-of-files database looking for the requested information. Thus these advanced features are much more difficult to write and maintain in Git, and hence they are much less common. The database for Fossil is also ACID. Not so with Git. If you loss power in the middle of a Git command, it can leave the database in a dodgy state. Git has to be very careful that updates to its database occur in just the right order with fsyncs() at the right times, in order to avoid corrupting the repository on a power loss. We hope the Git developers got it all right! With Fossil, atomic and consistent updates to the repository are guaranteed by the underlying database engine, giving Fossil developers considerable freedom of implementation and making the repository highly resistant to corruption due to bugs in the Fossil code. The database engine in Fossil automatically takes care of serializing access to the repository. So multiple processes can safely use Fossil at the same time. I've never tried to use Git simultaneously from two different processes, but I strongly suspect that the results would not be pretty. And, yes, you can move around a Git repository by copying the entire directory tree that implements Git's pile-of-files database. But it is ever so much more convenient to be able to copy a single file than it is to copy a complete file hierarchy. -- D. Richard Hipp [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
