On Fri, 14 Dec 2012 00:23:12 +0100, Richard Hipp <d...@sqlite.org> wrote:
On Thu, Dec 13, 2012 at 6:08 PM, Eric <e...@deptj.eu> wrote:
On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu" <altufa...@mail.com>
wrote:
> In order to continue the debate:
> In my work flow, I do rm or mv in file system as and when needed. I
do
> fossil rm or fossil mv only when reviewing my changes before commit.
Well, yes, that is the way I do it too. I suspect that there are some
who do not review their changes before commit, and that many of those
commit way too often, essentially treating their VCS as a backup method.
This of course leads to junk, non-functional checkins, followed by an
unhealthy interest in rebase-like functionality.
Well put.
I don't think so, actually. I've seen misuses (sort of) and misconceptions
of SCMs here (on this list) and elsewhere. that happens. considering
serious and sane use of SCM, I'm still
perfectly sure that for the sole reason (repeated already way to often)
that the by far most frequent use case of `fossil rm' and `fossil mv' will
be a situation where
the file system should reflect the change, the default behaviour should
change. your previous suggestion in this direction did make perfect sense
to me. the present one not so much.
so I strongly opt for a default that does the "real" thing (yes!) of
keeping repo and file system in sync (that's in my view what the SCM
should always strive for. and to relegate different behaviour to the
options, not the other way round.
but, indeed, it is an interesting question why for heavens sake this
issue does cause such a storm on this list? I don't get it. maybe it's too
obvious to me that a default which forces me (and an estimate 99% of the
other users) to type more than necessary -- which I don't like -- (and at
the same time of running the risk of forgetting the additional actions and
starting to mess things up) is no good while others have adjusted their
mind to the current behaviour and don't want to change anything since it
currently "just works" (tm).
I can tell you from own experience that it definitely does not help to
convince svn users, e.g., that fossil is a interesting system (which it
is). and yes: this alone
sure is no argument. but it _is_ an argument if essentially all of the
"competitors" (that I know of) go for the "`scm rm/mv' act on the
filesystem as well" strategy for a reason.
anywayt, I think everything has been said now more than once. I'll try to
keep radio silence regarding this topic from know own (see whether I'm
successful...).
looking forward to the upcoming releases. I'll manage to use fossil in any
case.
j.
So Altu and Eric (and also Joe Mistachkin on a back-channel) have pretty
much convinced me at this point to keep the current behavior of "fossil
rm"
and "fossil mv".
But, should there be an opt-in option to also make the disk changes?
Perhaps "fossil rm abc.txt" just removes abc.txt from configuration
management, but "fossil rm -f abc.txt" also removes it from disk?
And/or should there be a warning printed: "File abc.txt removed from
management but unchanged on disk" just to give a heads-up to newcomers
who
expect different behavior?
--
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
