On Tue, 11 Dec 2012 22:50:06 +0100, Themba Fletcher
<themba.fletc...@gmail.com> wrote:
Sorry to drag up an old thread, but I'm just checking back in after a
lengthy absence.
On Fri, Nov 30, 2012 at 9:33 AM, Nolan Darilek <no...@thewordnerd.info>
wrote:
Weighing in on this, finally:
It's interesting to me that everyone speculates that this *might* break
things for some hypothetical person, and *might* bite someone, but has
anyone here ever been bitten by it?
It's the "what if" that bothers me. I use fossil as a safety net to
manage an ungodly number of small maintenance projects, so I'm often
not the original author of the project, and am almost never really
comfortable with the code base I'm modifying.
When I sync a code base to my machine and "fossil add . --dotfiles" I
really appreciate the fact that I can trust fossil not to touch the
disk if I accidentally add something that I don't want in there and
have to remove it.
In the presence of shabby and poorly maintained deploy/sync scripts,
solo use of fossil, unknown modifications to the master since the last
checkin, etc., the consequences of removing something from my local
copy could be pretty embarrassing -- ie I could potentially blow away
the only working copy of a new cusomer's web app. Not to say that I
couldn't adjust to a new set of danger points, but that I do really
appreciate fossil's current behavior.
And is it not something that "fossil revert" could undo?
Is it? What about:
fossil add .
(whoops) -> fossil rm something
fossil commit
(take a phone call and forget it's fossil 2.0)
sync up
Now the files are gone locally, they're gone on the remote site, and
fossil revert isn't going to help. This is obviously a workflow /
deploy problem at its root, but it's a bit of sloppiness that fossil's
current behavior forgives and the proposed behavior would not.
I don't mind avoiding the change until a 2.0 release, but I worry about
making it a setting, because I prescribe to the idea that settings add
complexity both for users and developers.
I agree about minimizing the extra overhead of a setting, but I come
down personally on the side of "it's working fine, so please don't
touch it." Maybe my use case varies from the norm, but I don't do
fossil rm all that often and, when I do, the extra overhead of having
to do "Up arrow, Ctrl-A, Alt-D, Return" afterwards doesn't bother me
at all. I like explicitly taking care of this as a second deliberate
step.
My $0.10 adjusted for inflation: keep the existing behavior until 2.0,
then
just change it. There are plenty of settings already, please don't add
another, especially for something that we're all speculating might
affect
someone who can't just revert for whatever reason.
So, respectfully disagree. For me it's about not having to learn new
rules about when fossil will touch my files and when it will not.
for me it's about what is the most sane (or probably expected) default
behavior for the majority of users.
this question has been answered several times by the developers/users of
other SCMs (hg, svn, ...) to the
extent that `rm' and 'mv' should act on the files in the checkout as well.
for me, they were right: when
executing commands via the SCM (fossil in the present context) one can
_expect_ that something will happen
to the checkout and that fossil's opinion of what the state of the project
is should be in sync with the
checkout as far as possible. _usually_ `fossil mv' and `fossil rm' should
imply that the action is applied
to the checkout as well (do the rename or deletion of the file). more
often than not (I'd say) that's what
the user will want to happen. and that's what the default behavior should
cover.
of course I understand that this might exactly be _not_ your use case. but
we are talking about _default_ behavior (and possibly delegating diverging
behavior to options). in my use case I _always_ have to mv/rm (mv is
especially bad, if forgotten) the checkout files manually and my suspicion
is that's exactly what the majority of users will do currently. which
would indicate that the current behavior is suboptimal.
best regards,
joerg
Best Regards,
Themba
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
