On Thu, 13 Dec 2012 14:09:46 +0100, Jan Danielsson
<[email protected]> wrote:
On 12/13/12 05:07, Carson Chittom wrote:
Nolan Darilek <[email protected]> writes:
If we're talking about adding "git" to the name because of this whole
"rm" thing, we might as well consider "mercurial" as a candidate
too. Mercurial behaves sensibly and removes the file automatically on
rm. Naysayers aren't trying to make Fossil Git, we're just trying to
make it do what most other VCSs do in these areas.
Speaking as someone who has absolutely no investment--emotional,
professional, or otherwise--in any VCS other than fossil (and also as a
non-programmer), is "what most other VCSs do" so important?
It's not; there's an important level of indirection that you're
overlooking.
Other VCS's do it automatically because it's the most intuitive way
to do it. I.e. we want to do like other sane VCS's because *they do it
the sane way* (not because they do it in higher numbers). If all other
VCS would require two separate operations, I would still want fossil do
it automatically in one operation.
I know it's being lazy, but sometimes it's simply easier to make the
argument "everyone else is doing it", and let the readers themselves
think about _why_ others do it that way.
Seems
like--while there's certainly potential room for tweaking--there's a
fundamental disconnect, philosophically, between
1) what is in the filesystem
2) what is kept in version control
and while the twain shall meet occasionally (to say the least), they are
not *necessarily* the same. Fossil, after all, is a version control
system, not a filesystem management system. It seems wholly natural to
me that "fossil rm x" should mean "remove the file x from version
control," since "version control" is fossil's raison d'etre. To my way
of thinking, VCSs which also really delete the file when removing it
from version control are violating their fundamental paradigm.
Proper data separation philosophies isn't the reason I use VCS's.
There are aspects of "proper design" which I find to be important, but
in the face of being practical, guaranteeing history integrity, and a
few other properties I could care less about conceptual proper
separation of filesystem/VCS data abstraction layers.
More importantly: I use a fossil in a filesystem (open, checkout, rm,
mv, update, etc), and hence I expect it to do filesystem operations for
me. Which is does, sans rm and mv. I don't buy the "it's separate
layers" argument; a lot of working directory filesystem operations are
already an integral part of fossil -- why exclude rm and mv?
But sticking to the practical side of things: If people are anyways
in 99.99% of the cases going to follow a "fossil rm" by an rm, and a
"fossil mv" by an mv, then I think we should start thinking about
whether it's really necessary to require them to do so when we're in the
perfect situation to do it for them.
Say fossil changes the behavior and performs the requested filesystem
operations immediately, and a few people are really upset about it. I
could write a wrapper script for those uses which does essentially the
following:
cp $file $file.tmp
fossil rm $file
mv $file.tmp $file
That way, people can still do it in two separate steps if they want
to.
Now, consider how many times this will actually be used versus how
many people who do "fossil rm" followed by "rm" and "fossil mv" followed
by "mv".
(I tried to make this point in my last mail, but I don't think people
quite get what I'm trying to say).
well, I dit get it (and that's why I started the thread in the first
place): couldn't have summarized the actual question/problem at hand
better (including that the apparent phobia that fossil might
mercurialized, gittized, or what ever is completely beside the point and
the 99.9% (or whatever) use case is what matters here).
I'm completely surprised by the level of emotion this seemingly innocuous
request/question to sanitize the default behaviour has created. hope
people are going to calm down again soon. and I really don't get it that
at the very least there could be any disagreement that
a `fossil mv' without doing the same to the checkout is not a good default.
joerg
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
