On 12/16/12 03:28, Joe Mistachkin 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.
Still, I think I'm right. I don't think any of the issues you've
brought up as potential serious issues so far are actual problems. But I
know for sure that the current mv/rm behavior is not what many people
(who have voiced their opinion) expect, and I'm fairly certain that the
change would overall be for the better.
>> 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.
Oh, ok.
# atactl wd0 smart status
id value thresh crit collect reliability description
9 100 0 no online positive Power-on hours count
28691
12 100 0 no online positive Device power cycle count 312
192 100 0 no online positive Power-off retract count 165
225 200 0 no offline positive Load/unload cycle count
227574
232 100 10 yes online positive Unknown 0
233 99 0 no online positive Unknown 0
..and this is my second-most tortured drive. (An Intel-drive, in case
anyone wants to look up the Unknown id's).
The wear and tear in this context is (another) completely bogus
argument. Unless one buys some broken-by-design drive (but again, one
can just as well do that with a spinning-platter disk, so there's still
no valid point).
>> 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.
1) Fossil does file operations in the working directory regardless.
The working directory isn't equivalent to "the filesystem"; in abstract
terms, I see the working directory as the glue between the filesystem
and the repository. The working directory is special; it's a place where
fossil does its magic. I don't see why this needs to exclude mv and rm.
In fact, I would expect fossil to manage (including mv/rm) the files in
the working directory which are under version control.
2) Even looking past #1; without some kind of relevant end-game, what
reason is there to have such a goal? I've only read "We need to separate
them, because we need to separate them" so far, but no one has explained
why it would be more important that The Principle of Least Surprise for
new users.
3) There are other places in fossil which violate this "strict
separation" idea. I don't see any noise about them. Again, I think it's
a bogus argument from start, so I don't want any noise about any other
issues. I can appreciate abstract separations, but in this case I hardly
think it applies. Especially in the face of making fossil more intuitive
I think these made up separations are just nonsense.
>> 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.
Oh, we reached that point 50 posts ago. :)
> 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, but - as has been written so many times now that it's not even
funny any longer: rm/mv has a canonical behavior, and new users continue
to be surprised by the current behavior.
We want to adjust rm/mv according to The Principle of Least Surprise.
I think the vast majority of fossil users will think "Oh, so they
changed it to what I first expected" rather than "panic!".
>> 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.
Or, we can change the behavior of mv/rm, implement the "unmanage" and
corresponding "move" command. Two or three users will sulk for a week,
get over it and then continue living on as nothing has happened. And all
the new users who expect the canonical behavior of mv and rm will no
longer need to be surprised.
>> --------------------
>> 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).
Well, as far as I can see, you're the only one remaining who won't
budge. It seems that the others have accepted it as a good compromise.
We get the real rm/mv, the principle of least surprise for new users,
a canonical behavior for mv/rm, and the old behavior (just under a new
name). Everybody wins! (?)
>> 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.
You're missing the point; whatever problems with the actual
implementation, somehow others have managed to work around them and made
systems which work and that people are happy with. And I'm pretty sure
we can do it too.
Anywho, I think I've had to repeat every point I've made 10 times
now. Either I'm incapable of making myself understood, or people are
just plainly ignoring me. Whatever the reason, I'm starting to feel that
wonderful feeling of futility creeping up, which I guess is a good time
to give up. :)
I can assure you that this topic will be brought up again in the
future (without the help of any of the participants this time around).
I'm pretty sure that had we had the canonical mv/rm behavior from the
beginning, we wouldn't be having these .. er, but reverse, discussions.
Probably worth considering.
--
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
