On Fri, 06 Mar 2015 15:11:31 +0100, Tontyna <tont...@ultrareal.de> wrote:
I'm in the 1%, too.
Perhaps that's because of my OS being Windows and me being a Fossil
newbie.
Maybe me and my co-workers aren't exemplars of The Average Fossil User
(current and future) but typing commands in a shell is not our common
approach to move or delete files.
Reference point are files on a harddrive actually belonging to a
specific software project which are managed and altered via IDE and file
browser and afterwards confirmed (not performed) in fossil.
Fossil should not interfere with that worklflow.
I'd prefer that default `rm`/`mv` without options leave my file system
alone. A `--forcefilesytem` flag would be a convenient enhancement.
personally, I would _not_ like to see a mandatory `--forcefilesystem'
"option" in order to get the usually desired behaviour.
otherwise, see the previous mail by jan nijtmans which proposes a very
sensible solution in my view: create a new alias `forget' for the current
`rm' (which then should become the sole command performing that sort of
operation (removing file from `fossil' tracking w/o touching file system)
in due time -- thr sooner the better ...) and start to use the already
existing `rename' instead of `mv'. this would ease the way of making rm/mv
act like they really should (in the view of most people I really would say
-- and that's an important criterion w.r.t. what a "good" default behavior
should be) namely like what is happening in `hg' (I agree with warren
young that the `hg' people seemingly have thought long enough about this
and found a good solution and implemented enough options to cover all
relevant use cases).
another point which has already been made in this thread, but might be
emphasized: of course `mv' and `rm' already touch the file system quite
regularly namely "on the other end": someone updating from your repository
(or your "remote" repo to which you (auto)sync)) after you performed `mv'
or `rm' will of course modify his checkout (as indeed, it should). it
makes (usually, but not always I admit) no sense that locally one has to
go again and again through the routine of mirroring each and every `fossil
rm' and `fossil mv' by a corresponding file system action. I understand
that some people _want_ this but there needs would be satisfied if that is
achieved by `rename/forget' in the future.
-Tontyna
BTW: As soon as I started exploring Fossil I startet developing a GUI
application to comfortably operate Fossil. My GUI is much alike Paul's
`fcommit`.
Am 04.03.2015 um 18:24 schrieb paul:
On 03/03/15 22:27, j. van den hoff wrote:
.....
so, I would second the OP's request to make fossil behave
essentially like svn (or hg) regarding `mv' and `rm'. I'm quite sure
that would be the better behaviour in the overwhelming number of use
cases (i.e. right now I would guess that in 99 out of 100 cases
`fossil mv/rm' is followed by the corresponding os-level command, so
...).
I'm in the 1%.
I prefer _not_ to use the command line. So if I want to move a file or
directory I usually do that with a file browser. Same for deleting.
When I eventually come to doing a check-in, renamed/deleted files show
up in
the missing tab of my fcommit GUI (*), and it's then, using the GUI,
that I
tell fossil what I've done, and then I commit.
If fossil mv also moves files on a filesystem, I'd be happy with that,
so long
as I can still use a file browser as I'm doing now.
If I want to move a file on my hard drive, I think I should be able to
do it
however I like, whether it's managed by a version control system or not.
Regards,
Paul
(*) www.p-code.org/fcommit
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
