On Wed, Mar 04, 2015 at 03:49:37PM -0700, Warren Young wrote:
> On Mar 4, 2015, at 3:27 PM, bch <brad.har...@gmail.com> wrote:
Hi there,
> > Sure, but: fossil is distinct from the filesystems. DOS, ext<n>, ffs,
> > etc., etc., etc are not versioning/managment filesystems, and there
> > ought to be a principle-of-least-surprise/being-a-good-citizen kept in
> > mind.
>
> The principle of least surprise says that Fossil should behave like other
> VCSes.
I think that the principle of least surprise for users of fossil is
that the next version of fossil should be pretty much "the same as the
current version, only better".
I think that the principle of least surprise for non-users of fossil is
(much) less important.
I think that the last few times this topic came up on the list, there
was not a clear enough consensus that changing some fossil commands to do
something (potentially) destructive which they are explicitly documented
not to do, that the patches were not accepted.
Perhaps this time it will be different.
For what it's worth, I do think that it would be useful to have a command
to affect both the repository and the filesystem in similar ways. But I
also think that historical baggage suggests that "rm" (or "mv") is not
that command.
The matrix in the "hg remove" documentation does cover many (possibly
all?) cases. Perhaps a "fossil remove" command could act just like
it? With a "fossil move" command to do "fossil mv + suitable
filesystem manipulations"?
(I confess that I'm not clear on exactly how (or
whether) "undo" or "revert" will become involved in the new
remove-from-repository-and-filesystem command/argument. I think I didn't
understand it the last time around, either.)
But one thing I know, is that I won't be the one writing the patches,
or deciding whether they go into stock-fossil.
Cheers,
f
--
Francis Daly fran...@daoine.org
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
