On 23 October 2014 12:26, Ron W <ronw.m...@gmail.com> wrote: > Having read post from many places, one of the big complaints SVN users have > about Git is directory tracking. Fossil lack this, too.
I had a weird related issue the other day (I would argue it's a bug, but YMMV). I was moving an existing directory hierarchy into a new fossil. I had a sub-directory TeX that had lots of TeX-related files in it. I said fossil add and it added all the files from the TeX directory. Seeing that I realized that I had TeX directories under many projects that had often essentially been a copy of each other, so I decided to move TeX elsewhere and replaced it by a symlink to the other location. I then said fossil addremove . and expected it to remove all those files (I hadn't yet committed) and add the symlink (I have allow-symlink set globally). Instead it said it had nothing to do. I worked-around, but it was surprising. I expected it to discover the symlink in the path to the files and consider everything below to no longer be there. I also found another (I think bug) with addremove. I did an addremove . but it added things in .. directories. : ~/fs/Admin/bin ; touch bar : ~/fs/Admin/bin ; fs extra bar ../homedir/Emacs/Startup.el-original : ~/fs/Admin/bin ; fossil addremove . ADDED bin/bar ADDED homedir/Emacs/Startup.el-original added 2 files, deleted 0 files One other surprise, while I'm at it: : ~ ; ls Fossils/Admin.fossil Fossils/Admin.fossil : ~ ; cd fs : ~/fs ; mkdir blah : ~/fs ; cd blah : ~/fs/blah ; fs open ../../Fossils/Admin.fossil bin/update-fossils ... project-name: Admin repository: /Users/dmason/fs/blah/../../Fossils/Admin.fossil local-root: /Users/dmason/fs/blah/ config-db: /Users/dmason/.fossil project-code: 70274e3df807d403e5d292f7c84e26eebf6f7119 checkout: 2f095fe0993a5aa584398b392d03d0e7ce304c6c 2014-10-20 19:36:40 UTC parent: d2b6e3978227013ca3ec6bff0aece4fad6522093 2014-10-08 11:30:58 UTC leaf: open tags: trunk comment: update-fossils (user: dmason) checkins: 4 : ~/fs/blah ; fs open ../../Fossils/Admin.fossil already within an open tree rooted at /Users/dmason/fs/blah/ If I'm doing the open in the root of the tree, and it's the same fossil, I don't see why it needs to say anything, or at most say, "Already open in this directory" or something like that. The error scares me and (if I wasn't thinking) I might try it again with --nested, to which you get: : ~/fs/blah ; fs open --nested ../../Fossils/Admin.fossil SQLITE_ERROR: table vvar already exists fs: table vvar already exists If you have recently updated your fossil executable, you might need to run "fossil all rebuild" to bring the repository schemas up to date. which could be very scary! "Already open" would be much more calming. ../Dave (loving fossil, but surprised more than I like) _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users