On Sat, Jun 18, 2016 at 1:21 PM, Paul Hammant <p...@hammant.org> wrote:
> Curiosities: > > - Having a database name rather than just a .git or .svn folder > convention > - The 'open' step. > > Fossil and SVN are more similar than you seem to think. Fossil's "open" command is much like SVN's "checkout" command. Both take a path to a repository. The difference being that Fossil expects a local database file while SVN expects an URL to the repository, which SVN treats as remote, even if it is local. This is because SVN clients all work from a central repo, while Fossil works with a local repo that might be a copy of a remote/central repo. And, like SVN's "checkout" command, "open" also checks out files into your working copy. Also, like SVN, when a working copy is created, a .fossil file is created in the base folder of the working copy. (SVN uses a folder, Fossil uses a database file.) Fossil's "update" is pretty much the same as SVN's "update". Fossil's "checkout" is a bit different. While it fetches the specified version of files, it does not attempt to merge with local changes. So, like SVN, Fossil allows multiple working copies from the same repo. But Fossil working copies are associated with a local repo while SVN working copies are associated with a remote/central repo. The local Fossil repo is what might be associated with a remote/central repo. A pull, push or sync command done from any of the working copies will cause the associate repo to interact with the remote repo. SVN commands always interact directly with the remote repo, so SVN doesn't have pull, push or sync. Also, when you commit from one local working copy, you can then update from another local working copy without doing a pull, push or sync. Remote working copies won't be able to update to your commit until pull, push or sync (as appropriate) is done to get the commit transferred. git, on the other hand, every working copy has it's own local copy of the repo, so each local working copy is completely independent, just as a remote working copy would be. To transfer commits between git working copies - local or remote - you have to pull, push or sync. >From my point of view, Fossil provides the best of a DVCS with the best features of SVN or other non distributed VCS. I can perform VCS operations "off line", even with multiple working copies (with only one local copy of the repo), then still be able to easily sync to a remote repo once online.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
