On 12/15/2012 06:28 PM, Joe Mistachkin wrote:
> 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.
So, you're saying that we wouldn't want to remove files from disk when
they're removed from the repository, because that action--which probably
wouldn't be a daily occurrence, and in my own personal use is a
once-every-week-or-so kind of thing--would be potentially bad for SSDs?
I'm sympathetic to the idea that software should be written with a
certain efficiency or hardware-awareness in mind, but this seems like a
bit of a stretch.
>
>> ...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.
Frankly speaking, I'd expect the opposite, but more than anything else
I'd expect that the documentation can tell me what commands do what.
And, again, if the user issued the 'fossil rm' and it removed the file
from the repo and from disk, couldn't the user just pull it back out of
their last checkin, if for some reason they wanted to unmanage it but
retain it?
Or, put another way, how often have you wanted to delete a file from a
repo, but not delete it from disk? Or move it within the repo, but not
wanted to move it on disk? Is there any practical reason you're opposed
to this minor change in how the command works, or is it an adherence to
a principle of making as few incompatible changes as possible?
>
>> 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
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
