On 12/16/12 00:36, Joe Mistachkin wrote:
[---]
> 2. [---] On the other hand, if the
> "mv" and "rm" commands were to perform their file system actions
> prior to commit, would "revert" need to bring the previous files
> back to life? That does not make sense.
Why not?
$ fossil rm foo.txt
foo.txt deleted from filesystem, and marked for removal in the
repository.
...ops, wrong file..
$ fossil status
foo.txt DELETED
$ fossil revert foo.txt
..brings back the file in the filesystem, and unmarks file for removal..
Why doesn't that make sense?
> 3. Related to the previous problem... Think about very large files.
> If the "rm" command removes a very large file from the file system
> and later it needs to be restored, that is a whole lot of file I/O
> (potentially up to several GB). This can be very hard on machines
> that are using SSD as their primary storage.
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).
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).
Anyway, even with the current behavior, one could "fossil rm" a few
GB-sized files, then remove the files from the filesystem, and later
realize one was in the wrong directory or something, so even with the
current situation one could end up needing to wait a while for a
reverted undelete.
...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?
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)).
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).
And finally, if you're worried about performance, try working with
the netbsd repository. IMHO, there are far more common everyday
optimizations which need to be done looooooong before we worry about the
odd "several GB data was deleted by mistake from a working tree.".
> 4. What happens if a user tries to "rm" a file that does not exist in
> the repository? Presumably, it would just issue an error message?
Yes. (I recommend you read through the threads; some of the issues
you raise have been discussed previously).
> 5. What happens if a user tries to "rm" a file that has been shunned
> at some point?
What's the current behavior, and why would it need to differ?
> 6. What happens if a user tries: "fossil rm ." ?
What happens them you type:
$ rm .
.. ?
And what happens in other SCM's which support real rm?
> 7. What happens if a user needs to add all files in the directory
> except for generated files (i.e. "fossil add .")? After that
> point, normally *I* would "rm" the extra files; however, I do not
> want them deleted from the file system.
You appear to be assuming that the suggestion is to change the
behavior of rm/mv and not retain the current behavior in any shape or
form. The suggestion which finally seemed to have pleased (mostly) both
sides was:
--------------------
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"
--------------------
So, you'll be able to continue doing exactly what you are doing sans
s/rm/unmanage/. Everyone gets the behavior they want; others who
previously opposed real mv/rm seem to think that the latest suggestion
was a good compromise. For a brief moment, I thought that both sides
getting what they want would be the end of it..
How come all these points you listed aren't issues with other source
management systems which have real rm/mv?
--
Kind regards,
Jan Danielsson
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
