On Sat, Dec 15, 2012 at 06:28:52PM -0800, 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.
zsh: sports metaphor not found
> >
> > 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.
HDDs also suffer wear and tear during I/O operations, and new SSDs easily
last long enough that, relative to HDDs, this should no longer be any
kind of problem. In fact, the major problem is not that SSDs have a
limited number of writes; so do HDDs. The "problem" is that you can know
in advance how many you have, while with HDDs it's a roll of the dice.
> >
> > 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.
I think there should be a clear division, as well. Those commands that
mimic the form of filesystem operations (e.g. `rm`) should, where at all
reasonable to do so, be on the filesystem interaction side of that
divide. Those that do not (e.g. `delete`) can be on the other side of
it.
> >
> > 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.
It's not just bikeshedding if it's a matter of actual tool usability.
> >
> > 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.
. . . which works great for new users! Oh, wait, no it doesn't.
>
> 2. Customize their local Fossil binaries to include the necessary code.
. . . which perfectly solves the POLS problem for both new users and
people who have to interact with the rest of the world sometimes! Oh,
wait, no it doesn't.
>
> 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.
I've read them all. It was easy.
> >
> > --------------------
> > 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).
. . . but not for any solid reasons I've seen.
> >
> > 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.
Because *you* never really interact with the rest of the world, the fact
the rest of us do is irrelevant, I guess. It's all about you.
Don't forget that there was a real question in that. You claim there are
huge problems with the proposed new behavior of `rm` and `mv` for Fossil
SCM, but the example of other VCSes makes it clear these problems do not,
in fact, materialize in practice. Your lack of experience with those
other systems does not in any way invalidate the question.
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
