fossil rm should not remove a file it doesn't manage or has changes, just
like other SCM systems. In this case, the file in question has changes, as
it is brand new, the entire file has changed. Thus, if you were to (in the
future) do:
$ fossil rm #document_manager.php#
File has changes, not removing from disk.
Jeremy
-----Original Message-----
From: Themba Fletcher
Sent: Wednesday, December 21, 2011 4:40 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Behavior of rm, mv, and changes/extra
Well here's a fun thing that just happened:
tif@w...:~/Projects/ACSS/project$ fossil extra | grep -v db/
site/common/classes/document_manager.php
tif@w...:~/Projects/ACSS/project$ fossil extra | grep -v db/ | xargs
fossil add
ADDED site/common/classes/#document_manager.php#
ADDED site/common/classes/document_manager.php
So in the time it took me to type up-arrow | xargs fossil add my editor
pulled an auto-save, and fossil added (2) files instead of one. Now I've
got:
1. a file in my repo that I don't want
2. and it's not under version control, so I can't get it back if
fossil deletes it
It's a simple fossil rm away from being solved, but ...
Assume a destructive fossil rm, and let's say the file is precious
rather than just an autosave file. Lots of ways to get around the auto
delete, but not necessarily obvious ones and someone, somewhere is going
to learn how it works the first time by having fossil delete their file
unexpectedly.
Nope, I suddenly find myself a fan of the two step process as it stands.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
