Jan Danielsson wrote:
>
> First, I feel you're inventing problems to make arguments in order to
> exclude features which address real world issues. (A little like the
> script issue brought up earlier).
>
Straw man argument. Five yard penalty, still first down.
>
> Second (slightly off-topic), What's the problem with SSD and large
> files? I have been using SLC SSD's since 2007, and since 2008 almost
> exclusively mixed SLC and MLC SSD's on both servers and clients. On two
> machines I regularly handle multi-GB files, and have not encountered any
> issues which I haven't encountered with spinning-platter disks. I fail
> to see why I would suddenly start having issues with large files because
> I'm using fossil on SSD:s? (which, I'll admit, I have not).
>
The point here is wear-and-tear on the SSD, which have a finite limit of
the number of bytes they can write during their useful lifetime. Sorry
if this point was not clear in my previous response.
>
> ...and also, when you revert a deleted file, doesn't fossil need to
> scan through the entire file to see if it has changed? If you revert a
> multi-GB file, you'll still need to spend some time waiting for it, no?
>
I was not referring to the performance, see above.
>
> There are lots of ways you can screw up, but the important thing is
> that you can recover. I also think we have to assume that the normal
> case is that people won't screw up, and assume that normally people
> double check before they do something. (Wasn't that one of the insults
> directed at those of us who want real mv/rm? That we just blindly do
> things without thinking things through? Ironic twist (yes, I know you
> weren't the one to say it, but someone else did)).
>
I just think there should be a clear division between Fossil commands
that interact with the file system and those that do not. I expect
the "clean" and "revert" commands to deal with modifying files in the
file system; however, I would not expect the "add", "mv", and "rm"
commands to do that.
>
> Plus, if you know you're setting yourself up for such a situation,
> then don't use the real rm; use the command which has retained the old
> behavior ("unmanage", for instance).
>
Bike shedding. The new command, say "realrm" (or whatever) could just
as easily be made to perform the semantics you desire instead of breaking
backward compatibility by modifying existing commands.
>
> Yes. (I recommend you read through the threads; some of the issues
> you raise have been discussed previously).
>
Frankly, I've been trying to avoid getting involved in this discussion
at all. If people really want "mv" and "rm" to perform file system
operations, they can already:
1. Write a wrapper script that performs the operations.
2. Customize their local Fossil binaries to include the necessary code.
Also, I have read most of the messages in this thread; however, I think
it may be next to impossible to read them all. I do not even know how
many messages there are in total.
>
> --------------------
> Stage 1:
> (a) "fossil rm -f" deletes from disk (if it is safe to do so)
> (b) "fossil rm" works as currently, but prints a warning message that it
> will delete from disk in a future release.
> (c) "fossil delete" works as currently
> (d) "fossil unmanage" added as an alias for "fossil delete"
>
> Stage 2 (after a stage 1 has been released for a while):
> (e) "fossil rm" works just like "fossil rm -f"
> --------------------
>
I agree with (1a), (1c), and (1d). I disagree with all the others,
especially (2e).
>
> How come all these points you listed aren't issues with other source
> management systems which have real rm/mv?
>
Frankly, I don't use the those other systems on a regular basis and I
really do not care what they do. Sorry.
--
Joe Mistachkin
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
