On Dec 27, 2017, at 1:49 PM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > > Any DVCS is going to cause a penalty when the goal is to check out a > particular version of the files from a remote server
…the first time. After you’ve got a clone, operations are usually much faster with a DVCS than a remote non-distributed VCS. > the whole repository normally needs to be duplicated first. Which is why narrow and shallow cloning features can make the difference between “impractical” and “practical” when converting a sufficiently large repository from a traditional non-distributed VCS to a DVCS. In effect, they roll back some of the features you get from a DVCS, making it more like a non-distributed VCS. When the repo size is on the order of that of sqlite.org, however, narrow and shallow clones buy you little, and they cost you the inherent backup you get by distributing your entire repository everywhere. My war story above about about my lost repository on Gna! was because it was hosted in Subversion, so I lost all project history between the last svnadmin backup I made and the working copies on my development machines. That won’t happen now that that project is hosted on Fossil: every user of that software project holds the whole project history now. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
