On Wed, Mar 04, 2015 at 05:52:36PM -0700, Warren Young wrote:
> On Mar 4, 2015, at 5:28 PM, Francis Daly <fran...@daoine.org> wrote:
> > On Wed, Mar 04, 2015 at 03:49:37PM -0700, Warren Young wrote:
> > I think that the principle of least surprise for non-users of fossil is
> > (much) less important.
>
> I think there are many times more future users of Fossil than present users
> of Fossil.
Potential future users, yes. But (selfishly) they are not my concern.
Other opinions exist, of course.
> It will be easier to woo them if we’re not throwing pointless differences in
> their way.
Wooing them is not my ambition.
Disturbing current actual users, few though they may be, is a definite
negative.
Possibly the positive for current actual users who want the behaviour
change, plus whatever positive is associated with future users who will
benefit from the behaviour change, outweighs the negative.
That's a balance for the project to decide.
> > 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.
>
> There really isn’t any historical baggage with mv. Fossil’s the weird one
> here.
Some historical baggage is that right now, one (reasonable?) way to
commit a file rename is
fossil mv a b && mv a b && fossil commit -m mv
If you're going to break that, do it deliberately and loudly.
> > (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.
>
> fossil mv is easy. It’s inherently undoable.
I'm sure it can be, for all combinations of files and directories which
do and do not exist before the "fossil repo+fs-mv", and which are created
after that and before any "undo".
But there's a whole new (I think) set of error cases in there.
(I may be wrong; they may already be covered by "checkout", which would
ease the documentation burden.)
> The Mercurial approach to rm addresses this concern, too. It won’t allow rm
> without -f if you have uncommitted local modifications. If you force it,
> you’ve already given up on undo, IMHO. The tool tried to protect you from a
> potential data loss, and you made it proceed anyway.
Once the error indication and the "recovery advice" are clear, it'll be
fine for interactive use or new scripting use.
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
