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
