5 ms·

I'm a long time git, hg and svn user who has been using fossil every day for over a year now and find it to be reliable, quick and easy to use. It is also very

I'm a long time git, hg and svn user who has been using fossil every day for over a year now and find it to be reliable, quick and easy to use. It is also very hackable and I've customized the "fossil ui" to my liking. However, fossil does lacks some important features that svn, hg and git have: * Fossil does not support versioning directories. In fossil only files are first class objects. It is not possible to commit an empty directory. This is a big shortcoming that all other major SCMs address. * Cannot perform a "fossil diff" for just a directory and its descendants - i.e., no fossil equivalent of the following: # produce a diff for this directory and its descendants git diff . * A "fossil merge" between distributed repos it will give commit attribution to the wrong user for all files in the merge - changes will be recorded as being made by the user performing the merge. This is particularly annoying because it makes "fossil blame" on a given file less effective when pinpointing who introduced what change. There are other fossil issues, but those are the biggest ones that come to mind.

jordigh 11y ago
> Fossil does not support versioning directories. In fossil only files are first class objects. It is not possible to commit an empty directory. This is a big shortcoming that all other major SCMs address. Hm? Neither git nor hg allow this either. The usual workaround in both is to put an placeholder file in the desired "empty" directory, such as a .gitignore.
- node_uzer 11y ago
  hg and svn support versioning directories. I assumed that git also did. If it does not, I stand corrected.
- node_uzer 11y ago
  You're also correct about hg not versioning empty directories with the default mercurial install. A previous place I worked had a non-standard extension - that unknown to me may very well have used the .keep file trick you described. So it would appear that fossil not supporting versioning of directories puts it in good SCM company.
wyoung2 11y ago
> Fossil does not support versioning directories. While that is true, what would revision 2 look like? "This new directory is also empty, but more so?" My point is that an empty directory isn't really "versionable," in the sense that there is something there to be diffed. I converted a few Subversion repos to Fossil, and the empty directories I'd stored were all easily replaced by a dependency in the build system, so that it was created at the point of need. In that sense, the directory is versioned as part of the Makefile. In many cases, your existing tooling already takes care of this, as with "bin\Debug" and such in Visual Studio. > Cannot perform a "fossil diff" for just a directory and its descendants Yes, that would occasionally be nice. Fossil does support directory names in checkins, though, so if you're certain the changes are all confined to one subtree, you can just check that change in, then diff what's left. You can also "stash" a directory, then either diff the stash against the working checkout, or diff what's left, as your workflow requires. > A "fossil merge" between distributed repos it will give commit attribution to the wrong user I suspect that's because the full user table isn't included as part of a clone, nor are local user changes pushed back to the repo you cloned from. The idea of federating identity management gives me the heebie-jeebies. Just ask the PGP folk how well that works. If repo A clones from B, which clones from C, and you want changes made to A to be properly credited in C, the owners of A need to acquire a login on C, sync themselves to C instead of your B repo, and then check their changes in directly, bypassing B.
SQLite 11y ago
> Cannot perform a "fossil diff" for just a directory and its descendants Thanks for the suggestion. I just checked in an enhancements so that this works now. https://www.fossil-scm.org/fossil/info/c46f98055cf49687 https://www.fossil-scm.org/fossil/info/c46f98055cf49687 As for your other short-comings, please mention them on the fossil-users@lists.fossil-scm.org mailing list

jordigh 11y ago

> Fossil does not support versioning directories. In fossil only files are first class objects. It is not possible to commit an empty directory. This is a big shortcoming that all other major SCMs address. Hm? Neither git nor hg allow this either. The usual workaround in both is to put an placeholder file in the desired "empty" directory, such as a .gitignore.

node_uzer 11y ago
hg and svn support versioning directories. I assumed that git also did. If it does not, I stand corrected.
node_uzer 11y ago
You're also correct about hg not versioning empty directories with the default mercurial install. A previous place I worked had a non-standard extension - that unknown to me may very well have used the .keep file trick you described. So it would appear that fossil not supporting versioning of directories puts it in good SCM company.

wyoung2 11y ago

> Fossil does not support versioning directories. While that is true, what would revision 2 look like? "This new directory is also empty, but more so?" My point is that an empty directory isn't really "versionable," in the sense that there is something there to be diffed. I converted a few Subversion repos to Fossil, and the empty directories I'd stored were all easily replaced by a dependency in the build system, so that it was created at the point of need. In that sense, the directory is versioned as part of the Makefile. In many cases, your existing tooling already takes care of this, as with "bin\Debug" and such in Visual Studio. > Cannot perform a "fossil diff" for just a directory and its descendants Yes, that would occasionally be nice. Fossil does support directory names in checkins, though, so if you're certain the changes are all confined to one subtree, you can just check that change in, then diff what's left. You can also "stash" a directory, then either diff the stash against the working checkout, or diff what's left, as your workflow requires. > A "fossil merge" between distributed repos it will give commit attribution to the wrong user I suspect that's because the full user table isn't included as part of a clone, nor are local user changes pushed back to the repo you cloned from. The idea of federating identity management gives me the heebie-jeebies. Just ask the PGP folk how well that works. If repo A clones from B, which clones from C, and you want changes made to A to be properly credited in C, the owners of A need to acquire a login on C, sync themselves to C instead of your B repo, and then check their changes in directly, bypassing B.

SQLite 11y ago

> Cannot perform a "fossil diff" for just a directory and its descendants Thanks for the suggestion. I just checked in an enhancements so that this works now. https://www.fossil-scm.org/fossil/info/c46f98055cf49687 https://www.fossil-scm.org/fossil/info/c46f98055cf49687 As for your other short-comings, please mention them on the fossil-users@lists.fossil-scm.org mailing list