Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Michael Richter]

Do you two need a room?  If so, there's a local so-called "love hotel" I
can book for you in two-hour slots.


On 18 December 2012 13:00, Chad Perrin  wrote:

> On Sun, Dec 16, 2012 at 05:02:23PM -0800, Joe Mistachkin wrote:
> >
> > Chad Perrin wrote:
> > >
> > > If you use bleeding edge versions, you should already be prepared to
> deal
> > > with changes in behavior.  I don't see the problem.
> > >
> >
> > I help write the "bleeding edge" versions.  Therefore, it is useful that
> I
> > run them on a daily basis as well.
>
> . . . therefore, I don't see the problem.
>
>
> > >
> > > There will always be someone disenfranchised.  The question is whether
> we
> > > should disenfranchise people who are very, very bad at software
> > > management, or disenfranchise people who want their software to work
> in a
> > > reasonable manner.
> >
> > I would just like to point out here that, contrary to your assertion to
> the
> > contrary, I do care about other people besides myself in this matter.
>
> I'd call it a suggestion, rather than an assertion.  I don't think I
> quite explicitly made that charge.  It's nice to know you care, though.
> Perhaps you'd like to acknowledge that fact in future comments rather
> than phrase your commentary like that two which I responded.
>
>
> > >
> > > Show me where I "demonized" anyone.  I didn't imply people are stupid,
> > > the way some emails opposed to changing `rm` and `mv` have.  I didn't
> say
> > > people were morally reprehensible, acting maliciously to make others'
> > > lives difficult.  I just asked about whether the primary priority
> should
> > > be for people who don't care enough about their work to pay attention
> to
> > > their tools.
> >
> > It's very subtle, but it's there.  To quote, "someone who will never pay
> > attention to warnings".  Out of curiousity, how many warnings given by
> > software do *YOU* routinely ignore (e.g. web site security, etc)?
>
> "Someone who will never pay attention to warnings" isn't a demonization.
> It's a characterization of people who, well, never pay attention to
> warnings -- which, you may note, was obviously not directed at you
> personally, in any case.
>
> There are people out there who never pay attention to warnings, and
> people who use four-year out of date software with critical security
> vulnerabilities left unpatched.  Screws fall out all the time.  The world
> is an imperfect place.
>
> Please tell me who else would not notice warnings over a gentle
> deprecation period with warnings other than:
>
> 1. those who never pay attention to warnings
>
> 2. those who go for ridiculously long times without updating software
>
> I'm willing to acknowledge the existence of people in large numbers
> falling through that crack if you can point out such a crack through
> which large numbers of people might fall.  The world is, after all, an
> imperfect place (see above).  I just see no evidence of them in any
> arguments for inflexible stasis of software defaults so far.
>
>
> > >
> > > . . . except that, given your reactions to some of the other things I
> > > said, you seem inclined to take statements as insults when they
> obviously
> > > are not intended as insults, so the problem isn't really solved on your
> > > end.  Right?
> >
> > After having read several of your previous posts to others on this list,
> > including several containing insults, it seemed to be a fair assumption.
>
> I recommend you read for denotative meaning of words rather than for
> imagined tone in the future.  Emails do not generally come with tone of
> voice.
>
>
> > >
> > > That seems like another implementation detail.
> >
> > I'm not sure how to respond to this.  Yes, changes to software do require
> > changing the implementation.
>
> When taken in isolation, ignoring everything else I said about
> implementation details, I suppose it's easy to pretend I said something
> nonsensical.
>
> --
> Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
"Perhaps people don't believe this, but throughout all of the discussions
of entering China our focus has really been what's best for the Chinese
people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Sun, Dec 16, 2012 at 05:02:23PM -0800, Joe Mistachkin wrote:
> 
> Chad Perrin wrote:
> >
> > If you use bleeding edge versions, you should already be prepared to deal
> > with changes in behavior.  I don't see the problem.
> >
> 
> I help write the "bleeding edge" versions.  Therefore, it is useful that I
> run them on a daily basis as well.

. . . therefore, I don't see the problem.


> > 
> > There will always be someone disenfranchised.  The question is whether we
> > should disenfranchise people who are very, very bad at software
> > management, or disenfranchise people who want their software to work in a
> > reasonable manner.
> 
> I would just like to point out here that, contrary to your assertion to the
> contrary, I do care about other people besides myself in this matter.

I'd call it a suggestion, rather than an assertion.  I don't think I
quite explicitly made that charge.  It's nice to know you care, though.
Perhaps you'd like to acknowledge that fact in future comments rather
than phrase your commentary like that two which I responded.


> > 
> > Show me where I "demonized" anyone.  I didn't imply people are stupid,
> > the way some emails opposed to changing `rm` and `mv` have.  I didn't say
> > people were morally reprehensible, acting maliciously to make others'
> > lives difficult.  I just asked about whether the primary priority should
> > be for people who don't care enough about their work to pay attention to
> > their tools.
> 
> It's very subtle, but it's there.  To quote, "someone who will never pay
> attention to warnings".  Out of curiousity, how many warnings given by
> software do *YOU* routinely ignore (e.g. web site security, etc)?

"Someone who will never pay attention to warnings" isn't a demonization.
It's a characterization of people who, well, never pay attention to
warnings -- which, you may note, was obviously not directed at you
personally, in any case.

There are people out there who never pay attention to warnings, and
people who use four-year out of date software with critical security
vulnerabilities left unpatched.  Screws fall out all the time.  The world
is an imperfect place.

Please tell me who else would not notice warnings over a gentle
deprecation period with warnings other than:

1. those who never pay attention to warnings

2. those who go for ridiculously long times without updating software

I'm willing to acknowledge the existence of people in large numbers
falling through that crack if you can point out such a crack through
which large numbers of people might fall.  The world is, after all, an
imperfect place (see above).  I just see no evidence of them in any
arguments for inflexible stasis of software defaults so far.


> > 
> > . . . except that, given your reactions to some of the other things I
> > said, you seem inclined to take statements as insults when they obviously
> > are not intended as insults, so the problem isn't really solved on your
> > end.  Right?
> 
> After having read several of your previous posts to others on this list,
> including several containing insults, it seemed to be a fair assumption.

I recommend you read for denotative meaning of words rather than for
imagined tone in the future.  Emails do not generally come with tone of
voice.


> >
> > That seems like another implementation detail.
> 
> I'm not sure how to respond to this.  Yes, changes to software do require
> changing the implementation.

When taken in isolation, ignoring everything else I said about
implementation details, I suppose it's easy to pretend I said something
nonsensical.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Sun, Dec 16, 2012 at 05:13:24PM -0800, Joe Mistachkin wrote:
> 
> Chad Perrin wrote:
> >
> > zsh: sports metaphor not found
> > 
> 
> Sorry, I was attempting to inject some humor into this discussion because
> it has grown very tedious.

I guess you didn't find my rejoinder amusing.


> > 
> > HDDs also suffer wear and tear during I/O operations, and new SSDs easily
> > last long enough that, relative to HDDs, this should no longer be any
> > kind of problem.  In fact, the major problem is not that SSDs have a
> > limited number of writes; so do HDDs.  The "problem" is that you can know
> > in advance how many you have, while with HDDs it's a roll of the dice.
> 
> My original point of doing (potentially several GB of) superfluous file I/O
> still stands.

. . . unless you pay attention to what I said.


> >
> > It's not just bikeshedding if it's a matter of actual tool usability.
> 
> Funny, I've been using Fossil for years and this usability "problem" has
> never bothered me.  In fact, quite the opposite.

The point has been made many times that the usability issue under
discussion is relevant to certain people, while certain others may not
experience the same issue.  The question under discussion is how to
determine which is the more important group to satisfy, which to some
extent involves an estimate of numbers.  Considering the number of new
users who have not yet started using Fossil but might some day, and who
are quite familiar with both Unix environments and other VCSes newer than
CVS, combined with the number of current users who find the current
behavior of `mv` and `rm` somewhat confounding, is surely much greater
than the number of people currently using Fossil who never encounter
other VCSes and Unix environments to give a crap, I fall on the "we
should change things" side of the debate.


> >
> > . . . which works great for new users!  Oh, wait, no it doesn't.
> 
> There is always a learning curve for new users, however slight.

I suppose that means we should make the curve as steep as possible,
regardless of whether it actually buys us anything, then.  Right?  If
they can't hack it, let them use rcs instead.  They can eat cake while
they're at it.


> >
> > I've read them all.  It was easy.
> 
> I didn't want to read them all.

Okay.  Why didn't you say so in the first place?


> > 
> > Because *you* never really interact with the rest of the world, the fact
> > the rest of us do is irrelevant, I guess.  It's all about you.
> 
> I'm growing increasingly tired of your attempts to insult me.

That's not an insult.  It's marveling at your egocentric dismissal of
everyone in the world with a different computing experience than you,
which some of the rest of us might find insulting if we were as thin
skinned as you.


> > 
> > Your lack of experience with those other systems does not in any way
> > invalidate the question.
> 
> I never stated that I lack experience with those other systems; however,
> I use them only very rarely.

That's a lack of experience, just as a trial lawyer of twenty years would
refer to my involvement in Youth In Government twenty years ago in the
trial law part of the program as a lack of experience.  I don't really
consider occasional dilettentes "experienced" in a significant sense.

Really, I think the thing that irks me most about many of the arguments
on your side of the debate is their condescending dismissal of the
possibility that someone might have a meaningful argument for changing
the behavior of `mv` and `rm` Fossil commands, even if it is not deemed
compelling enough to change things by core contributors.  In previous
emails, by contrast, I have tried to address concerns of those who
disagree with me on the overall desirability of the proposed changes by
suggesting deprecation followed by eventual change in accord with
semantic versioning.  Others have made similar suggestions to try to
satisfy everyone involved.  You, meanwhile, have taken the position of
"Screw you and the horse you rode in on; you can have some other command
instead that doesn't actually address core concerns you've raised."

Perhaps you should think about that before blowing people's concerns off
as meaningless and accusing them of insulting you.  Even if someone has
insulted you, that doesn't justify your own insulting lack of regard for
anyone who might not have exactly the same software usage habits as you.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Mike Meyer]

I don't really care which behavior is the default. I've dealt with
both long enough that neither is surprising, and my workflow doesn't
change enough to notice for this. I'm just tired of seeing the bogus
claim that one is somehow "surprising" and "natural" and one isn't.

The only thing I want to avoid is a builtin "fossil rm" that can do
different things in different repos that are supposedly running the
same version of fossil. Well, ok, I also really don't want the silly
git behavior of having to force the SCM to record a move in the repo
that's already happened on disk.

On Sun, 16 Dec 2012 11:06:57 -0500
daniel gregory  wrote:
> >   Yes, but - as has been written so many times now that it's not even
> > funny any longer: rm/mv has a canonical behavior, and new users continue
> > to be surprised by the current behavior.
> This is so true.

Only if you behave the way you want to:

> not for something where I have to think "rm" in unix is this, but
> "rm" in fossil means this.

It doesn't matter whether it touches the work space or not, "rm" in
fossil means something different than "rm" in unix. It *has* to. Unix
doesn't know anything about fossil repositories, so it's "rm" *can't*
deal with them. The only thing that would be surprising is if "fossil
rm" actually did what unix rm does, and removed a file from disk
without changing the repo in any way.

The only way you can be surprised by either behavior is if you do what
daniel suggests, and *don't* think about what you're doing. This kind
of surprise - cause by thoughtlessly extrapolating from a *different*
command set - is not what POLS is about. Otherwise, Unix would have a
DEL command because people coming from VMS/DOS/RSTS/etc were surprised
that it didn't. I don't see anything *in fossil* that would lead one
to expect "rm" or "mv" to have either behavior.

My gut reaction:

This is a silly argument, caused by people being overly attached to
those two-letter commands. Just nuke them both. "del" and "ren" both
work fine, and are only one character longer. A "--filesystem/-f" flag
would be nice if the commands don't change. If they change to touch
the filesystem - well, make sure they always queue changes to the repo
for the next commit, even if they fail to change the file system for
some reason. And a flag that says "repo only, ignore the file system"
would probably be appreciated by some.

   http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Joe Mistachkin]

Chad Perrin wrote:
>
> zsh: sports metaphor not found
> 

Sorry, I was attempting to inject some humor into this discussion because
it has grown very tedious.

> 
> HDDs also suffer wear and tear during I/O operations, and new SSDs easily
> last long enough that, relative to HDDs, this should no longer be any
> kind of problem.  In fact, the major problem is not that SSDs have a
> limited number of writes; so do HDDs.  The "problem" is that you can know
> in advance how many you have, while with HDDs it's a roll of the dice.
> 

My original point of doing (potentially several GB of) superfluous file I/O
still stands.

>
> It's not just bikeshedding if it's a matter of actual tool usability.
>

Funny, I've been using Fossil for years and this usability "problem" has
never bothered me.  In fact, quite the opposite.

>
> . . . which works great for new users!  Oh, wait, no it doesn't.
>

There is always a learning curve for new users, however slight.

>
> I've read them all.  It was easy.
>

I didn't want to read them all.

> 
> Because *you* never really interact with the rest of the world, the fact
> the rest of us do is irrelevant, I guess.  It's all about you.
> 

I'm growing increasingly tired of your attempts to insult me.

> 
> Your lack of experience with those other systems does not in any way
> invalidate the question.
> 

I never stated that I lack experience with those other systems; however,
I use them only very rarely.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Joe Mistachkin]

Chad Perrin wrote:
>
> If you use bleeding edge versions, you should already be prepared to deal
> with changes in behavior.  I don't see the problem.
>

I help write the "bleeding edge" versions.  Therefore, it is useful that I
run them on a daily basis as well.

> 
> There will always be someone disenfranchised.  The question is whether we
> should disenfranchise people who are very, very bad at software
> management, or disenfranchise people who want their software to work in a
> reasonable manner.
> 

I would just like to point out here that, contrary to your assertion to the
contrary, I do care about other people besides myself in this matter.

> 
> Show me where I "demonized" anyone.  I didn't imply people are stupid,
> the way some emails opposed to changing `rm` and `mv` have.  I didn't say
> people were morally reprehensible, acting maliciously to make others'
> lives difficult.  I just asked about whether the primary priority should
> be for people who don't care enough about their work to pay attention to
> their tools.
> 

It's very subtle, but it's there.  To quote, "someone who will never pay
attention to warnings".  Out of curiousity, how many warnings given by
software do *YOU* routinely ignore (e.g. web site security, etc)?

> 
> . . . except that, given your reactions to some of the other things I
> said, you seem inclined to take statements as insults when they obviously
> are not intended as insults, so the problem isn't really solved on your
> end.  Right?
> 

After having read several of your previous posts to others on this list,
including several containing insults, it seemed to be a fair assumption.

>
> That seems like another implementation detail.
>

I'm not sure how to respond to this.  Yes, changes to software do require
changing the implementation.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Sat, Dec 15, 2012 at 06:28:52PM -0800, Joe Mistachkin wrote:
> Jan Danielsson wrote:
> > 
> >   First, I feel you're inventing problems to make arguments in order to
> > exclude features which address real world issues. (A little like the
> > script issue brought up earlier).
> 
> Straw man argument.  Five yard penalty, still first down.

zsh: sports metaphor not found


> > 
> > Second (slightly off-topic), What's the problem with SSD and large
> > files? I have been using SLC SSD's since 2007, and since 2008 almost
> > exclusively mixed SLC and MLC SSD's on both servers and clients. On two
> > machines I regularly handle multi-GB files, and have not encountered any
> > issues which I haven't encountered with spinning-platter disks. I fail
> > to see why I would suddenly start having issues with large files because
> > I'm using fossil on SSD:s? (which, I'll admit, I have not).
> 
> The point here is wear-and-tear on the SSD, which have a finite limit of
> the number of bytes they can write during their useful lifetime.  Sorry
> if this point was not clear in my previous response.

HDDs also suffer wear and tear during I/O operations, and new SSDs easily
last long enough that, relative to HDDs, this should no longer be any
kind of problem.  In fact, the major problem is not that SSDs have a
limited number of writes; so do HDDs.  The "problem" is that you can know
in advance how many you have, while with HDDs it's a roll of the dice.


> > 
> >   There are lots of ways you can screw up, but the important thing is
> > that you can recover. I also think we have to assume that the normal
> > case is that people won't screw up, and assume that normally people
> > double check before they do something. (Wasn't that one of the insults
> > directed at those of us who want real mv/rm? That we just blindly do
> > things without thinking things through? Ironic twist (yes, I know you
> > weren't the one to say it, but someone else did)).
> 
> I just think there should be a clear division between Fossil commands
> that interact with the file system and those that do not.  I expect
> the "clean" and "revert" commands to deal with modifying files in the
> file system; however, I would not expect the "add", "mv", and "rm"
> commands to do that.

I think there should be a clear division, as well.  Those commands that
mimic the form of filesystem operations (e.g. `rm`) should, where at all
reasonable to do so, be on the filesystem interaction side of that
divide.  Those that do not (e.g. `delete`) can be on the other side of
it.


> > 
> >   Plus, if you know you're setting yourself up for such a situation,
> > then don't use the real rm; use the command which has retained the old
> > behavior ("unmanage", for instance).
> 
> Bike shedding.  The new command, say "realrm" (or whatever) could just
> as easily be made to perform the semantics you desire instead of breaking
> backward compatibility by modifying existing commands.

It's not just bikeshedding if it's a matter of actual tool usability.


> > 
> >   Yes. (I recommend you read through the threads; some of the issues
> > you raise have been discussed previously).
> 
> Frankly, I've been trying to avoid getting involved in this discussion
> at all.  If people really want "mv" and "rm" to perform file system
> operations, they can already:
> 
> 1. Write a wrapper script that performs the operations.

. . . which works great for new users!  Oh, wait, no it doesn't.


>
> 2. Customize their local Fossil binaries to include the necessary code.

. . . which perfectly solves the POLS problem for both new users and
people who have to interact with the rest of the world sometimes!  Oh,
wait, no it doesn't.


> 
> Also, I have read most of the messages in this thread; however, I think
> it may be next to impossible to read them all.  I do not even know how
> many messages there are in total.

I've read them all.  It was easy.


> > 
> > 
> > Stage 1:
> > (a) "fossil rm -f" deletes from disk (if it is safe to do so)
> > (b) "fossil rm" works as currently, but prints a warning message that it
> > will delete from disk in a future release.
> > (c) "fossil delete" works as currently
> > (d) "fossil unmanage" added as an alias for "fossil delete"
> > 
> > Stage 2 (after a stage 1 has been released for a while):
> > (e) "fossil rm" works just like "fossil rm -f"
> > 
> 
> I agree with (1a), (1c), and (1d).  I disagree with all the others,
> especially (2e).

. . . but not for any solid reasons I've seen.


> > 
> >   How come all these points you listed aren't issues with other source
> > management systems which have real rm/mv?
> 
> Frankly, I don't use the those other systems on a regular basis and I
> really do not care what they do.  Sorry.

Because *you* never really interact with the rest of the world, the fact
the rest of us do is irrelevant, I guess.  It's all about you.

Don't forget that there was a real question in that.  You c

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Sun, Dec 16, 2012 at 11:06:57AM -0500, daniel gregory wrote:
> 
> I think we should write a patch… publish is and see how many people
> actually use the patched version instead of the real version… then we'd
> have an argument against the conservatives that just don't like change.

That's not a bad idea, though I think it should be maintained alongside
the unpatched version with equal maintenance and availability for both.
Otherwise, it may be that almost nobody uses it.  I may not even use it,
preferring to script around the undesirable old behavior, if the
alternative is to have to patch it myself every time I upgrade or hunt
down some non-canonical location for downloads.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Sat, Dec 15, 2012 at 03:36:43PM -0800, Joe Mistachkin wrote:
> Chad Perrin wrote:
> > 
> > If you are not ready for changes in default behavior, don't upgrade to
> > the next major version number.  There is no good argument for software
> > defaults to be set in stone for all time.  Just use reasonable caution
> > when releasing changes to default behavior.
> 
> That is somewhat difficult in my case as I typically run trunk (or very
> close to it) to use the new/modified features I've been adding.

If you use bleeding edge versions, you should already be prepared to deal
with changes in behavior.  I don't see the problem.


> > 
> > It shouldn't be a surprise, as the migration is currently proposed,
> > unless all those users never upgrade Fossil SCM between now and the some-
> > future-time final change in functionality, thanks to the behavior
> > migration warnings and other indications (including, presumably, a major
> > version number change) that should apply along the way.
> 
> That is an exceptionally bad assumption.  We've had users that did
> not upgrade over a year.  Subsequently, they would sometimes notice a
> significant behavioral change and report it to us.  If "rm" suddenly
> started deleting files, I suspect that could induce panic, even if
> the action could be undone.

There will always be someone disenfranchised.  The question is whether we
should disenfranchise people who are very, very bad at software
management, or disenfranchise people who want their software to work in a
reasonable manner.


> > 
> > Should all software never ever break any backward compatibility ever,
> > just because something may be automated somewhere by someone who will
> > never pay attention to warnings given by the software itself or will
> > skip many intermediate versions before upgrading to a new, post-change
> > version?
> 
> Attempting to demonize people for relying on the current behavior
> seems to be in poor taste.

Show me where I "demonized" anyone.  I didn't imply people are stupid,
the way some emails opposed to changing `rm` and `mv` have.  I didn't say
people were morally reprehensible, acting maliciously to make others'
lives difficult.  I just asked about whether the primary priority should
be for people who don't care enough about their work to pay attention to
their tools.


> >
> > Should we always plan changes only for the sake of the most
> > irresponsible users?
> 
> Being openly hostile to users (i.e. by calling them "irresponsible")
> is also in poor taste.  Software that is openly hostile to its user
> base does not end up being too popular.  Finding examples of this is
> within the industry is left as an exercise for the reader.

I'm not calling users in general "irresponsible" -- only irresponsible
users.  There *are* irresponsible users in the world, just as there are
developmentally disabled people, stupid people, and actually *bad*
people.  Pretending there aren't such people doesn't change the facts,
and we should damned well be able to account for such people when making
policy.

I'm not even saying that all people who disagree with the need for a
change in default `rm` and `mv` behavior are irresponsible.  I'm just
pointing out that many of the problems raised are non-issues except to
irresponsible users, and saying that I think this is a bad prioritization
strategy.


> >
> > If to you it's perfectly reasonable to leave it as-is, we aren't
> > even speaking the same language.
> 
> I'm not sure if this is an attempt to insult me or not; however, I'll
> just assume that it is not.  Not changing something in an incompatible
> way is always a "reasonable" choice.  I think we'll have to agree to
> disagree on this.

It's not an attempt to insult you.  Problem solved.

. . . except that, given your reactions to some of the other things I
said, you seem inclined to take statements as insults when they obviously
are not intended as insults, so the problem isn't really solved on your
end.  Right?


> 
> There are several other problems with changing the current behavior:
> 
> 1.  The opposite of "add" is "remove".  The "add" command does not
> modify the file system.  It merely records something to be done
> for the next commit.  Similarly, the current "remove" command
> does this as well.

The opposite of "add" could be "delete" or "subtract" instead.  Notice
that the ideas of leaving "delete" as-is and/or adding a "remove" alias
for it have been raised, and that "rm" is not exactly the same as
"remove".  I think this point of yours does not exactly hold water.


> 
> 2.  If the "mv" and "rm" commands were to be changed to perform some
> action during commit, that would be very confusing as "commit"
> should only modify the repository.  On the other hand, if the
> "mv" and "rm" commands were to perform their file system actions
> prior to commit, would "revert" need to bring the previous files
> back to life?  That does not make sense.

This seems

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[daniel gregory]

Disclaimer:
1) I care nothing about backward compatibility.
2) I only care about the efficiency of tools that I use to help me do my job.



On Dec 15, 2012, at 11:02 PM, Jan Danielsson  wrote:

> On 12/16/12 03:28, Joe Mistachkin wrote:
>   Still, I think I'm right. I don't think any of the issues you've
> brought up as potential serious issues so far are actual problems. But I
> know for sure that the current mv/rm behavior is not what many people
> (who have voiced their opinion) expect, and I'm fairly certain that the
> change would overall be for the better.

As a new fossil user… I agree that the rm/mv is annoying.  I want the scm to 
help me do my job and not get in the way.  The repo is a way to save the state 
of my project, not the working directory is a way to manage my repo.   The 
current mv/rm supports the later mentality and I have to always do two 
operations in order to achieve anything which is a waste of my time.

>   Yes, but - as has been written so many times now that it's not even
> funny any longer: rm/mv has a canonical behavior, and new users continue
> to be surprised by the current behavior.

This is so true.

>> 1. Write a wrapper script that performs the operations.
>> 2. Customize their local Fossil binaries to include the necessary code.

Have already done 1 and I'm working on 2.  But why would I want to have to 
maintain this broken behavior.   It's a completely bad design and there is not 
one point in this thread that states why having the current functionality makes 
since.  You have to look at it from the end-users perspective, "I want to 
remove this file".   If it's already in the repo, then I can recover.  If not, 
it should say the file isn't under repo control.  If it's modified, maybe it 
should warn/prompt the user.


>   Or, we can change the behavior of mv/rm, implement the "unmanage" and
> corresponding "move" command. Two or three users will sulk for a week,
> get over it and then continue living on as nothing has happened. And all
> the new users who expect the canonical behavior of mv and rm will no
> longer need to be surprised.

this still wouldn't help with the principle of least surprise.  mv/rm are UNIX 
commands that have meaning… overloading them is retarded.

> 
>   We get the real rm/mv, the principle of least surprise for new users,
> a canonical behavior for mv/rm, and the old behavior (just under a new
> name). Everybody wins! (?)

I disagree… I want new names for the other things, not for something where I 
have to think "rm" in unix is this, but "rm" in fossil means this.

If you really didn't want to make changes on disk until commit then fine, I 
would agree on that, but then you have to maintain state in fossil (just like 
git does) until you do the commit.



I think we should write a patch… publish is and see how many people actually 
use the patched version instead of the real version… then we'd have an argument 
against the conservatives that just don't like change.


dan

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Jan Danielsson]

On 12/16/12 03:28, Joe Mistachkin wrote:
>>   First, I feel you're inventing problems to make arguments in order to
>> exclude features which address real world issues. (A little like the
>> script issue brought up earlier).
> Straw man argument.  Five yard penalty, still first down.

   Still, I think I'm right. I don't think any of the issues you've
brought up as potential serious issues so far are actual problems. But I
know for sure that the current mv/rm behavior is not what many people
(who have voiced their opinion) expect, and I'm fairly certain that the
change would overall be for the better.

>> Second (slightly off-topic), What's the problem with SSD and large
>> files? I have been using SLC SSD's since 2007, and since 2008 almost
>> exclusively mixed SLC and MLC SSD's on both servers and clients. On two
>> machines I regularly handle multi-GB files, and have not encountered any
>> issues which I haven't encountered with spinning-platter disks. I fail
>> to see why I would suddenly start having issues with large files because
>> I'm using fossil on SSD:s? (which, I'll admit, I have not).
> 
> The point here is wear-and-tear on the SSD, which have a finite limit of
> the number of bytes they can write during their useful lifetime.  Sorry
> if this point was not clear in my previous response.

   Oh, ok.

# atactl wd0 smart status
 id value thresh crit collect reliability description
  9 1000 no  online  positivePower-on hours count
28691
 12 1000 no  online  positiveDevice power cycle count   312
192 1000 no  online  positivePower-off retract count165
225 2000 no  offline positiveLoad/unload cycle count
227574
232 100   10 yes online  positiveUnknown0
233  990 no  online  positiveUnknown0

   ..and this is my second-most tortured drive. (An Intel-drive, in case
anyone wants to look up the Unknown id's).

   The wear and tear in this context is (another) completely bogus
argument. Unless one buys some broken-by-design drive (but again, one
can just as well do that with a spinning-platter disk, so there's still
no valid point).

>>   There are lots of ways you can screw up, but the important thing is
>> that you can recover. I also think we have to assume that the normal
>> case is that people won't screw up, and assume that normally people
>> double check before they do something. (Wasn't that one of the insults
>> directed at those of us who want real mv/rm? That we just blindly do
>> things without thinking things through? Ironic twist (yes, I know you
>> weren't the one to say it, but someone else did)).
> 
> I just think there should be a clear division between Fossil commands
> that interact with the file system and those that do not.  I expect
> the "clean" and "revert" commands to deal with modifying files in the
> file system; however, I would not expect the "add", "mv", and "rm"
> commands to do that.

   1) Fossil does file operations in the working directory regardless.
The working directory isn't equivalent to "the filesystem"; in abstract
terms, I see the working directory as the glue between the filesystem
and the repository. The working directory is special; it's a place where
fossil does its magic. I don't see why this needs to exclude mv and rm.
In fact, I would expect fossil to manage (including mv/rm) the files in
the working directory which are under version control.

   2) Even looking past #1; without some kind of relevant end-game, what
reason is there to have such a goal? I've only read "We need to separate
them, because we need to separate them" so far, but no one has explained
why it would be more important that The Principle of Least Surprise for
new users.

   3) There are other places in fossil which violate this "strict
separation" idea. I don't see any noise about them. Again, I think it's
a bogus argument from start, so I don't want any noise about any other
issues. I can appreciate abstract separations, but in this case I hardly
think it applies. Especially in the face of making fossil more intuitive
I think these made up separations are just nonsense.

>>   Plus, if you know you're setting yourself up for such a situation,
>> then don't use the real rm; use the command which has retained the old
>> behavior ("unmanage", for instance).
> Bike shedding.

   Oh, we reached that point 50 posts ago. :)

> The new command, say "realrm" (or whatever) could just
> as easily be made to perform the semantics you desire instead of breaking
> backward compatibility by modifying existing commands.

   Yes, but - as has been written so many times now that it's not even
funny any longer: rm/mv has a canonical behavior, and new users continue
to be surprised by the current behavior.

   We want to adjust rm/mv according to The Principle of Least Surprise.
I think the vast majority of fossil users will think "Oh, so they
changed it to what I first expecte

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Steve Havelka]

On 12/15/2012 06:28 PM, Joe Mistachkin wrote:
> Jan Danielsson wrote:
>>   First, I feel you're inventing problems to make arguments in order to
>> exclude features which address real world issues. (A little like the
>> script issue brought up earlier).
>>
> Straw man argument.  Five yard penalty, still first down.
>
>> Second (slightly off-topic), What's the problem with SSD and large
>> files? I have been using SLC SSD's since 2007, and since 2008 almost
>> exclusively mixed SLC and MLC SSD's on both servers and clients. On two
>> machines I regularly handle multi-GB files, and have not encountered any
>> issues which I haven't encountered with spinning-platter disks. I fail
>> to see why I would suddenly start having issues with large files because
>> I'm using fossil on SSD:s? (which, I'll admit, I have not).
>>
> The point here is wear-and-tear on the SSD, which have a finite limit of
> the number of bytes they can write during their useful lifetime.  Sorry
> if this point was not clear in my previous response.

So, you're saying that we wouldn't want to remove files from disk when
they're removed from the repository, because that action--which probably
wouldn't be a daily occurrence, and in my own personal use is a
once-every-week-or-so kind of thing--would be potentially bad for SSDs?

I'm sympathetic to the idea that software should be written with a
certain efficiency or hardware-awareness in mind, but this seems like a
bit of a stretch.



>
>>   ...and also, when you revert a deleted file, doesn't fossil need to
>> scan through the entire file to see if it has changed? If you revert a
>> multi-GB file, you'll still need to spend some time waiting for it, no?
>>
> I was not referring to the performance, see above.
>
>>   There are lots of ways you can screw up, but the important thing is
>> that you can recover. I also think we have to assume that the normal
>> case is that people won't screw up, and assume that normally people
>> double check before they do something. (Wasn't that one of the insults
>> directed at those of us who want real mv/rm? That we just blindly do
>> things without thinking things through? Ironic twist (yes, I know you
>> weren't the one to say it, but someone else did)).
>>
> I just think there should be a clear division between Fossil commands
> that interact with the file system and those that do not.  I expect
> the "clean" and "revert" commands to deal with modifying files in the
> file system; however, I would not expect the "add", "mv", and "rm"
> commands to do that.

Frankly speaking, I'd expect the opposite, but more than anything else
I'd expect that the documentation can tell me what commands do what. 
And, again, if the user issued the 'fossil rm' and it removed the file
from the repo and from disk, couldn't the user just pull it back out of
their last checkin, if for some reason they wanted to unmanage it but
retain it?

Or, put another way, how often have you wanted to delete a file from a
repo, but not delete it from disk?  Or move it within the repo, but not
wanted to move it on disk?  Is there any practical reason you're opposed
to this minor change in how the command works, or is it an adherence to
a principle of making as few incompatible changes as possible?








>
>>   Plus, if you know you're setting yourself up for such a situation,
>> then don't use the real rm; use the command which has retained the old
>> behavior ("unmanage", for instance).
>>
> Bike shedding.  The new command, say "realrm" (or whatever) could just
> as easily be made to perform the semantics you desire instead of breaking
> backward compatibility by modifying existing commands.
>
>>   Yes. (I recommend you read through the threads; some of the issues
>> you raise have been discussed previously).
>>
> Frankly, I've been trying to avoid getting involved in this discussion
> at all.  If people really want "mv" and "rm" to perform file system
> operations, they can already:
>
> 1. Write a wrapper script that performs the operations.
> 2. Customize their local Fossil binaries to include the necessary code.
>
> Also, I have read most of the messages in this thread; however, I think
> it may be next to impossible to read them all.  I do not even know how
> many messages there are in total.
>
>> 
>> Stage 1:
>> (a) "fossil rm -f" deletes from disk (if it is safe to do so)
>> (b) "fossil rm" works as currently, but prints a warning message that it
>> will delete from disk in a future release.
>> (c) "fossil delete" works as currently
>> (d) "fossil unmanage" added as an alias for "fossil delete"
>>
>> Stage 2 (after a stage 1 has been released for a while):
>> (e) "fossil rm" works just like "fossil rm -f"
>> 
>>
> I agree with (1a), (1c), and (1d).  I disagree with all the others,
> especially (2e).
>
>>   How come all these points you listed aren't issues with other source
>> management systems which have real rm/mv?
>>
> Frankly, I don't use

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Joe Mistachkin]

Jan Danielsson wrote:
> 
>   First, I feel you're inventing problems to make arguments in order to
> exclude features which address real world issues. (A little like the
> script issue brought up earlier).
> 

Straw man argument.  Five yard penalty, still first down.

> 
> Second (slightly off-topic), What's the problem with SSD and large
> files? I have been using SLC SSD's since 2007, and since 2008 almost
> exclusively mixed SLC and MLC SSD's on both servers and clients. On two
> machines I regularly handle multi-GB files, and have not encountered any
> issues which I haven't encountered with spinning-platter disks. I fail
> to see why I would suddenly start having issues with large files because
> I'm using fossil on SSD:s? (which, I'll admit, I have not).
> 

The point here is wear-and-tear on the SSD, which have a finite limit of
the number of bytes they can write during their useful lifetime.  Sorry
if this point was not clear in my previous response.

> 
>   ...and also, when you revert a deleted file, doesn't fossil need to
> scan through the entire file to see if it has changed? If you revert a
> multi-GB file, you'll still need to spend some time waiting for it, no?
> 

I was not referring to the performance, see above.

> 
>   There are lots of ways you can screw up, but the important thing is
> that you can recover. I also think we have to assume that the normal
> case is that people won't screw up, and assume that normally people
> double check before they do something. (Wasn't that one of the insults
> directed at those of us who want real mv/rm? That we just blindly do
> things without thinking things through? Ironic twist (yes, I know you
> weren't the one to say it, but someone else did)).
> 

I just think there should be a clear division between Fossil commands
that interact with the file system and those that do not.  I expect
the "clean" and "revert" commands to deal with modifying files in the
file system; however, I would not expect the "add", "mv", and "rm"
commands to do that.

> 
>   Plus, if you know you're setting yourself up for such a situation,
> then don't use the real rm; use the command which has retained the old
> behavior ("unmanage", for instance).
> 

Bike shedding.  The new command, say "realrm" (or whatever) could just
as easily be made to perform the semantics you desire instead of breaking
backward compatibility by modifying existing commands.

> 
>   Yes. (I recommend you read through the threads; some of the issues
> you raise have been discussed previously).
> 

Frankly, I've been trying to avoid getting involved in this discussion
at all.  If people really want "mv" and "rm" to perform file system
operations, they can already:

1. Write a wrapper script that performs the operations.
2. Customize their local Fossil binaries to include the necessary code.

Also, I have read most of the messages in this thread; however, I think
it may be next to impossible to read them all.  I do not even know how
many messages there are in total.

> 
> 
> Stage 1:
> (a) "fossil rm -f" deletes from disk (if it is safe to do so)
> (b) "fossil rm" works as currently, but prints a warning message that it
> will delete from disk in a future release.
> (c) "fossil delete" works as currently
> (d) "fossil unmanage" added as an alias for "fossil delete"
> 
> Stage 2 (after a stage 1 has been released for a while):
> (e) "fossil rm" works just like "fossil rm -f"
> 
> 

I agree with (1a), (1c), and (1d).  I disagree with all the others,
especially (2e).

> 
>   How come all these points you listed aren't issues with other source
> management systems which have real rm/mv?
> 

Frankly, I don't use the those other systems on a regular basis and I
really do not care what they do.  Sorry.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Jan Danielsson]

On 12/16/12 00:36, Joe Mistachkin wrote:
[---]
> 2.  [---] On the other hand, if the
> "mv" and "rm" commands were to perform their file system actions
> prior to commit, would "revert" need to bring the previous files
> back to life?  That does not make sense.

   Why not?

   $ fossil rm foo.txt
   foo.txt deleted from filesystem, and marked for removal in the
repository.
   ...ops, wrong file..
   $ fossil status
   foo.txt   DELETED
   $ fossil revert foo.txt
   ..brings back the file in the filesystem, and unmarks file for removal..

   Why doesn't that make sense?

> 3.  Related to the previous problem...  Think about very large files.
> If the "rm" command removes a very large file from the file system
> and later it needs to be restored, that is a whole lot of file I/O
> (potentially up to several GB).  This can be very hard on machines
> that are using SSD as their primary storage.

   First, I feel you're inventing problems to make arguments in order to
exclude features which address real world issues. (A little like the
script issue brought up earlier).

   Second (slightly off-topic), What's the problem with SSD and large
files? I have been using SLC SSD's since 2007, and since 2008 almost
exclusively mixed SLC and MLC SSD's on both servers and clients. On two
machines I regularly handle multi-GB files, and have not encountered any
issues which I haven't encountered with spinning-platter disks. I fail
to see why I would suddenly start having issues with large files because
I'm using fossil on SSD:s? (which, I'll admit, I have not).

   Anyway, even with the current behavior, one could "fossil rm" a few
GB-sized files, then remove the files from the filesystem, and later
realize one was in the wrong directory or something, so even with the
current situation one could end up needing to wait a while for a
reverted undelete.

   ...and also, when you revert a deleted file, doesn't fossil need to
scan through the entire file to see if it has changed? If you revert a
multi-GB file, you'll still need to spend some time waiting for it, no?

   There are lots of ways you can screw up, but the important thing is
that you can recover. I also think we have to assume that the normal
case is that people won't screw up, and assume that normally people
double check before they do something. (Wasn't that one of the insults
directed at those of us who want real mv/rm? That we just blindly do
things without thinking things through? Ironic twist (yes, I know you
weren't the one to say it, but someone else did)).

   Plus, if you know you're setting yourself up for such a situation,
then don't use the real rm; use the command which has retained the old
behavior ("unmanage", for instance).

   And finally, if you're worried about performance, try working with
the netbsd repository. IMHO, there are far more common everyday
optimizations which need to be done looong before we worry about the
odd "several GB data was deleted by mistake from a working tree.".

> 4.  What happens if a user tries to "rm" a file that does not exist in
> the repository?  Presumably, it would just issue an error message?

   Yes. (I recommend you read through the threads; some of the issues
you raise have been discussed previously).

> 5.  What happens if a user tries to "rm" a file that has been shunned
> at some point?

   What's the current behavior, and why would it need to differ?

> 6.  What happens if a user tries:  "fossil rm ." ?

   What happens them you type:
   $ rm .

   .. ?

   And what happens in other SCM's which support real rm?

> 7.  What happens if a user needs to add all files in the directory
> except for generated files (i.e. "fossil add .")?  After that
> point, normally *I* would "rm" the extra files; however, I do not
> want them deleted from the file system.

   You appear to be assuming that the suggestion is to change the
behavior of rm/mv and not retain the current behavior in any shape or
form. The suggestion which finally seemed to have pleased (mostly) both
sides was:


Stage 1:
(a) "fossil rm -f" deletes from disk (if it is safe to do so)
(b) "fossil rm" works as currently, but prints a warning message that it
will delete from disk in a future release.
(c) "fossil delete" works as currently
(d) "fossil unmanage" added as an alias for "fossil delete"

Stage 2 (after a stage 1 has been released for a while):
(e) "fossil rm" works just like "fossil rm -f"


   So, you'll be able to continue doing exactly what you are doing sans
s/rm/unmanage/. Everyone gets the behavior they want; others who
previously opposed real mv/rm seem to think that the latest suggestion
was a good compromise. For a brief moment, I thought that both sides
getting what they want would be the end of it..


   How come all these points you listed aren't issues with other source
management systems which have real rm/mv?

-- 
Kind regards,
Jan Daniels

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Joe Mistachkin]

Chad Perrin wrote:
> 
> If you are not ready for changes in default behavior, don't upgrade to
> the next major version number.  There is no good argument for software
> defaults to be set in stone for all time.  Just use reasonable caution
> when releasing changes to default behavior.
> 

That is somewhat difficult in my case as I typically run trunk (or very
close to it) to use the new/modified features I've been adding.

> 
> It shouldn't be a surprise, as the migration is currently proposed,
> unless all those users never upgrade Fossil SCM between now and the some-
> future-time final change in functionality, thanks to the behavior
> migration warnings and other indications (including, presumably, a major
> version number change) that should apply along the way.
> 

That is an exceptionally bad assumption.  We've had users that did
not upgrade over a year.  Subsequently, they would sometimes notice a
significant behavioral change and report it to us.  If "rm" suddenly
started deleting files, I suspect that could induce panic, even if
the action could be undone.

>
> .. . . most of which are not *bad* differences like this one.
>

Good and bad are very subjective, as this thread proves.

> 
> Should all software never ever break any backward compatibility ever,
> just because something may be automated somewhere by someone who will
> never pay attention to warnings given by the software itself or will
> skip many intermediate versions before upgrading to a new, post-change
> version?
>

Attempting to demonize people for relying on the current behavior
seems to be in poor taste.

>
> Should we always plan changes only for the sake of the most
> irresponsible users?
>

Being openly hostile to users (i.e. by calling them "irresponsible")
is also in poor taste.  Software that is openly hostile to its user
base does not end up being too popular.  Finding examples of this is
within the industry is left as an exercise for the reader.

>
> If to you it's perfectly reasonable to leave it as-is, we aren't
> even speaking the same language.
>

I'm not sure if this is an attempt to insult me or not; however, I'll
just assume that it is not.  Not changing something in an incompatible
way is always a "reasonable" choice.  I think we'll have to agree to
disagree on this.

There are several other problems with changing the current behavior:

1.  The opposite of "add" is "remove".  The "add" command does not
modify the file system.  It merely records something to be done
for the next commit.  Similarly, the current "remove" command
does this as well.

2.  If the "mv" and "rm" commands were to be changed to perform some
action during commit, that would be very confusing as "commit"
should only modify the repository.  On the other hand, if the
"mv" and "rm" commands were to perform their file system actions
prior to commit, would "revert" need to bring the previous files
back to life?  That does not make sense.

3.  Related to the previous problem...  Think about very large files.
If the "rm" command removes a very large file from the file system
and later it needs to be restored, that is a whole lot of file I/O
(potentially up to several GB).  This can be very hard on machines
that are using SSD as their primary storage.

4.  What happens if a user tries to "rm" a file that does not exist in
the repository?  Presumably, it would just issue an error message?

5.  What happens if a user tries to "rm" a file that has been shunned
at some point?

6.  What happens if a user tries:  "fossil rm ." ?

7.  What happens if a user needs to add all files in the directory
except for generated files (i.e. "fossil add .")?  After that
point, normally *I* would "rm" the extra files; however, I do not
want them deleted from the file system.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Sat, Dec 15, 2012 at 03:03:26AM -0800, Joe Mistachkin wrote:
> 
> j. v. d. hoff wrote:
> >
> > POLS comes again to mind.
> >
> 
> The Principle of Least Surprise is not static.  Changing the current
> behavior
> would be a huge (and potentially unpleasant) surprise for those who are very
> actively using Fossil now.

It shouldn't be a surprise, as the migration is currently proposed,
unless all those users never upgrade Fossil SCM between now and the some-
future-time final change in functionality, thanks to the behavior
migration warnings and other indications (including, presumably, a major
version number change) that should apply along the way.


> >
> > I can tell you that I _was_ surprised (being also a user of svn and
> > hg) when I installed fossil quickly read through the help ("ah yes,
> > ci, add, pull, push, rm, mv, stat, log -- default naming scheme for
> > default tasks"),
> 
> Of course, there are much bigger differences between Fossil and those other
> systems than the semantics of "mv" and "rm".

. . . most of which are not *bad* differences like this one.


> >
> > and I do not buy the "it'll be really dangerous for so many people"
> > prophecy.
> 
> Obviously, I do buy it.  Breaking compatibility is generally bad.  It's
> even worse when other _software_ (i.e. not humans) may depend on the
> current semantics.  The surface area of Fossil is the set of command
> line options it exposes, since it's a command line tool.  In this case,
> it would not be unlike changing the default behavior of the Unix "rm"
> command to implicitly include the "-f" option.

Should all software never ever break any backward compatibility ever,
just because something may be automated somewhere by someone who will
never pay attention to warnings given by the software itself or will skip
many intermediate versions before upgrading to a new, post-change
version?  Should we always plan changes only for the sake of the most
irresponsible users?

What are your criteria for allowing something to change?  What if all rm
did was give you a warning saying "You need to issue the command wakka_
wakka_dingbat_eliminate_this_file_from_the_repository because the rm
command is only a documentation helper!"?  Would you say we should never
change the behavior of rm and leave everyone stuck with wakka_wakka_
dingbat_eliminate_this_file_from_the_repository forever after to serve
the demands of backward compatibility?

If your answer is "No, of course not!  That's just silly!" then we've
reached a point of agreement where we have established that sometimes
breaking backward compatibility is a good idea.  All that remains at that
point is negotiating the specific cutoff point between "good idea" and
"bad idea".

If your answer is "Yes!" on the other hand, I think you and I have
absolutely zero common ground for discussion of the matter at all,
because wakka_wakka_dingbat_eliminate_this_file_from_the_repository with
the described `rm` behavior referring to it is intentionally meant to be
regarded as silly beyond reason.  If to you it's perfectly reasonable to
leave it as-is, we aren't even speaking the same language.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Fri, Dec 14, 2012 at 08:26:33PM -0800, Joe Mistachkin wrote:
> 
> My opinion is that backward compatibility should be retained because various
> people, including several that may not be involved in this discussion, have
> existing scripts and other automation that relies upon the current behavior.

Backward compatibility should be broken sometimes.  It is a decision that
should be undertaken only with great care, but it should sometimes be
undertaken.  That's an important part of how software improves over time.


> 
> Whether the current behavior being "ideal" or not is an entirely different
> debate.
> 
> My ideas on this issue are as follows:
> 
> 1. Retain the existing behavior for all current commands and aliases.
> It is far too dangerous to change the DEFAULT semantics of these
> commands now.

I disagree.  A careful, measured approach to changing default behavior
with a clear, unambiguous understanding of when and how things change
mitigates the potential for problems.  The major version number in
semantic versioning practice, in fact, exists specifically for the
purpose of indicating that backward compatbility has been broken.  Thus,
changes to default behavior that break backward compatibility should only
be released in major version number releases (and their release
candidates, if applicable), additions to the functionality of the
software without destructive changes should only be released on major and
minor version numbers, and fixes can be released on major, minor, or
revision version numbers.  This way, when you consider an upgrade, you
know what you're getting into just by looking at the number.

If you are not ready for changes in default behavior, don't upgrade to
the next major version number.  There is no good argument for software
defaults to be set in stone for all time.  Just use reasonable caution
when releasing changes to default behavior.


> 
> 2. Add entirely new commands named "relocate" (for mv) and "obliterate"
> (for rm) that will perform actions on the repository itself as well as
> the file system.

Apart from the fact that these terms are already used elsewhere with
distinctly different meanings (thus duplicating the problem that already
exists), it does not solve the problem that already exists.


> 
> 5. Optionally, add a -f/-filesystem option to the existing mv/rm
> commands if there is consensus on this point.  This new option will
> cause the exact same behavior as the new commands, including the errors
> as described above.

Honestly, if the repurposing of the rm and mv commands is not to happen
(though it should), this is the only suggestion that I think really makes
sense for the project.  A -f (--force, probably, rather than
--filesystem) is better than `relocate` and `obliterate` commands as you
have suggested, I think.  Of course, the problem of surprising behavior
for `rm` and `mv` would still apply in that case.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Steve Havelka]

On 12/15/2012 03:52 AM, Jan Danielsson wrote:
> On 12/15/12 05:26, Joe Mistachkin wrote:
>> My opinion is that backward compatibility should be retained because various
>> people, including several that may not be involved in this discussion, have
>> existing scripts and other automation that relies upon the current behavior.
>I'm going to speculate that this will affect very few users in the
> end (and that they'll survive the change without any problems). Do you
> actually know of any such cases; if so, would you care to explain the
> work-flow so we get a better understanding of how they are used (more
> importantly; so we understand how dangerous such a change would be)?
>
>In particular, with the proposed change there's no chance of loss of
> data as I see it. If the scripts fail, the data is still in the
> repository (again, no one is suggesting fossil blindly remove files).

Throughout all of this, I've been a little at a loss how data loss is
_ever_ possible with drh's proposed mechanism.

According to the latest proposal, the file will be removed from disk iff
it's removed from fossil AND is unchanged from its state in the last
checkin.

So...  the user has checked in this file.  It's managed.  It's in the
fossil repo.  They decide they don't want it, and fossil rm it.  Fossil
removes it from the checkin and from the disk...oh crud, they did want
it after all!  Well, it's still in the previous checkin, isn't it??

When is it _ever_ going to happen that the user's going to actually lose
data under this scenario?





>
>..while the proposed change will affect many users (in a positive way).
>
>(And yes, I do believe that numbers matter. Not entirely, but
> sufficiently in this case).
>
>> 1. Retain the existing behavior for all current commands and aliases.  It is
>>far too dangerous to change the DEFAULT semantics of these commands now.
>I don't agree.
>
>Of those I have introduced to fossil most of them have complained
> about the mv/rm command ("I think I've found a bug.."). One user in
> particular has never used SCM's before, so he had no preconceived ideas
> with regards to SCM's. I know how bad anecdotal evidence is in a
> "universal" discussion, but I firmly believe my friends and
> acquaintances are representative enough for me to make a somewhat valid
> extrapolation.
>
>If every user that I introduce to fossil who uses mv or rm comes to
> me and says they've found a bug, then I feel it's a problem in fossil,
> not the users.
>
>Not to mention the times it's been brought up on the mailing list and
> other Internet-forums.
>
>> 2. Add entirely new commands named "relocate" (for mv) and "obliterate" (for
>>rm) that will perform actions on the repository itself as well as the
>> file system.
>Obliterate has "shun" connotations for those who have used Perforce,
> If we go with different names, I would prefer another name for the commands.
>
>mv and rm are good, because they make sense in Unix.
>
>As a new user, I would have expected "relocate" and "obliterate" to
> be a database only operations. For me, then rather than two commands
> which has behavior which doesn't make sense, we'd have four.
>
>I vote no, and again reaffirm my vote for the suggestion drh wrote
> last night (local time).
>

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Sat, Dec 15, 2012 at 05:15:17PM +, Eric wrote:
> On Fri, 14 Dec 2012 20:46:22 -0700, Chad Perrin  wrote:
> 
> Why do people feel insulted when it is suggested that they don't know
> everything?
> 
> > I know what SCM is, you condescending ass.
> 
> I believe you, but there are some here who don't know, and the message
> is for everybody. And I did say "Well, I had to pick one message
> to answer". Instead of thinking "this bit isn't for me" you feel
> insulted and start being rude. Or rather, continue being rude. I do not
> understand this behaviour.

Your implication that anyone who disagrees with you must not know
anything implicitly includes me and everyone else here who disagrees with
you.  If you are not aware of this fact, I recommend you reread your
emails before sending next time.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Eric]

On Fri, 14 Dec 2012 20:46:22 -0700, Chad Perrin  wrote:

Why do people feel insulted when it is suggested that they don't know
everything?

> I know what SCM is, you condescending ass.

I believe you, but there are some here who don't know, and the message
is for everybody. And I did say "Well, I had to pick one message
to answer". Instead of thinking "this bit isn't for me" you feel
insulted and start being rude. Or rather, continue being rude. I do not
understand this behaviour.

Eric
-- 
ms fnd in a lbry
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Eric]

On Sat, 15 Dec 2012 01:52:11 +0100, Jan Danielsson  
wrote:
> On 12/15/12 01:06, Eric wrote:
> [---]
>> 4) I am not criticizing people, merely what they say. I see evidence
>> that they don't get where I'm coming from because they have only an
>> incomplete idea of what this is all about.
>> 
>> 5) SCM stands for Software Configuration Management which is not the
>> same thing as version control. Look it up. You will possibly hate it,
>> but if you ever write software that can affect real lives or large
>> amounts of money you will need to know about it.
> 
>So "SCM" defines how rm and mv should behave?

Oh for crying out loud! Of course it doesn't. That's the original subject
of this thread, and behind all the nonsense it's beginning to look like
there might be a sensible resolution. But there was so much nonsense here
before I ever posted in this thread that I felt the need to pick up on
all the things being claimed with no reason or an incorrect reason, so
many that a general statement seemed better than a whole lot of little
nit-picks which wouldn't make my real point anyway.

Get it? There is more than one topic of conversation here and, I'm
sorry, but you do seem to be wilfully misunderstanding this.

> And in order to take
> part of these definitions, to gain a "complete idea of what this is all
> about", one needs to write software which "affects real lives" or "large
> amounts of money"?
> 
>Well, I develop programs which *very* much can affect real lives, and
> large amounts of money is involved. No one has invited me to any secret
> organization where the *true* definition of "SCM" is revealed.

You have a VCS, and rules about when and if you can check in things
that won't build. You have rules about when you should branch and how
branches should be labelled. You have a proper change-management system
with adequate record-keeping. You have a test suite and can prove it's
coverage and that it has been used. You have a bug-tracking system. You
have proper backups and a disaster recovery plan for your _development_
systems. You can say how some part of your system behaved a year ago,
and how it behaves now, and why it is different, and if there is an
unauthorized difference you can find out who was responsible.

If not I don't want my real life or my real money anywhere near your
software!

SCM is not a religion or a secret as you seem to think I said, it is a
set of engineering and business disciplines to provide 
accountability, verifiability, traceability and control for the
development process.

Those who just want to use Fossil for their own development will not
want to know about any of that, and that's fine, but as far as I know
Fossil wants to be able to live in that sort of environment, so many of
the changes people want should not happen. So they do need to know that
there may be reasons beyond their current knowledge. The only
"stupidity" (and I did not use that word) is from those who do not
believe there is anything beyond their current knowledge, and who feel
insulted when told there is something they don't know.

>Sorry, but I think you're being silly. You don't know any more about
> these things than anyone else here.

Beg to differ, though not necessarily with respect to _everybody_ else.
(Not providing CV or references though).

> Calling you an ass was a little
> harsh, but at the same time, you are stating that others are inferior to
> you, yet you present nothing of substance to back it up. I understand
> why people are get a little annoyed.

But do you now understand why I am so exasperated?
> 
>You seem to be indicating that there's some exact definitions of an
> "SCM" which will resolve the rm/mv issue once and for all. Rather than
> to talk about affecting real lives and how much money is involved and
> other irrelevant nonsense, post those exact SCM definitions which are
> relevant to the mv/rm issues and we can judge that information directly.

Once again, that issue was only the trigger for a lot of (in my view)
nonsense and my reaction to it. And I am still exasperated!

Eric
-- 
ms fnd in a lbry
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Gour]

On Sat, 15 Dec 2012 12:52:34 +0100
Jan Danielsson
 wrote:

>Obliterate has "shun" connotations for those who have used
> Perforce, If we go with different names, I would prefer another name
> for the commands.

Similar here...I know 'obliterate' from darcs and the explanation is:

darcs obliterate - Obliterate completely removes recorded patches from
your local repository. The changes will be undone in your working copy
and the patches will not be shown in your changes list anymore. Beware
that you can lose precious code by obliterating!

>I vote no, and again reaffirm my vote for the suggestion drh wrote
> last night (local time).

I also stay behind my vote for changes proposed by Richard before
changing his mind.


Sincerely,
Gour

-- 
A self-realized man has no purpose to fulfill in the discharge 
of his prescribed duties, nor has he any reason not to perform 
such work. Nor has he any need to depend on any other living being.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Jan Danielsson]

On 12/15/12 11:24, j. v. d. hoff wrote:
[---]
> and I do not buy the "it'll be really dangerous for so many people" 
> prophecy. of course, if one really tries hard one can manage to get
> things messed up on disk (change lots of things in tracked files, but
> don't ever check in (clever) and then decide to stop tracking the files
> and issue 'fossil rm' assuming the files are left alone on disk and only
> then discover they were not). the transition period should guarantee
> that this will not evelove into a real-world problem I'd say.

   *nods in major agreement*

-- 
Kind regards,
Jan Danielsson

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Jan Danielsson]

On 12/15/12 05:26, Joe Mistachkin wrote:
> My opinion is that backward compatibility should be retained because various
> people, including several that may not be involved in this discussion, have
> existing scripts and other automation that relies upon the current behavior.

   I'm going to speculate that this will affect very few users in the
end (and that they'll survive the change without any problems). Do you
actually know of any such cases; if so, would you care to explain the
work-flow so we get a better understanding of how they are used (more
importantly; so we understand how dangerous such a change would be)?

   In particular, with the proposed change there's no chance of loss of
data as I see it. If the scripts fail, the data is still in the
repository (again, no one is suggesting fossil blindly remove files).

   ..while the proposed change will affect many users (in a positive way).

   (And yes, I do believe that numbers matter. Not entirely, but
sufficiently in this case).

> 1. Retain the existing behavior for all current commands and aliases.  It is
>far too dangerous to change the DEFAULT semantics of these commands now.

   I don't agree.

   Of those I have introduced to fossil most of them have complained
about the mv/rm command ("I think I've found a bug.."). One user in
particular has never used SCM's before, so he had no preconceived ideas
with regards to SCM's. I know how bad anecdotal evidence is in a
"universal" discussion, but I firmly believe my friends and
acquaintances are representative enough for me to make a somewhat valid
extrapolation.

   If every user that I introduce to fossil who uses mv or rm comes to
me and says they've found a bug, then I feel it's a problem in fossil,
not the users.

   Not to mention the times it's been brought up on the mailing list and
other Internet-forums.

> 2. Add entirely new commands named "relocate" (for mv) and "obliterate" (for
>rm) that will perform actions on the repository itself as well as the
> file system.

   Obliterate has "shun" connotations for those who have used Perforce,
If we go with different names, I would prefer another name for the commands.

   mv and rm are good, because they make sense in Unix.

   As a new user, I would have expected "relocate" and "obliterate" to
be a database only operations. For me, then rather than two commands
which has behavior which doesn't make sense, we'd have four.

   I vote no, and again reaffirm my vote for the suggestion drh wrote
last night (local time).

-- 
Kind regards,
Jan Danielsson

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[j. v. d. hoff]

On Sat, 15 Dec 2012 12:03:26 +0100, Joe Mistachkin   
wrote:




j. v. d. hoff wrote:


POLS comes again to mind.



The Principle of Least Surprise is not static.  Changing the current
behavior
would be a huge (and potentially unpleasant) surprise for those who are  
very

actively using Fossil now.



I can tell you that I _was_ surprised (being also a user of svn and hg)

when
I installed fossil quickly read through the help ("ah yes, ci, add,  
pull,

push, rm, mv, stat, log -- default naming scheme for default tasks"),



Of course, there are much bigger differences between Fossil and those  
other

systems than the semantics of "mv" and "rm".



and I do not buy the "it'll be really dangerous for so many people"
prophecy.



Obviously, I do buy it.  Breaking compatibility is generally bad.  It's  
even

worse when other _software_ (i.e. not humans) may depend on the current
semantics.  The surface area of Fossil is the set of command line


yes, "may" but no convincing scenarios are provided where it _does_ and in  
a way that would cause real grieve for many users. and we are still  
talking about defaults (= most sensible/suitable for most users) here, not  
about good vs. evil behaviour. I repeat that I support the recent proposal  
by richard to change the default as described.



options it
exposes, since it's a command line tool.  In this case, it would not be
unlike
changing the default behavior of the Unix "rm" command to implicitly  
include

the "-f" option.


_that_ is the default in unix (no questions asked). but it's aliased to  
`rm -i' for normal user accounts.





--
Joe Mistachkin

___
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

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Joe Mistachkin]

j. v. d. hoff wrote:
>
> POLS comes again to mind.
>

The Principle of Least Surprise is not static.  Changing the current
behavior
would be a huge (and potentially unpleasant) surprise for those who are very
actively using Fossil now.

>
> I can tell you that I _was_ surprised (being also a user of svn and hg)
when
> I installed fossil quickly read through the help ("ah yes, ci, add, pull,
> push, rm, mv, stat, log -- default naming scheme for default tasks"),
>

Of course, there are much bigger differences between Fossil and those other
systems than the semantics of "mv" and "rm".

>
> and I do not buy the "it'll be really dangerous for so many people"   
> prophecy.
>

Obviously, I do buy it.  Breaking compatibility is generally bad.  It's even
worse when other _software_ (i.e. not humans) may depend on the current
semantics.  The surface area of Fossil is the set of command line options it
exposes, since it's a command line tool.  In this case, it would not be
unlike
changing the default behavior of the Unix "rm" command to implicitly include
the "-f" option.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[j. v. d. hoff]

On Sat, 15 Dec 2012 10:56:20 +0100, Joe Mistachkin   
wrote:




j. v. d. hoff wrote:


I find this a confounding proposal.



Would you care to explain exactly what you find confounding about it?


has all been set way too often in this way too long thread:
POLS comes again to mind. I can tell you that I _was_ surprised (being  
also a user of svn and hg) when
I installed fossil quickly read through the help ("ah yes, ci, add, pull,  
push, rm, mv, stat, log -- default naming scheme for default tasks"),
started to use it and it turned out mv/rm did _not_ behave as usual (and  
for all the reasons stated over and over again: which would be more  
sensible).
by delegating the desired behaviour to `obliterate' or whatever and  
keeping rm as it is you guarantee that this will happen over and over again
to other people. why? for no good reason at all I can see. I'd bet that in  
this arena (recent users) lurks much more trouble by failing to meet
the usual (good, mind you) behaviour than by changing current defaults  
after a transition period.




It provides the requested functionality; however, it does so in a manner
that is respectful to those who are depending on the current


changing the default (including the transition period) is no sign of  
disrespect to anybody.



functionality.


and I do not buy the "it'll be really dangerous for so many people"   
prophecy. of course, if one really tries hard one can manage to get things  
messed up on disk (change lots of things in tracked files, but don't ever  
check in (clever) and then decide to stop tracking the files and issue  
'fossil rm' assuming the files are left alone on disk and only then  
discover they were not). the transition period should guarantee that this  
will not evelove into a real-world problem I'd say.


j.



--
Joe Mistachkin

___
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

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Joe Mistachkin]

j. v. d. hoff wrote:
>
> I find this a confounding proposal. 
>

Would you care to explain exactly what you find confounding about it?

It provides the requested functionality; however, it does so in a manner
that is respectful to those who are depending on the current functionality.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Joe Mistachkin]

Gour wrote:
>
> Does it imply that Fossil should not break backward comp. ever in
> order to evolve in certain design choices which were, as Richard
> himself stated "the use of text/x-fossil-wiki for comment and ticket 
> text was a mistake." ?
> 

In my opinion, breaking backward compatibility with a piece of software
that is widely deployed and that lots people depend on every single day
should never be taken lightly.

In this case, since Fossil is a command line tool, there are almost
certainly build scripts, graphical wrappers, continuous integration
systems, and other automation that would be potentially broken by such
a change.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[j. v. d. hoff]

On Sat, 15 Dec 2012 05:26:33 +0100, Joe Mistachkin   
wrote:




My opinion is that backward compatibility should be retained because  
various
people, including several that may not be involved in this discussion,  
have
existing scripts and other automation that relies upon the current  
behavior.


Whether the current behavior being "ideal" or not is an entirely  
different

debate.

My ideas on this issue are as follows:

1. Retain the existing behavior for all current commands and aliases.   
It is
   far too dangerous to change the DEFAULT semantics of these commands  
now.


2. Add entirely new commands named "relocate" (for mv) and "obliterate"  
(for

   rm) that will perform actions on the repository itself as well as the
file
   system.

3. For the new "relocate" command, it should raise an error if the
destination
   file name already exists on the file system or in the repository.

4. For the new "obliterate" command, it should raise an error if the file
has
   been changed in the current checkout.

5. Optionally, add a -f/-filesystem option to the existing mv/rm  
commands if
   there is consensus on this point.  This new option will cause the  
exact

   same behavior as the new commands, including the errors as described
above.

P.S. This message is not a reply to any given message on this thread, per
se.

If you disagree with my ideas, that's fine; however, please keep the
discussion
civil.

Thanks.


I find this a confounding proposal. the backward compatibility issue  
(given the proposed precautions,warnings, and length of phase out time)  
will I'm sure turn out to

be a none-issue in the end.

so "-1"

from my side




--
Joe Mistachkin

___
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

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Gour]

On Fri, 14 Dec 2012 20:26:33 -0800
"Joe Mistachkin"  wrote:

> 1. Retain the existing behavior for all current commands and
> aliases.  It is far too dangerous to change the DEFAULT semantics of
> these commands now.

Does it imply that Fossil should not break backward comp. ever in
order to evolve in certain design choices which were, as Richard
himself stated "the use of text/x-fossil-wiki for comment and ticket 
text was a mistake." ?


Sincerely,
Gour


-- 
Not by merely abstaining from work can one achieve freedom 
from reaction, nor by renunciation alone can one attain perfection.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Joe Mistachkin]

My opinion is that backward compatibility should be retained because various
people, including several that may not be involved in this discussion, have
existing scripts and other automation that relies upon the current behavior.

Whether the current behavior being "ideal" or not is an entirely different
debate.

My ideas on this issue are as follows:

1. Retain the existing behavior for all current commands and aliases.  It is
   far too dangerous to change the DEFAULT semantics of these commands now.

2. Add entirely new commands named "relocate" (for mv) and "obliterate" (for
   rm) that will perform actions on the repository itself as well as the
file
   system.

3. For the new "relocate" command, it should raise an error if the
destination
   file name already exists on the file system or in the repository.

4. For the new "obliterate" command, it should raise an error if the file
has
   been changed in the current checkout.

5. Optionally, add a -f/-filesystem option to the existing mv/rm commands if
   there is consensus on this point.  This new option will cause the exact
   same behavior as the new commands, including the errors as described
above.

P.S. This message is not a reply to any given message on this thread, per
se.

If you disagree with my ideas, that's fine; however, please keep the
discussion
civil.

Thanks.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Fri, Dec 14, 2012 at 08:46:22PM -0700, Chad Perrin wrote:
> On Sat, Dec 15, 2012 at 12:06:02AM +, Eric wrote:
> > 
> > 1) Telling the operating system to delete a file from disk and telling
> > the VCS that a file which is in the parent commit should not be in the
> > next are two very different actions and I think they should be kept
> > separate.
> 
> I'm perfectly fine with there being a way to keep the peformance of these
> tasks separate, and I doubt anyone else here has a problem with it
> either.  What people actually want is a POLS way to combine them.  The
> suggestion of moving current `rm` behavior to `remove`, and repurposing
> `rm`, seems like an excellent way to satisfy both needs.  I'd be just as
> happy with a command line option for the current behavior and the default
> being repurposed as proposed, though some people would evidently be
> miffed by that even if they insist everyone else use a command line
> option instead, so the command line option may be a suboptimal solution.

I just saw the reminder of the existence of the `delete` command, and if
I had thought of that before composing the quoted email I would have
suggested `delete` instead of `remove` here.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Sat, Dec 15, 2012 at 12:06:02AM +, Eric wrote:
> 
> 1) Telling the operating system to delete a file from disk and telling
> the VCS that a file which is in the parent commit should not be in the
> next are two very different actions and I think they should be kept
> separate.

I'm perfectly fine with there being a way to keep the peformance of these
tasks separate, and I doubt anyone else here has a problem with it
either.  What people actually want is a POLS way to combine them.  The
suggestion of moving current `rm` behavior to `remove`, and repurposing
`rm`, seems like an excellent way to satisfy both needs.  I'd be just as
happy with a command line option for the current behavior and the default
being repurposed as proposed, though some people would evidently be
miffed by that even if they insist everyone else use a command line
option instead, so the command line option may be a suboptimal solution.

Considering nobody's saying the two tasks you identify as distinct should
be inextricably linked for all cases renders your objection here entirely
irrelevant.


> 
> 2) In hindsight perhaps re-using the Unix/Linux command names wasn't
> such a good idea. Would this thread be so out of hand if it had always
> been "fossil remove"?

Probably not.  Then people would just want addition of an `rm` command
that does what people are now suggesting it should be repurposed to do.


> 
> 3) As time has passed I have felt less and less comfortable in this list
> because there are more and more contributors here who want changes I
> don't like without providing any real argument at all beyond that some
> other system does it. So I have introduced that more general issue into
> this thread with a very specific (though misleading) subject. Sorry but
> thread-drift is natural (and is the same thing as conversation-drift
> which has always happened). 

That's fine.  The problem is that there are actually substantive
arguments being made that you ignore, or to which your only retorts are
(perhaps thinly veiled) insults.


> 
> 4) I am not criticizing people, merely what they say. I see evidence
> that they don't get where I'm coming from because they have only an
> incomplete idea of what this is all about.

If you do not mean to insult people directly, you should phrase your
statements so that you do not make insulting statements.  Case in point:

. . . they have only an incomplete idea of what this is all about.

Yes, of course, that *must* be it.  It could not possibly be the case
that anyone who has different priorities than you has a meaningful case
for a given preference unless that person is an ignorant dolt.  Good work
on convincing us that you don't mean to insult anyone while in the same
breath implying that the *only* reason anyone disagrees with you is an
inability to understand the Sekrit Kno-ledge only the intellectual elite
such as yourself could ever comprehend.


> 
> 5) SCM stands for Software Configuration Management which is not the
> same thing as version control. Look it up. You will possibly hate it,
> but if you ever write software that can affect real lives or large
> amounts of money you will need to know about it.

I know what SCM is, you condescending ass.  This in no way changes
anyone's arguments for a change in the behavior of the version control
component of Fossil SCM.  Yes, there is indeed a version control
component -- an integral component of the whole SCM system.


> 
> Back to the email I am replying to...
> 
> On Fri, 14 Dec 2012 10:10:44 -0700, Chad Perrin  wrote:
> >
> > . . . and you're an ass.
> 
> Direct gratuitous insult. Well done.

Thank you.

Unlike yours, my insult was gratuitous.  Yours was the meat of your
argument.  As such, your argument (such as it was) had the unfortunate
character of being fallacious as well as rude.  Mine was merely rude, and
well deserved by the target.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Jan Danielsson]

On 12/15/12 01:06, Eric wrote:
[---]
> 4) I am not criticizing people, merely what they say. I see evidence
> that they don't get where I'm coming from because they have only an
> incomplete idea of what this is all about.
> 
> 5) SCM stands for Software Configuration Management which is not the
> same thing as version control. Look it up. You will possibly hate it,
> but if you ever write software that can affect real lives or large
> amounts of money you will need to know about it.

   So "SCM" defines how rm and mv should behave? And in order to take
part of these definitions, to gain a "complete idea of what this is all
about", one needs to write software which "affects real lives" or "large
amounts of money"?

   Well, I develop programs which *very* much can affect real lives, and
large amounts of money is involved. No one has invited me to any secret
organization where the *true* definition of "SCM" is revealed.


   Sorry, but I think you're being silly. You don't know any more about
these things than anyone else here. Calling you an ass was a little
harsh, but at the same time, you are stating that others are inferior to
you, yet you present nothing of substance to back it up. I understand
why people are get a little annoyed.

   You seem to be indicating that there's some exact definitions of an
"SCM" which will resolve the rm/mv issue once and for all. Rather than
to talk about affecting real lives and how much money is involved and
other irrelevant nonsense, post those exact SCM definitions which are
relevant to the mv/rm issues and we can judge that information directly.


-- 
Kind regards,
Jan Danielsson

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Eric]

On Fri, 14 Dec 2012 10:10:44 -0700, Chad Perrin  wrote:

Well, I had to pick one message to answer

Aaargh! (there should be more "a"s)

1) Telling the operating system to delete a file from disk and telling
the VCS that a file which is in the parent commit should not be in the
next are two very different actions and I think they should be kept
separate.

2) In hindsight perhaps re-using the Unix/Linux command names wasn't
such a good idea. Would this thread be so out of hand if it had always
been "fossil remove"?

3) As time has passed I have felt less and less comfortable in this list
because there are more and more contributors here who want changes I
don't like without providing any real argument at all beyond that some
other system does it. So I have introduced that more general issue into
this thread with a very specific (though misleading) subject. Sorry but
thread-drift is natural (and is the same thing as conversation-drift
which has always happened). 

4) I am not criticizing people, merely what they say. I see evidence
that they don't get where I'm coming from because they have only an
incomplete idea of what this is all about.

5) SCM stands for Software Configuration Management which is not the
same thing as version control. Look it up. You will possibly hate it,
but if you ever write software that can affect real lives or large
amounts of money you will need to know about it.

Back to the email I am replying to...

> I prefer a `fossil rm` command that removes from disk as well, but I do
> not fit the description

Quite possibly not, I wouldn't know at this point.

> your maliciously insulting description of the
> evils of such obviously inferior people.

You have managed to put more venom towards me in those few words than
there could ever have been in anything I said, and nothing I said was
directed at you explicitly anyway.

> . . . and you're an ass.

Direct gratuitous insult. Well done.

Eric
-- 
ms fnd in a lbry
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Martin Gagnon]

Le 2012-12-14 12:50, Matt Welland a écrit :


On Fri, Dec 14, 2012 at 10:32 AM, Chad Perrin mailto:c...@apotheon.net>> wrote:

On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote:
 >
 > This is the classical divide between pragmatists (I want to get
my job with
 > with minimal pain so I can go home a play ball with my son)
versus the
 > idealists (source code management means doing x, y and z and no
more and no
 > less and I'm sorry that it will take you twice as long to do your
job right
 > *grin*).
 >
 > Fossil is caught between the messy world of the pragmatists and
the nice
 > tidy world of the idealists. There is no one right way to do it.
One group
 > or the other will be disappointed.

I don't think that's all there is to it.  It isn't really fair to those
who prefer automation of the full set of rm tasks to suggest they
necessarily lack a sense of the idea, or to those who oppose that
automation to suggest they lack a sense of pragmatism.  I think that the
two sides of this discussion are more sophisticated and complex than
that, with several different types of argument being possible and
presented on each side.  The major argument types I have seen so far
are:

  for rm automation| against rm automation

--|--
  idealist (Unix way)  | idealists (airbags way)
  pragamtists (POLS way)   | pragmatists (backward compat)
  trolls (haven't noticed any) | trolls (NIH and "you're dumb")

If you know of any trollish argument forms on the pro-automation side,
please feel free to point them out.  I may be suffering some
confirmation
bias in this case.  Anyway, my explanations of the various arguments, as
I have noticed them, follow.

* Unix way idealists: When you tell it to do something, it damned well
   does it.

* airbags way idealists: When you tell it to do something that might be
   accidentally applied in an unintentionally destructive manner by an
   incautious user, it should second-guess your intentions and try to
   convince you to do things differently, on the assumption that is not
   what you wanted.

* POLS pragmatists: When you issue a command that seems like it should
   perform a given task, you expect it to perform the whole task,
and not
   only part of it.  Tool design should account for that.

* backward compat pragmatists: This is how it has been done so far,
   establishing a set of expectations particular to long-time users and
   the automation scripts they have written that rely on the behavior in
   question.  We should not change the tool's behavior to violate those
   ingrained expectations because there may be backward incompatibility
   problems.

* NIH trolls: You're trying to turn Fossil into Git!  Stop it!

* "you're dumb" trolls: Obviously you are all too stupid to understand
   the benefits of keeping things the way they are.  You are wrong
because
   you are stupid; you are stupid because you disagree with me.

If we could eliminate those "troll" category participants in the
discussion, I think we would get a lot further in sorting this out.


Nice analysis Chad!

My sincere apologies to anyone insulted by my overly simplistic and
arguably unfair comment :)

I still want one of these two:

Preferred behavior: remove file silently from disk iff the file is
controlled and unchanged or if forced with -f. Issue a warning if the
file was not removed.


+2


Also works for me: don't remove files unless forced with -f. With force
all removals on disk happen without any notice.


+1

--
Martin G.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Matt Welland]

On Fri, Dec 14, 2012 at 10:32 AM, Chad Perrin  wrote:

> On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote:
> >
> > This is the classical divide between pragmatists (I want to get my job
> with
> > with minimal pain so I can go home a play ball with my son) versus the
> > idealists (source code management means doing x, y and z and no more and
> no
> > less and I'm sorry that it will take you twice as long to do your job
> right
> > *grin*).
> >
> > Fossil is caught between the messy world of the pragmatists and the nice
> > tidy world of the idealists. There is no one right way to do it. One
> group
> > or the other will be disappointed.
>
> I don't think that's all there is to it.  It isn't really fair to those
> who prefer automation of the full set of rm tasks to suggest they
> necessarily lack a sense of the idea, or to those who oppose that
> automation to suggest they lack a sense of pragmatism.  I think that the
> two sides of this discussion are more sophisticated and complex than
> that, with several different types of argument being possible and
> presented on each side.  The major argument types I have seen so far are:
>
>  for rm automation| against rm automation
> --|--
>  idealist (Unix way)  | idealists (airbags way)
>  pragamtists (POLS way)   | pragmatists (backward compat)
>  trolls (haven't noticed any) | trolls (NIH and "you're dumb")
>
> If you know of any trollish argument forms on the pro-automation side,
> please feel free to point them out.  I may be suffering some confirmation
> bias in this case.  Anyway, my explanations of the various arguments, as
> I have noticed them, follow.
>
> * Unix way idealists: When you tell it to do something, it damned well
>   does it.
>
> * airbags way idealists: When you tell it to do something that might be
>   accidentally applied in an unintentionally destructive manner by an
>   incautious user, it should second-guess your intentions and try to
>   convince you to do things differently, on the assumption that is not
>   what you wanted.
>
> * POLS pragmatists: When you issue a command that seems like it should
>   perform a given task, you expect it to perform the whole task, and not
>   only part of it.  Tool design should account for that.
>
> * backward compat pragmatists: This is how it has been done so far,
>   establishing a set of expectations particular to long-time users and
>   the automation scripts they have written that rely on the behavior in
>   question.  We should not change the tool's behavior to violate those
>   ingrained expectations because there may be backward incompatibility
>   problems.
>
> * NIH trolls: You're trying to turn Fossil into Git!  Stop it!
>
> * "you're dumb" trolls: Obviously you are all too stupid to understand
>   the benefits of keeping things the way they are.  You are wrong because
>   you are stupid; you are stupid because you disagree with me.
>
> If we could eliminate those "troll" category participants in the
> discussion, I think we would get a lot further in sorting this out.
>

Nice analysis Chad!

My sincere apologies to anyone insulted by my overly simplistic and
arguably unfair comment :)

I still want one of these two:

Preferred behavior: remove file silently from disk iff the file is
controlled and unchanged or if forced with -f. Issue a warning if the file
was not removed.

Also works for me: don't remove files unless forced with -f. With force all
removals on disk happen without any notice.

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Nolan Darilek]

Here's a thought:

Let's remove the rm alias and make it just "fossil remove". That will 
eliminate all my objections.


When I issue a "rm", whether at my shell, or in hg, git, svn, everywhere 
else but CVS apparently, which is the reason for establishing this 
expectation, it behaves a certain way.


Forget VCSs for a minute. When I issue "rm" on every Unix implementation 
on the planet, the file is removed from disk. Unix does not have a 
"remove" command about which I have expectations.


So let's just ditch "fossil rm" entirely so that expectation is broken? 
Then when someone asks for rm to be aliased, we explain that there is a 
dissonance between how Fossil and just about everything else handles rm, 
so the non-standard behavior is called "remove" and nothing more?


I have no issues with "fossil remove" not removing the file from the 
filesystem, but I will probably almost always hit this "fossil rm" 
dissonance.


And thus the bikeshed is painted.


On 12/14/2012 11:32 AM, Chad Perrin wrote:

On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote:

This is the classical divide between pragmatists (I want to get my job with
with minimal pain so I can go home a play ball with my son) versus the
idealists (source code management means doing x, y and z and no more and no
less and I'm sorry that it will take you twice as long to do your job right
*grin*).

Fossil is caught between the messy world of the pragmatists and the nice
tidy world of the idealists. There is no one right way to do it. One group
or the other will be disappointed.

I don't think that's all there is to it.  It isn't really fair to those
who prefer automation of the full set of rm tasks to suggest they
necessarily lack a sense of the idea, or to those who oppose that
automation to suggest they lack a sense of pragmatism.  I think that the
two sides of this discussion are more sophisticated and complex than
that, with several different types of argument being possible and
presented on each side.  The major argument types I have seen so far are:

  for rm automation| against rm automation
 --|--
  idealist (Unix way)  | idealists (airbags way)
  pragamtists (POLS way)   | pragmatists (backward compat)
  trolls (haven't noticed any) | trolls (NIH and "you're dumb")

If you know of any trollish argument forms on the pro-automation side,
please feel free to point them out.  I may be suffering some confirmation
bias in this case.  Anyway, my explanations of the various arguments, as
I have noticed them, follow.

* Unix way idealists: When you tell it to do something, it damned well
   does it.

* airbags way idealists: When you tell it to do something that might be
   accidentally applied in an unintentionally destructive manner by an
   incautious user, it should second-guess your intentions and try to
   convince you to do things differently, on the assumption that is not
   what you wanted.

* POLS pragmatists: When you issue a command that seems like it should
   perform a given task, you expect it to perform the whole task, and not
   only part of it.  Tool design should account for that.

* backward compat pragmatists: This is how it has been done so far,
   establishing a set of expectations particular to long-time users and
   the automation scripts they have written that rely on the behavior in
   question.  We should not change the tool's behavior to violate those
   ingrained expectations because there may be backward incompatibility
   problems.

* NIH trolls: You're trying to turn Fossil into Git!  Stop it!

* "you're dumb" trolls: Obviously you are all too stupid to understand
   the benefits of keeping things the way they are.  You are wrong because
   you are stupid; you are stupid because you disagree with me.

If we could eliminate those "troll" category participants in the
discussion, I think we would get a lot further in sorting this out.



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote:
> 
> This is the classical divide between pragmatists (I want to get my job with
> with minimal pain so I can go home a play ball with my son) versus the
> idealists (source code management means doing x, y and z and no more and no
> less and I'm sorry that it will take you twice as long to do your job right
> *grin*).
> 
> Fossil is caught between the messy world of the pragmatists and the nice
> tidy world of the idealists. There is no one right way to do it. One group
> or the other will be disappointed.

I don't think that's all there is to it.  It isn't really fair to those
who prefer automation of the full set of rm tasks to suggest they
necessarily lack a sense of the idea, or to those who oppose that
automation to suggest they lack a sense of pragmatism.  I think that the
two sides of this discussion are more sophisticated and complex than
that, with several different types of argument being possible and
presented on each side.  The major argument types I have seen so far are:

 for rm automation| against rm automation
--|--
 idealist (Unix way)  | idealists (airbags way)
 pragamtists (POLS way)   | pragmatists (backward compat)
 trolls (haven't noticed any) | trolls (NIH and "you're dumb")

If you know of any trollish argument forms on the pro-automation side,
please feel free to point them out.  I may be suffering some confirmation
bias in this case.  Anyway, my explanations of the various arguments, as
I have noticed them, follow.

* Unix way idealists: When you tell it to do something, it damned well
  does it.

* airbags way idealists: When you tell it to do something that might be
  accidentally applied in an unintentionally destructive manner by an
  incautious user, it should second-guess your intentions and try to
  convince you to do things differently, on the assumption that is not
  what you wanted.

* POLS pragmatists: When you issue a command that seems like it should
  perform a given task, you expect it to perform the whole task, and not
  only part of it.  Tool design should account for that.

* backward compat pragmatists: This is how it has been done so far,
  establishing a set of expectations particular to long-time users and
  the automation scripts they have written that rely on the behavior in
  question.  We should not change the tool's behavior to violate those
  ingrained expectations because there may be backward incompatibility
  problems.

* NIH trolls: You're trying to turn Fossil into Git!  Stop it!

* "you're dumb" trolls: Obviously you are all too stupid to understand
  the benefits of keeping things the way they are.  You are wrong because
  you are stupid; you are stupid because you disagree with me.

If we could eliminate those "troll" category participants in the
discussion, I think we would get a lot further in sorting this out.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Thu, Dec 13, 2012 at 11:08:04PM +, Eric wrote:
> On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu"  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.
> 
> On another note, people are saying things like "there is a certain
> behaviour that is expected" without saying why it is expected. The main
> reasons seem to be that other VCS's do it and that it saves time. The
> first is irrelevant and the second, in my opinion, a case of people
> knowing the price of everything and the value of nothing.
> 
> I think this thread has served to highlight the number of people here
> who want Fossil to be something other that what it set out to be, and
> don't actually know what SCM means. It doesn't surprise me that they
> have caused some over-the-top reactions.

I review changes before committing, and I don't just treat a VCS as a
backup method.  I also believe default behavior should be for an `rm`
command to do what it says on the tin, in the most convenient and
unsurprising manner possible, because computers and the software running
on them are supposed to automate away the mind-numbing drudgery of a
rigid series of steps that must be taken regularly to achieve common,
conceptually simple tasks -- not add redundancy to the actions that must
be taken to maintain workflow.

I prefer a `fossil rm` command that removes from disk as well, but I do
not fit the description your maliciously insulting description of the
evils of such obviously inferior people.

. . . and you're an ass.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[David Given]

Richard Hipp wrote:
[...]
> 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?

Yes, please. (Particularly with fossil mv; refactoring large numbers of
files becomes annoyingly fiddly without it.)

> 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?

I think this is also a good idea.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "There is nothing in the world so dangerous --- and I mean *nothing*
│ --- as a children's story that happens to be true." --- Master Li Kao,
│ _The Bridge of Birds_



signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Pierpaolo Bernardi]

On Fri, Dec 14, 2012 at 12:23 AM, Richard Hipp  wrote:

> 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".

I'm happy to read this. Thank you.

I had refrained to chime in the discussion so far, because I was not
sure about how to articulate my point of view.

Now I think the point is, it is good practice that processes
responsible for creating/opening/locking a resource must be the same
responsible for deleting/closing/unlocking them.

If I manually create a file, it must be me to manually delete it when
I don't need it anymore. It must not be deleted as a side effect of
some other thing.  And no, saving a few keystrokes does not balance
this.

Cheers
P.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Gour]

On Fri, 14 Dec 2012 10:55:50 +0100
Jan Danielsson
 wrote:

>I must say, I'm not quite as fond of the fossil community as I once
> was. I have no interest in being insulted further.

That's pity that immature people are chasing away older members. :-(


Sincerely,
Gour

-- 
Thus the wise living entity's pure consciousness becomes covered by 
his eternal enemy in the form of lust, which is never satisfied and 
which burns like fire.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Jan Danielsson]

On 12/14/12 00:56, Nolan Darilek wrote:
> Who would have guessed that something as simple as having rm remove the
> file from disk would prompt opponents to:
> 
>  * claim that I want Fossil to be like Git.
>  * Call me "lazy."
>  * Insult my intelligence by claiming that I don't know what a VCS is or
> should do.
> 
> Done with this thread. Keep it classy, detractors.

   100% agree.

   I must say, I'm not quite as fond of the fossil community as I once
was. I have no interest in being insulted further.

-- 
Kind regards,
Jan Danielsson

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Jan Danielsson]

On 12/14/12 00:23, Richard Hipp wrote:
> But, should there be an opt-in option to also make the disk changes?

   Yes -- definitely.

-- 
Kind regards,
Jan Danielsson

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Ramon Ribó]

> 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.


With all sincerity I fail to see why this is well put.

That paragraph is basically criticizing the rest of the people that is
not using an VCS in the same way that the poster likes to use. Why is
it not correct to commit often? Why is it an advantage to always make
a deep review of what is going to be commited? Why the timeline needs
to be pretty and delicately handmade? In my opinion a VCS can be used
in many different ways depending on the type of application, size of
the dev team, company policies, etc. Trying to enforce one of these
ways of working is just plain reductionism.

At the end we are discussing something very simple: Which default
usage is more convenient for most users? Once one default is selected,
are we causing a great pain to the non favoured users?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Matt Welland]

On Thu, Dec 13, 2012 at 4:48 PM, j. v. d. hoff wrote:

> On Fri, 14 Dec 2012 00:23:12 +0100, Richard Hipp  wrote:
>
>  On Thu, Dec 13, 2012 at 6:08 PM, Eric  wrote:
>>
>>  On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu" 
>>> 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).
>

This is the classical divide between pragmatists (I want to get my job with
with minimal pain so I can go home a play ball with my son) versus the
idealists (source code management means doing x, y and z and no more and no
less and I'm sorry that it will take you twice as long to do your job right
*grin*).

Fossil is caught between the messy world of the pragmatists and the nice
tidy world of the idealists. There is no one right way to do it. One group
or the other will be disappointed.

When I saw that fossil was leaning more towards the idealistic side I
created my fsl wrapper to make fossil workable in a real-world arena.
Without my wrapper fossil would be unusable in our team.

Maybe it is time for a more robust, written in C or similar, wrapper that
adapts fossil for the pragmatists allowing the idealists to have their
pristine usage model.

Is this something that could be formally architected to be part of the
fossil project? Basically it would be one tool with two faces. It is just a
thought.

My wrapper needs some work (I never did finish off the -r and -f for rm)
but it works well enough for now. You can get it at
https://chiselapp.com/user/kiatoa/repository/fsl/index and I very much
welcome suggestions for improvement. Keep in mind that it is intended to
make life easy for those on large teams working with large numbers of
fossils (we have over two hundred fossils in use right now) in a pure Unix
environment.


> 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-

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Nolan Darilek]

Who would have guessed that something as simple as having rm remove the 
file from disk would prompt opponents to:


 * claim that I want Fossil to be like Git.
 * Call me "lazy."
 * Insult my intelligence by claiming that I don't know what a VCS is 
or should do.


Done with this thread. Keep it classy, detractors.


On 12/13/2012 05:08 PM, Eric wrote:

On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu"  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.

On another note, people are saying things like "there is a certain
behaviour that is expected" without saying why it is expected. The main
reasons seem to be that other VCS's do it and that it saves time. The
first is irrelevant and the second, in my opinion, a case of people
knowing the price of everything and the value of nothing.

I think this thread has served to highlight the number of people here
who want Fossil to be something other that what it set out to be, and
don't actually know what SCM means. It doesn't surprise me that they
have caused some over-the-top reactions.

Eric


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[j. v. d. hoff]

On Fri, 14 Dec 2012 00:23:12 +0100, Richard Hipp  wrote:


On Thu, Dec 13, 2012 at 6:08 PM, Eric  wrote:


On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu" 
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

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Joan Picanyol i Puig]

* Richard Hipp  [20121213 16:37]:
 
> My current leanings are to change "rm" and "mv" as follows:

[...]
 
> It seems to me that the behaviors above are the most "intuitive" and
> provide developers with the least amount of surprise.

I agree.

Regarding your later post, I fail to see how this proposed behaviour
encourages VCS-as-backup sloppiness.

qvb
-- 
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[j. v. d. hoff]

On Fri, 14 Dec 2012 00:08:04 +0100, Eric  wrote:

On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu"   
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.

On another note, people are saying things like "there is a certain
behaviour that is expected" without saying why it is expected. The main
reasons seem to be that other VCS's do it and that it saves time. The
first is irrelevant and the second, in my opinion, a case of people
knowing the price of everything and the value of nothing.

I think this thread has served to highlight the number of people here
who want Fossil to be something other that what it set out to be, and


richard might decide that one, right? and even if it were true that this  
discussion revolves about the issue of morphing fossil into something  
else, which it is not, it could - theoretically - be a development in the  
right direction presuming that the initial design (goal) was not perfect  
in the strict sense of the word (which simply never can be the case in  
this world). but all this is 100% relevant to the point at hand.



don't actually know what SCM means. It doesn't surprise me that they


sure. dummies all of them.


have caused some over-the-top reactions.


altogether I see your mail as another (logical) non sequitur.

j.



Eric



--
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

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Richard Hipp]

On Thu, Dec 13, 2012 at 6:08 PM, Eric  wrote:

> On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu" 
> 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.

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?


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Eric]

On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu"  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.

On another note, people are saying things like "there is a certain
behaviour that is expected" without saying why it is expected. The main
reasons seem to be that other VCS's do it and that it saves time. The
first is irrelevant and the second, in my opinion, a case of people
knowing the price of everything and the value of nothing.

I think this thread has served to highlight the number of people here
who want Fossil to be something other that what it set out to be, and
don't actually know what SCM means. It doesn't surprise me that they
have caused some over-the-top reactions.

Eric
-- 
ms fnd in a lbry
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Steve Havelka]

On 12/13/2012 07:38 AM, Richard Hipp wrote:
> FWIW, I am following this thread with great interest.  I think I
> understand the various points of view.  I think most everybody brings
> up good points, and I encourage this kind of discussion. 
>
> My current leanings are to change "rm" and "mv" as follows:

I like these proposed changes.  I don't think I've ever done one rm/mv
without the other (i.e. rm in fossil without also rm'ing on disk), so
this'd save me some steps and typing 100% of the time.

thanks, Richard!






> (1) "fossil rm xyx.txt" will remove the file xyz.txt from disk if and
> only if an exact copy of xyz.txt exists under control.  If xyz.txt has
> been modified or if xyz.txt has never been checked in (and the "fossil
> rm" is simply to reverse a prior "fossil add") then xyz.txt is
> unchanged.  Either way, there are probably no error or warning
> messages, though I am sympathetic to the argument that there should be
> a warning message if the file is not deleted from disk.
>
> (2) "fossil mv abc.txt xyz.txt" will rename abc.txt to xyz.txt on disk
> provided that xyz.txt does not previously exist on disk or if xyz.txt
> does already exist and its content is identical to abc.txt.  If
> xyz.txt does previously exist and is different from abc.txt (and hence
> would be overwritten) then the operation just fails out-right with an
> appropriate error message.
>
> It seems to me that the behaviors above are the most "intuitive" and
> provide developers with the least amount of surprise.  The goal of
> Fossil (as it should be for any VCS) is to get out of the developer's
> way and just "do the right thing", so that the developer can devote
> maximum brain-power to working on their application, and expend a
> minimum number of brain-cycles thinking about Fossil and how to
> control it.  And I think the behaviors outlined above probably best
> achieve this goal.
>
> But I am far from certain of that, so please do continue debating the
> issue.  We want to get this right. 
>
> -- 
> D. Richard Hipp
> d...@sqlite.org 
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Altu Faltu]

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.

 IMO, as somebody else suggested in the thread, let fossil do rm or mv only in 
version control.

 In order to satisfy need of fossil users asking for changes in file system, I 
suggest an option -f be given, which acts as suggested in your mail. With this 
option if fossil decides not to rm or mv any file in file system, it should 
print reason for deciding so.

- Original Message -
From: Richard Hipp
Sent: 12/13/12 09:08 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] why does `fossil rm' not do the "real" thing?

 FWIW, I am following this thread with great interest. I think I understand the 
various points of view. I think most everybody brings up good points, and I 
encourage this kind of discussion. 

 My current leanings are to change "rm" and "mv" as follows:

 (1) "fossil rm xyx.txt" will remove the file xyz.txt from disk if and only if 
an exact copy of xyz.txt exists under control. If xyz.txt has been modified or 
if xyz.txt has never been checked in (and the "fossil rm" is simply to reverse 
a prior "fossil add") then xyz.txt is unchanged. Either way, there are probably 
no error or warning messages, though I am sympathetic to the argument that 
there should be a warning message if the file is not deleted from disk.

 (2) "fossil mv abc.txt xyz.txt" will rename abc.txt to xyz.txt on disk 
provided that xyz.txt does not previously exist on disk or if xyz.txt does 
already exist and its content is identical to abc.txt. If xyz.txt does 
previously exist and is different from abc.txt (and hence would be overwritten) 
then the operation just fails out-right with an appropriate error message.

 It seems to me that the behaviors above are the most "intuitive" and provide 
developers with the least amount of surprise. The goal of Fossil (as it should 
be for any VCS) is to get out of the developer's way and just "do the right 
thing", so that the developer can devote maximum brain-power to working on 
their application, and expend a minimum number of brain-cycles thinking about 
Fossil and how to control it. And I think the behaviors outlined above probably 
best achieve this goal.

 But I am far from certain of that, so please do continue debating the issue. 
We want to get this right. 

 --
 D. Richard Hipp
 d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Juanma Barranquero]

On Thu, Dec 13, 2012 at 6:13 PM, Nolan Darilek  wrote:

> You don't get to reframe this discussion by
> putting everyone who asks for a change in the same category. Sorry, I won't
> let you do that. Me asking for rm behavior today does not mean I'll ask for
> rebase tomorrow, nor does it mean that someone who does has *anything to do*
> with requesting a certain rm behavior today.

Moreover, asking for changes and improvements shouldn't be taboo, even
if these proposed changes are inspired by other (perhaps worse) tools.
Ultimately, it is up to the maintainers to weed out the proposals,
rejecting these who don't match the vision and perhaps adopting (and
adapting) others that can be useful. This kind of discussion, while
civilized, can only be good.

   J
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[j. van den hoff]

On Thu, 13 Dec 2012 18:02:25 +0100, Marcelo  wrote:


2012/12/13 Nolan Darilek 


On 12/13/2012 08:40 AM, Marcelo wrote:


They want the good things about fossil but they want to keep working as
if it were Git. I say, if they like Git so much, eat the crow that  
comes

with it.

And that doesn't even make sense, either. If I wanted Git, then I'd use

Git, full stop. It's silly telling me that changing this rm behavior is
suddenly going to make Fossil so like Git that I'm all like "Oh, great,  
now
I've succeeded in my nefarious mission of making everything Git-like!  
Mine

is an EVIL laugh! Next I'll ask for rebase!"



You may laugh at the image of the cackling, moustache twirling villain --
after all, I've used the image myself in hyperbole. But what you're
deliberate neglecting is that rebase *has been requested already*, even
when it goes against all what Fossil stands for. Not so silly any more,  
it

seems.




Making this sort of argument damages the cause because it puts those of  
us
advocating for a thing in a position we aren't necessarily in, so it  
makes

us want to just let the point go. I don't want Fossil to be another Git,
but by telling me that I do, I'm suddenly either compelled to stop
advocating for *any* change that violates Least Surprise. And hell, my
example didn't even *use* Git's behavior to justify my claims and I'm
*still* being told that OMG I want to make Fossil like teh gits! I  
respect
the "Fossil should be conservative" arguments even though I disagree  
with

them, but I'm going to call this exaggeration and hyperbole out on the
carpet.

Go ahead, call it whatever tickles your fancy. I'm not adverse to use

exaggeration and hyperbole to make a point, and I accept I did. So what?


it's annoying/exhausting. that's what.


I
don't think is a bad think to counter somewhat the impulse of advocating
the full Git command line experience in Fossil just for the same of the
muscle memory of some repentant Git users.


really: why not stop this nonsense/aggressiveness? nobody needs this  
(yourself included I presume)




Is fair to notice that the rm/mv issue is the one I have *less*  
objections

about. Is the full cloning of command line options of other systems


fine. that's what we are talking about.


what's
grating at my teeth right now. That and the advocacy for a rebase-like
feature as The Only Right Way To Work With Source Code.


I don't miss rebase right now (and yes: that feature exists out there in  
the wild (git, mercurial, probably others).
personally, though, I find it rather easy to ignore unwanted  
features/commands. and I _know_ there are projects
making good use of rebase without saying that other roads to not lead to  
Rome, too. you need not use it if you don't like
it. it's not an evil feature per se. but again: I don't care for it,  
currently.


j.






--
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

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Nolan Darilek]

On 12/13/2012 11:02 AM, Marcelo wrote:
You may laugh at the image of the cackling, moustache twirling villain 
-- after all, I've used the image myself in hyperbole. But what you're 
deliberate neglecting is that rebase *has been requested already*, 
even when it goes against all what Fossil stands for. Not so silly any 
more, it seems.





But it's still happening. You don't get to reframe this discussion by 
putting everyone who asks for a change in the same category. Sorry, I 
won't let you do that. Me asking for rm behavior today does not mean 
I'll ask for rebase tomorrow, nor does it mean that someone who does has 
*anything to do* with requesting a certain rm behavior today.


And just to be clear, I dislike rebase. Were I to jump ship to another 
VCS, it'd be Mercurial because it supports a very Fossil-like view of 
history. I used to like Git's "everything but the kitchen sink" approach 
until I came to Fossil, and now I don't.


Let's use a bit of hyperbole of my own. Should companies/projects like 
Google, Apple, Microsoft, GNOME, KDE and Mozilla abandon their adoption 
of some sort of human interface guidelines? These companies and projects 
manage to produce vastly different experiences, despite the fact that 
Ctrl-C, Ctrl-V, Ctrl-X and Ctrl-Z do vastly similar things across them 
all. Saying that GNOME or KDE is suddenly going to be like OS X or 
Windows 8 because it uses the same key commands doesn't make sense, and 
I think it'd be exaggeration to accuse GNOME or Mozilla of heading down 
the path of Windows were it not to have these keyboard shortcuts and 
suddenly choose to adopt them.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Marcelo]

2012/12/13 Nolan Darilek 

> On 12/13/2012 08:40 AM, Marcelo wrote:
>
>> They want the good things about fossil but they want to keep working as
>> if it were Git. I say, if they like Git so much, eat the crow that comes
>> with it.
>>
>> And that doesn't even make sense, either. If I wanted Git, then I'd use
> Git, full stop. It's silly telling me that changing this rm behavior is
> suddenly going to make Fossil so like Git that I'm all like "Oh, great, now
> I've succeeded in my nefarious mission of making everything Git-like! Mine
> is an EVIL laugh! Next I'll ask for rebase!"
>

You may laugh at the image of the cackling, moustache twirling villain --
after all, I've used the image myself in hyperbole. But what you're
deliberate neglecting is that rebase *has been requested already*, even
when it goes against all what Fossil stands for. Not so silly any more, it
seems.


>
> Making this sort of argument damages the cause because it puts those of us
> advocating for a thing in a position we aren't necessarily in, so it makes
> us want to just let the point go. I don't want Fossil to be another Git,
> but by telling me that I do, I'm suddenly either compelled to stop
> advocating for *any* change that violates Least Surprise. And hell, my
> example didn't even *use* Git's behavior to justify my claims and I'm
> *still* being told that OMG I want to make Fossil like teh gits! I respect
> the "Fossil should be conservative" arguments even though I disagree with
> them, but I'm going to call this exaggeration and hyperbole out on the
> carpet.
>
> Go ahead, call it whatever tickles your fancy. I'm not adverse to use
exaggeration and hyperbole to make a point, and I accept I did. So what? I
don't think is a bad think to counter somewhat the impulse of advocating
the full Git command line experience in Fossil just for the same of the
muscle memory of some repentant Git users.

Is fair to notice that the rm/mv issue is the one I have *less* objections
about. Is the full cloning of command line options of other systems what's
grating at my teeth right now. That and the advocacy for a rebase-like
feature as The Only Right Way To Work With Source Code.

-- 
   o-=< Marcelo >=-o
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Ramon Ribó]

> (1) "fossil rm xyx.txt" will remove the file xyz.txt from disk if and only
> if an exact copy of xyz.txt exists under control.  If xyz.txt has been
> modified or if xyz.txt has never been checked in (and the "fossil rm" is
> simply to reverse a prior "fossil add") then xyz.txt is unchanged.  Either
> way, there are probably no error or warning messages, though I am
> sympathetic to the argument that there should be a warning message if the
> file is not deleted from disk.

I think that there should be a warning message


> (2) "fossil mv abc.txt xyz.txt" will rename abc.txt to xyz.txt on disk
> provided that xyz.txt does not previously exist on disk or if xyz.txt does
> already exist and its content is identical to abc.txt.  If xyz.txt does
> previously exist and is different from abc.txt (and hence would be
> overwritten) then the operation just fails out-right with an appropriate
> error message.

You should define clearly what to do in case xyz.txt directory does not exist
or is not writable.

  if it is not writable, just fail and error message

  if the directory does not exist:

  a) the simple one, give and error

  b) Try to create the directories too


2012/12/13 Richard Hipp :
> FWIW, I am following this thread with great interest.  I think I understand
> the various points of view.  I think most everybody brings up good points,
> and I encourage this kind of discussion.
>
> My current leanings are to change "rm" and "mv" as follows:
>
> (1) "fossil rm xyx.txt" will remove the file xyz.txt from disk if and only
> if an exact copy of xyz.txt exists under control.  If xyz.txt has been
> modified or if xyz.txt has never been checked in (and the "fossil rm" is
> simply to reverse a prior "fossil add") then xyz.txt is unchanged.  Either
> way, there are probably no error or warning messages, though I am
> sympathetic to the argument that there should be a warning message if the
> file is not deleted from disk.
>
> (2) "fossil mv abc.txt xyz.txt" will rename abc.txt to xyz.txt on disk
> provided that xyz.txt does not previously exist on disk or if xyz.txt does
> already exist and its content is identical to abc.txt.  If xyz.txt does
> previously exist and is different from abc.txt (and hence would be
> overwritten) then the operation just fails out-right with an appropriate
> error message.
>
> It seems to me that the behaviors above are the most "intuitive" and provide
> developers with the least amount of surprise.  The goal of Fossil (as it
> should be for any VCS) is to get out of the developer's way and just "do the
> right thing", so that the developer can devote maximum brain-power to
> working on their application, and expend a minimum number of brain-cycles
> thinking about Fossil and how to control it.  And I think the behaviors
> outlined above probably best achieve this goal.
>
> But I am far from certain of that, so please do continue debating the issue.
> We want to get this right.
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Gour]

On Thu, 13 Dec 2012 10:38:36 -0500
Richard Hipp  wrote:

> (1) "fossil rm xyx.txt" will remove the file xyz.txt from disk if and
> only if an exact copy of xyz.txt exists under control.  If xyz.txt
> has been modified or if xyz.txt has never been checked in (and the
> "fossil rm" is simply to reverse a prior "fossil add") then xyz.txt
> is unchanged.  Either way, there are probably no error or warning
> messages, though I am sympathetic to the argument that there should
> be a warning message if the file is not deleted from disk.

I'm for warning that nothing was deleted.

> (2) "fossil mv abc.txt xyz.txt" will rename abc.txt to xyz.txt on disk
> provided that xyz.txt does not previously exist on disk or if xyz.txt
> does already exist and its content is identical to abc.txt.  If
> xyz.txt does previously exist and is different from abc.txt (and
> hence would be overwritten) then the operation just fails out-right
> with an appropriate error message.

Great.


Sincerely,
Gour

-- 
>From anger, complete delusion arises, and from delusion 
bewilderment of memory. When memory is bewildered, 
intelligence is lost, and when intelligence is lost 
one falls down again into the material pool.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Richard Hipp]

FWIW, I am following this thread with great interest.  I think I understand
the various points of view.  I think most everybody brings up good points,
and I encourage this kind of discussion.

My current leanings are to change "rm" and "mv" as follows:

(1) "fossil rm xyx.txt" will remove the file xyz.txt from disk if and only
if an exact copy of xyz.txt exists under control.  If xyz.txt has been
modified or if xyz.txt has never been checked in (and the "fossil rm" is
simply to reverse a prior "fossil add") then xyz.txt is unchanged.  Either
way, there are probably no error or warning messages, though I am
sympathetic to the argument that there should be a warning message if the
file is not deleted from disk.

(2) "fossil mv abc.txt xyz.txt" will rename abc.txt to xyz.txt on disk
provided that xyz.txt does not previously exist on disk or if xyz.txt does
already exist and its content is identical to abc.txt.  If xyz.txt does
previously exist and is different from abc.txt (and hence would be
overwritten) then the operation just fails out-right with an appropriate
error message.

It seems to me that the behaviors above are the most "intuitive" and
provide developers with the least amount of surprise.  The goal of Fossil
(as it should be for any VCS) is to get out of the developer's way and just
"do the right thing", so that the developer can devote maximum brain-power
to working on their application, and expend a minimum number of
brain-cycles thinking about Fossil and how to control it.  And I think the
behaviors outlined above probably best achieve this goal.

But I am far from certain of that, so please do continue debating the
issue.  We want to get this right.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Gour]

On Thu, 13 Dec 2012 08:54:25 -0600
Nolan Darilek  wrote:
 
> Making this sort of argument damages the cause because it puts those
> of us advocating for a thing in a position we aren't necessarily in,
> so it makes us want to just let the point go. 

Fortunately, Richard is mature person...


Sincerely,
Gour

-- 
Whatever action a great man performs, common men follow. And 
whatever standards he sets by exemplary acts, all the world pursues.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Nolan Darilek]

On 12/13/2012 08:40 AM, Marcelo wrote:
They want the good things about fossil but they want to keep working 
as if it were Git. I say, if they like Git so much, eat the crow that 
comes with it.






And that doesn't even make sense, either. If I wanted Git, then I'd use 
Git, full stop. It's silly telling me that changing this rm behavior is 
suddenly going to make Fossil so like Git that I'm all like "Oh, great, 
now I've succeeded in my nefarious mission of making everything 
Git-like! Mine is an EVIL laugh! Next I'll ask for rebase!"


Making this sort of argument damages the cause because it puts those of 
us advocating for a thing in a position we aren't necessarily in, so it 
makes us want to just let the point go. I don't want Fossil to be 
another Git, but by telling me that I do, I'm suddenly either compelled 
to stop advocating for *any* change that violates Least Surprise. And 
hell, my example didn't even *use* Git's behavior to justify my claims 
and I'm *still* being told that OMG I want to make Fossil like teh gits! 
I respect the "Fossil should be conservative" arguments even though I 
disagree with them, but I'm going to call this exaggeration and 
hyperbole out on the carpet.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Marcelo]

2012/12/13 Jan Danielsson 

> "Richie Adler" (that is, myself, not Themba Fletcher) wrote:
> >>> What's next? Replacing SQLite with individual files?
> >>
> >> Absolutely not, and statements like this do more harm than good because
> they
> >> willfully disregard the point of what is being expressed. The point is
> not
> >> to be alarmist and extreme, as statements like the above are. The point
> is
> >> to establish that there is a certain behavior that is expected, and
> Fossil
> >> does not exemplify that.
> >
> > Sure. But without fossil's deviation from the norm what possible
> > reason would I have to choose it over mercurial or git?
>
> I don't see changing the current rm/mv behavior as removing a selling
> point of fossil (and frankly speaking, I'm quite surprised to see that
> it's being treated as such).


In my particular case, is not. It's the recent flurry of requests to
"git-ify" Fossil what's incensing me. That's why I used hyperbole regarding
the SQLite
They want the good things about fossil but they want to keep working as if
it were Git. I say, if they like Git so much, eat the crow that comes with
it.

-- 
   o-=< Marcelo >=-o
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Jan Danielsson]

On 12/13/12 05:01, Themba Fletcher wrote:
>>> What's next? Replacing SQLite with individual files?
>>
>> Absolutely not, and statements like this do more harm than good because they
>> willfully disregard the point of what is being expressed. The point is not
>> to be alarmist and extreme, as statements like the above are. The point is
>> to establish that there is a certain behavior that is expected, and Fossil
>> does not exemplify that.
> 
> Sure. But without fossil's deviation from the norm what possible
> reason would I have to choose it over mercurial or git?

   I recall a discussion about implementing a "? :"-operator in a non-C
language a few years back. Some simply suggested "why not use '? :'?",
and some developers said "That's C -- we're not C". So someone posted a
convoluted syntax which it seemed like almost everyone hated, but the
"hard core" users said it was ok, "because it wasn't C".

   I don't want decisions about fossil to be made on that basis. "If we
change this behavior to the better, we'll become more like others, so we
can't have it.". Being different isn't of any value if the difference
doesn't imply improvement (in the case of mv/rm I think fossil's
behavior is inferior to others).

   Extrapolating "make rm and mv behave main-stream" to "we'll become
just like mercurial or git" seems to be a little of a stretch to me. I
have zero objections to becoming "main stream" with regards to certain
features if it means becoming better.


   Some of the reasons I use fossil are: I trust SQLite, SSL, I like
that it uses HTTP as its clone-protocol, the REMOTE_USER feature, I like
the web-ui (with all its features), I like the command line ui (mostly),
I like the strict DAG property of the repository, the built in wiki,
ticket system, user administration, etc.

   The fact that I have to perform two operations for something which
should only require one is _not_ a reason for me to chose fossil over
any other system. But more to the point: Even if I saw any value in the
separation, such a feature would still not be a reason for me to chose
fossil over any other system. It would have exactly zero bearing.

   I don't see changing the current rm/mv behavior as removing a selling
point of fossil (and frankly speaking, I'm quite surprised to see that
it's being treated as such). I see it more limiting the number of
replies to the question "Ok, so you've brought up the pros with fossil.
Could mention some of the cons?". I don't think there are many
annoyances with fossil, so the mv/rm behavior is a relatively minor
issue in the grand scheme of things, but still -- could we make it do
all of the work, not just half of it, I would be pleased and have one
less "con" in my list.

-- 
Kind regards,
Jan Danielsson

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[j. van den hoff]

On Thu, 13 Dec 2012 14:09:46 +0100, Jan Danielsson  
 wrote:



On 12/13/12 05:07, Carson Chittom wrote:

Nolan Darilek  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
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Jan Danielsson]

On 12/13/12 00:51, Themba Fletcher wrote:
> I'd like to return to what I think should be the focus, which is
> discussing what the "right thing" is for fossil to do. As a possible
> compromise, the combination of a '-f' flag to fossil rm with the
> ability to add aliases (mentioned as a possible feature by Richard
> recently in another thread if I'm not mistaken) could solve this
> completely. The default could remain as is, safe and conservative,

   Could someone explain where the idea of added "safety" with the
current behavior is? (I believe someone wrote an example a while back,
but I don't remember what is was, and I can't find it again).

   As I stated in another mail, I have on a few occasion lost track of
what operations I have performed due to fossil not immediately changing
the working directory to reflect the changes I've requested. I see the
current behavior as explicitly unsafe for that exact reason.

   Plus, no one is expecting rm to blindly remove files. To quote Martin
Gagnon:


[---] I would expect:

  fossil rm , to remove the file on checkout if the file is in
  sync with the repository, but command to fail if the file is locally
  modified.  In the case where the user really want to delete change
  that never get committed, he can use: fossil rm -f 

That way, there's no danger of accidental data lost. If you call
"fossil rm" by mistake, file can be retrieve from previous version on
the repository.


   What's "unsafe" with that behavior compared to the behavior we have
today?


-- 
Kind regards,
Jan Danielsson

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Jan Danielsson]

On 12/13/12 05:07, Carson Chittom wrote:
> Nolan Darilek  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).

-- 
Kind regards,
Jan Danielsson

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Mike Meyer]

On 12/12/12, Themba Fletcher  wrote:
> to alias 'fossil rm' to 'fossil rm -f'.

That is a disaster waiting to happen. If the user in question forgets
that they've done that, and then runs a series of commands from
someone who *didn't* do that (either cut-n-paste from an answer on the
list or the web, as part of a script for doing something, or
whatever), they'll wind up removing files that nobody wanted removed.

An alias mechanism is fine, but it really shouldn't let users change
the behavior of builtin commands. Either aliases should have to have
different names, or be invoked by some other mechanism. Both of those
sort of defeat the purpose of the rm alias, though.

   http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[j. v. d. hoff]

On Thu, 13 Dec 2012 10:58:29 +0100, Gour  wrote:


On Thu, 13 Dec 2012 06:49:08 -0300
Richie Adler  wrote:


Can you please killfile me and leave me alone?


That's not the point 'cause your comments are not polite and
disturbing to other Fossil users as you can see...


+1




Sincerely,
Gour





--
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

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[j. v. d. hoff]

On Thu, 13 Dec 2012 08:16:48 +0100, Gour  wrote:


On Wed, 12 Dec 2012 23:42:29 -0300
Richie Adler 
wrote:


Sorry, I still think that the intention is to destroy what Fossil has
of unique to offer to be able to say that Git or Mercurial it's the
same and they should be preferred to Fossil.

What's next? Replacing SQLite with individual files?


Can you please change your mantra labelling every constructive attempt
to change something in Fossil as conspiracy by Git advocates.



+1


Thank you.


Sincerely,
Gour




--
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

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Gour]

On Thu, 13 Dec 2012 06:49:08 -0300
Richie Adler  wrote:

> Can you please killfile me and leave me alone?

That's not the point 'cause your comments are not polite and
disturbing to other Fossil users as you can see...


Sincerely,
Gour 


-- 
A person is said to be elevated in yoga when, having renounced 
all material desires, he neither acts for sense gratification 
nor engages in fruitive activities.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Carson Chittom]

Nolan Darilek  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?  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.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Gour]

On Wed, 12 Dec 2012 23:42:29 -0300
Richie Adler 
wrote:

> Sorry, I still think that the intention is to destroy what Fossil has
> of unique to offer to be able to say that Git or Mercurial it's the
> same and they should be preferred to Fossil.
> 
> What's next? Replacing SQLite with individual files?

Can you please change your mantra labelling every constructive attempt
to change something in Fossil as conspiracy by Git advocates.

Thank you.


Sincerely,
Gour 

-- 
As a strong wind sweeps away a boat on the water, 
even one of the roaming senses on which the mind 
focuses can carry away a man's intelligence.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Nolan Darilek]

On 12/12/2012 08:42 PM, Richie Adler wrote:
What's next? Replacing SQLite with individual files? 



Absolutely not, and statements like this do more harm than good because 
they willfully disregard the point of what is being expressed. The point 
is not to be alarmist and extreme, as statements like the above are. The 
point is to establish that there is a certain behavior that is expected, 
and Fossil does not exemplify that. Saying "next you'll want to change 
the file format" is silly, because expectations about a thing like file 
format are *nowhere near the same category* as something like what rm 
should do.


In day to day operation, I care nothing about the file format. I care a 
whole lot more about whether or not I have to perform several operations 
to remove a file, when Fossil as a tool could make that work easier for 
me and not sacrifice data as several posters have already noted.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Richie Adler]

Nolan Darilek decía, en el mensaje "Re: [fossil-users] why does `fossil rm'
not do the "real" thing?" del Miércoles, 12 de Diciembre de 2012 22:38:16:

> Naysayers aren't trying to make Fossil Git, we're just trying to make it 
> do what most other VCSs do in these areas.

Sorry, I still think that the intention is to destroy what Fossil has of
unique to offer to be able to say that Git or Mercurial it's the same and they
should be preferred to Fossil.

What's next? Replacing SQLite with individual files?

-- 

   o-=< Marcelo >=-o

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Nolan Darilek]

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.



On 12/12/2012 05:38 PM, Juanma Barranquero wrote:

On Thu, Dec 13, 2012 at 12:13 AM, Chad Perrin  wrote:


Screw that.  Git makes exactly the kind of UI mistakes I'm talking about
eliminating.

Well, one thing that I don't know whether to call "UI mistake", but it
is certainly an inconvenience, is that to obtain accurate status
information (similar to git status, bzr status, etc.) you must do

   fossil status   ; or fossil changes
   fossil extras --dotfiles


   J
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Themba Fletcher]

On Wed, Dec 12, 2012 at 3:13 PM, Chad Perrin  wrote:
> On Wed, Dec 12, 2012 at 03:07:51PM -0800, Themba Fletcher wrote:
>> On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler  wrote:
>> > If that happens, please make sure to include "git" in the new name. That's
>> > what all the naysayers are trying to convert Fossil into, anyway.
>>
>> +1 :)
>
> Screw that.  Git makes exactly the kind of UI mistakes I'm talking about
> eliminating.

Sorry for the hasty and flippant reply -- poor judgement on my part
given the passion involved in this discussion.

It seems to all boil down to what's a sane default and how liberal
fossil should be about removing a file from the disk. I obviously
prefer the current, conservative, behavior, and it's one of fossil's
selling points as far as I'm concerned. This discussion has devolved
somewhat into a comparison with other systems and speculation about
user growth if fossil fails to conform, which I think may be getting
somewhat counterproductive.

I'd like to return to what I think should be the focus, which is
discussing what the "right thing" is for fossil to do. As a possible
compromise, the combination of a '-f' flag to fossil rm with the
ability to add aliases (mentioned as a possible feature by Richard
recently in another thread if I'm not mistaken) could solve this
completely. The default could remain as is, safe and conservative, and
the only downside would be the necessity of communicating the option
to new users to alias 'fossil rm' to 'fossil rm -f'. I'll of course
even volunteer to write the FAQ entry if this becomes a reality (since
I don't really have any place mucking about with fossil's internals).

Again, my apologies for adding noise earlier to an important discussion.

>
> --
> Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Juanma Barranquero]

On Thu, Dec 13, 2012 at 12:13 AM, Chad Perrin  wrote:

> Screw that.  Git makes exactly the kind of UI mistakes I'm talking about
> eliminating.

Well, one thing that I don't know whether to call "UI mistake", but it
is certainly an inconvenience, is that to obtain accurate status
information (similar to git status, bzr status, etc.) you must do

  fossil status   ; or fossil changes
  fossil extras --dotfiles


  J
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Wed, Dec 12, 2012 at 03:07:51PM -0800, Themba Fletcher wrote:
> On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler  wrote:
> > If that happens, please make sure to include "git" in the new name. That's
> > what all the naysayers are trying to convert Fossil into, anyway.
> 
> +1 :)

Screw that.  Git makes exactly the kind of UI mistakes I'm talking about
eliminating.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Themba Fletcher]

On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler  wrote:
> If that happens, please make sure to include "git" in the new name. That's
> what all the naysayers are trying to convert Fossil into, anyway.

+1 :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Richie Adler]

Chad Perrin decía, en el mensaje "Re: [fossil-users] why does `fossil rm' not
do the "real" thing?" del Miércoles, 12 de Diciembre de 2012 18:22:53:

> I rather suspect that, if Fossil continues to grow in usage over time,
> and if it fails to implement sane defaults and options like what you just
> described as a general policy, there will probably be either a fork or a
> wrapper that arrives to "solve" the problem.

If that happens, please make sure to include "git" in the new name. That's
what all the naysayers are trying to convert Fossil into, anyway.

-- 

   o-=< Marcelo >=-o

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Wed, Dec 12, 2012 at 08:28:55AM -0500, Martin Gagnon wrote:
> Le 2012-12-12 06:28, Ramon Ribó a écrit :
> >
> >  As I understand it, fossil currently deletes one file from disk when
> >doing and update if this file has been removed by another user.
> >
> >   For me, it is incoherent that fossil does not do the same on commit.
> >Of course, only for the case that there is a copy of the file in the
> >previous version and that there are no changes in it.
> >
> >   In the latter case, no information can be lost, and the file is
> >already contained in the previous version and can be checkout from there
> >if necessary.
> >
> 
> It's in that case where a "-f" would be useful. I would expect:
> 
>   fossil rm , to remove the file on checkout if the file is in
>   sync with the repository, but command to fail if the file is locally
>   modified.  In the case where the user really want to delete change
>   that never get committed, he can use: fossil rm -f 
> 
> That way, there's no danger of accidental data lost. If you call
> "fossil rm" by mistake, file can be retrieve from previous version on
> the repository.

I rather suspect that, if Fossil continues to grow in usage over time,
and if it fails to implement sane defaults and options like what you just
described as a general policy, there will probably be either a fork or a
wrapper that arrives to "solve" the problem.

That's just a guess, though.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Martin Gagnon]

Le 2012-12-12 06:28, Ramon Ribó a écrit :


  As I understand it, fossil currently deletes one file from disk when
doing and update if this file has been removed by another user.

   For me, it is incoherent that fossil does not do the same on commit.
Of course, only for the case that there is a copy of the file in the
previous version and that there are no changes in it.

   In the latter case, no information can be lost, and the file is
already contained in the previous version and can be checkout from there
if necessary.



It's in that case where a "-f" would be useful. I would expect:

  fossil rm , to remove the file on checkout if the file is in
  sync with the repository, but command to fail if the file is locally
  modified.  In the case where the user really want to delete change
  that never get committed, he can use: fossil rm -f 

That way, there's no danger of accidental data lost. If you call
"fossil rm" by mistake, file can be retrieve from previous version on
the repository.


 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Ramon Ribó]

 As I understand it, fossil currently deletes one file from disk when doing
and update if this file has been removed by another user.

  For me, it is incoherent that fossil does not do the same on commit. Of
course, only for the case that there is a copy of the file in the previous
version and that there are no changes in it.

  In the latter case, no information can be lost, and the file is already
contained in the previous version and can be checkout from there if
necessary.


RR



2012/12/12 Baruch Burstein 

> While the numbers may be in favor of the "-s" or whatever option,  I doubt
> the other behavior would be used zero times. It happens occasionally that I
> want to remove a file from version control, but not the actual file
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Baruch Burstein]

On Wed, Dec 12, 2012 at 1:24 AM, Jan Danielsson
wrote:
>
>I'm willing to bet that the number of times people will type "fossil
> mv/rm X Y" and not actually want to mv/rm X to Y just afterwards is
> vanishingly small. More to the point; let's reverse your "-s"-flag; I.e.:
>
>$ fossil mv X Y
>
>... renames X to Y (metadata and filesystem).
>
>$ fossil -d mv X Y
>
>... as in "Don't actually move" will only change the metadata, and
> the user can then use the mv command afterwards to manually rename/move
> the file in the filesystem.
>
>The last option doesn't make any sense at all. Which is sort of my
> point.. I think such an option would be used roughly zero times; but
> your proposed "-s" would be used almost 100% of the time (when people
> learn about it). And this goes back to that "ten things I hate about
> git"-list; when commands counter-intuitively require extra flags to get
> the canonical behavior.
>

While the numbers may be in favor of the "-s" or whatever option,  I doubt
the other behavior would be used zero times. It happens occasionally that I
want to remove a file from version control, but not the actual file.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Jan Danielsson]

On 12/11/12 23:08, K wrote:
> I agree with Themba. I like that Fossil is a separate repo 'world' from my 
> files. If this boundary is to be pierced, I think it should require passing 
> in some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in 
> this example representing "sync".
> 
> I would like some friendly tip text after rm/et al are ran, such as:
> 
> "You have removed file1.h, file1.c from repo foo, you may want to remove them 
> from your working copy."

> Seems like a great way to remind, teach, and help all in-context and with 
> minimal overhead.

   Say during your lifetime you'll (re)move 1000 files in fossil
repositories. That means you'll in practice perform 2000 (re)move
operations (once in metadata, and once in the filesystem). At what point
would one expect to have been sufficiently reminded and taught how to
(re)move files?

   Personally, I have never learned anything of value from having to
(re)move files twice.

   And I don't really buy the "It's safer" argument either. I have
several times become confused over what operations I have actually
performed because the file-system isn't in sync with the operations I
have performed; and becoming confused over what operations one has
performed because the filesystem doesn't reflect it is not "safe".

   I'm willing to bet that the number of times people will type "fossil
mv/rm X Y" and not actually want to mv/rm X to Y just afterwards is
vanishingly small. More to the point; let's reverse your "-s"-flag; I.e.:

   $ fossil mv X Y

   ... renames X to Y (metadata and filesystem).

   $ fossil -d mv X Y

   ... as in "Don't actually move" will only change the metadata, and
the user can then use the mv command afterwards to manually rename/move
the file in the filesystem.

   The last option doesn't make any sense at all. Which is sort of my
point.. I think such an option would be used roughly zero times; but
your proposed "-s" would be used almost 100% of the time (when people
learn about it). And this goes back to that "ten things I hate about
git"-list; when commands counter-intuitively require extra flags to get
the canonical behavior.

   (I did some serious refactoring recently which involved lots of mv
and a few rm, and it really annoyed me that my computer, which is
supposedly a machine for automating tasks, required me to perform an
extra manual step for each mv and rm). (Yes, I ended up scripting it in
the end .. but that just further annoyed me; why do I need to script
operations in fossil to get the canonical behavior?).

   I too am a little skeptical about adding too many settings to fossil,
but this is definitely one that I would think merits a setting if the
current (default) behavior is kept in 2.0.

   Sorry if this came out as a rant; it's not directed at anyone
personally, but like I said, I battled fossil rm/mv recently and I'm
still not completely over it. No flame-bait intended.

-- 
Kind regards,
Jan Danielsson

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[j. v. d. hoff]

On Tue, 11 Dec 2012 22:50:06 +0100, Themba Fletcher  
 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   
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

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Matt Welland]

On Tue, Dec 11, 2012 at 3:08 PM, K  wrote:

> I agree with Themba. I like that Fossil is a separate repo 'world' from my
> files. If this boundary is to be pierced, I think it should require passing
> in some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in
> this example representing "sync".
>
> I would like some friendly tip text after rm/et al are ran, such as:
>
> "You have removed file1.h, file1.c from repo foo, you may want to remove
> them from your working copy."
>
> Seems like a great way to remind, teach, and help all in-context and with
> minimal overhead.
>


I thought that there was some degree of agreement that the destructive
commands such as rm and mv would *require* -f (or some other switch) to do
the same action on disk.

If that is not the case then I share Themba's concern. This *will* cause
grief. There is no need to make this configurable.

My preference is to mirror the behavior of mecurial or git. Git's approach
of checking that the file is unchanged from the head before doing the rm is
safe and convenient.





>
> ^K
>
>
> on Dec 11, 2012, Themba Fletcher  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 
> 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.
> >
> >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
> >
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[K]

I agree with Themba. I like that Fossil is a separate repo 'world' from my 
files. If this boundary is to be pierced, I think it should require passing in 
some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in this 
example representing "sync".

I would like some friendly tip text after rm/et al are ran, such as:

"You have removed file1.h, file1.c from repo foo, you may want to remove them 
from your working copy."

Seems like a great way to remind, teach, and help all in-context and with 
minimal overhead.

^K


on Dec 11, 2012, Themba Fletcher  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  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.
>
>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
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Themba Fletcher]

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  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.

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

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Nolan Darilek]

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?


And is it not something that "fossil revert" could undo?

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.


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.



On 11/30/2012 08:58 AM, j. v. d. hoff wrote:
On Fri, 30 Nov 2012 15:30:13 +0100, Chad Perrin  
wrote:



On Tue, Nov 20, 2012 at 06:10:00PM +0100, j. van den hoff wrote:

On Tue, 20 Nov 2012 16:48:00 +0100, James Turner
>
>I'd suggest -f like cvs rm uses.

obviously everybody seems to have his/her own preference how to
handle this. so only a fraction of users will be happy in the end it
seems. -- I would again second the proposal
of Remigiusz Modrzejewski in this thread: after a 'grace' period
when it would behave in the way you propose (explicitly add a -f
flag to enforce deletion), finally change the default to what
_current_ VCSs (>= svn) seemingly all (?) do by default which is to
treat `svn(hg, git, bzr) rm' as meaning
"remove from repository and also remove the working copy" while
relegating different behaviour (if at all) to an option such as "bzr
rm --keep".

in my way that is the most frequently intended behaviour which
should therefore be the default.
sure a matter of taste as so many things, but at least it would
avoid surprises here for refugees from one of the other systems.


I think that makes sense, with the addition of using Matt Welland's
suggestion of scheduling the move to compatibility breaking behavior 
on a

2.0 release.  This is the purpose of common semantic versioning, after
all: major version numbers (the "integer" portion, essentially) are for
indicating breakage in backward compatibility for system features.

I think that doggedly sticking to current default behavior for all time
is a bad idea for a number of reasons[1], but that making changes to
expected defaults before a major version number increment is also a
rather bad idea.

[1]: . . . such as potential for error when using multiple DVCSes in
parallel and discouraging people from adopting the software.



I fully support this reasoning. the last point, especially, is not to 
be taken lightly. but of course behind that is the basically more 
important aspect that it (i.e. `rm' doing both, removal from tracking 
and deleting the checked out copy) would be a saner default, probably.


j.




___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[j. v. d. hoff]

On Fri, 30 Nov 2012 15:30:13 +0100, Chad Perrin  wrote:


On Tue, Nov 20, 2012 at 06:10:00PM +0100, j. van den hoff wrote:

On Tue, 20 Nov 2012 16:48:00 +0100, James Turner
>
>I'd suggest -f like cvs rm uses.

obviously everybody seems to have his/her own preference how to
handle this. so only a fraction of users will be happy in the end it
seems. -- I would again second the proposal
of Remigiusz Modrzejewski in this thread: after a 'grace' period
when it would behave in the way you propose (explicitly add a -f
flag to enforce deletion), finally change the default to what
_current_ VCSs (>= svn) seemingly all (?) do by default which is to
treat `svn(hg, git, bzr) rm' as meaning
"remove from repository and also remove the working copy" while
relegating different behaviour (if at all) to an option such as "bzr
rm --keep".

in my way that is the most frequently intended behaviour which
should therefore be the default.
sure a matter of taste as so many things, but at least it would
avoid surprises here for refugees from one of the other systems.


I think that makes sense, with the addition of using Matt Welland's
suggestion of scheduling the move to compatibility breaking behavior on a
2.0 release.  This is the purpose of common semantic versioning, after
all: major version numbers (the "integer" portion, essentially) are for
indicating breakage in backward compatibility for system features.

I think that doggedly sticking to current default behavior for all time
is a bad idea for a number of reasons[1], but that making changes to
expected defaults before a major version number increment is also a
rather bad idea.

[1]: . . . such as potential for error when using multiple DVCSes in
parallel and discouraging people from adopting the software.



I fully support this reasoning. the last point, especially, is not to be  
taken lightly. but of course behind that is the basically more important  
aspect that it (i.e. `rm' doing both, removal from tracking and deleting  
the checked out copy) would be a saner default, probably.


j.


--
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

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Chad Perrin]

On Tue, Nov 20, 2012 at 06:10:00PM +0100, j. van den hoff wrote:
> On Tue, 20 Nov 2012 16:48:00 +0100, James Turner
> >
> >I'd suggest -f like cvs rm uses.
> 
> obviously everybody seems to have his/her own preference how to
> handle this. so only a fraction of users will be happy in the end it
> seems. -- I would again second the proposal
> of Remigiusz Modrzejewski in this thread: after a 'grace' period
> when it would behave in the way you propose (explicitly add a -f
> flag to enforce deletion), finally change the default to what
> _current_ VCSs (>= svn) seemingly all (?) do by default which is to
> treat `svn(hg, git, bzr) rm' as meaning
> "remove from repository and also remove the working copy" while
> relegating different behaviour (if at all) to an option such as "bzr
> rm --keep".
> 
> in my way that is the most frequently intended behaviour which
> should therefore be the default.
> sure a matter of taste as so many things, but at least it would
> avoid surprises here for refugees from one of the other systems.

I think that makes sense, with the addition of using Matt Welland's
suggestion of scheduling the move to compatibility breaking behavior on a
2.0 release.  This is the purpose of common semantic versioning, after
all: major version numbers (the "integer" portion, essentially) are for
indicating breakage in backward compatibility for system features.

I think that doggedly sticking to current default behavior for all time
is a bad idea for a number of reasons[1], but that making changes to
expected defaults before a major version number increment is also a
rather bad idea.

[1]: . . . such as potential for error when using multiple DVCSes in
parallel and discouraging people from adopting the software.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[j. van den hoff]

On Tue, 20 Nov 2012 16:48:00 +0100, James Turner   
wrote:



On Tue, Nov 20, 2012 at 03:39:06PM +, David Given wrote:

Richard Hipp wrote:
[...]
> CVS did not couple the actions, and I copied CVS in this regard.  I
> agree with you now, that coupling them is the right thing to do.  But  
I
> fear to change it because that might cause problems for existing  
scripts.


Add a -p for physical option to actually change the files, and leave the
default as is? I agree, changing the existing behaviour would be a
recipe for disaster.



I'd suggest -f like cvs rm uses.



obviously everybody seems to have his/her own preference how to handle  
this. so only a fraction of users will be happy in the end it seems. -- I  
would again second the proposal
of Remigiusz Modrzejewski in this thread: after a 'grace' period when it  
would behave in the way you propose (explicitly add a -f flag to enforce  
deletion), finally change the default to what _current_ VCSs (>= svn)  
seemingly all (?) do by default which is to treat `svn(hg, git, bzr) rm'  
as meaning
"remove from repository and also remove the working copy" while relegating  
different behaviour (if at all) to an option such as "bzr rm --keep".


in my way that is the most frequently intended behaviour which should  
therefore be the default.
sure a matter of taste as so many things, but at least it would avoid  
surprises here for refugees from one of the other systems.


j.

--
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

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[James Turner]

On Tue, Nov 20, 2012 at 03:39:06PM +, David Given wrote:
> Richard Hipp wrote:
> [...]
> > CVS did not couple the actions, and I copied CVS in this regard.  I
> > agree with you now, that coupling them is the right thing to do.  But I
> > fear to change it because that might cause problems for existing scripts.
> 
> Add a -p for physical option to actually change the files, and leave the
> default as is? I agree, changing the existing behaviour would be a
> recipe for disaster.
> 

I'd suggest -f like cvs rm uses.

-- 
James Turner
ja...@calminferno.net
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[David Given]

Richard Hipp wrote:
[...]
> CVS did not couple the actions, and I copied CVS in this regard.  I
> agree with you now, that coupling them is the right thing to do.  But I
> fear to change it because that might cause problems for existing scripts.

Add a -p for physical option to actually change the files, and leave the
default as is? I agree, changing the existing behaviour would be a
recipe for disaster.

This, plus the ability to operate on directories (as in 'fossil commit
subdir' or 'fossil mv subdir newname') are the two big items on my
fossil wishlist.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "There is nothing in the world so dangerous --- and I mean *nothing*
│ --- as a children's story that happens to be true." --- Master Li Kao,
│ _The Bridge of Birds_



signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the "real" thing?

[Matt Welland]

On Tue, Nov 20, 2012 at 6:45 AM, Richard Hipp  wrote:

>
>
> On Tue, Nov 20, 2012 at 8:32 AM, j. van den hoff <
> veedeeh...@googlemail.com> wrote:
>
>> I already stumbled a couple of times over the fact that `fossil rm' and
>> `fossil mv' only act
>> on the repository but not on the check out, i.e. I always have to issue
>> two commands
>> in order to actually remove a file from the (future of) the project.
>>
>> obviously this is different from other VCSs but I'm missing the point why
>> it is a good idea
>> to decouple both actions (removal from tracking and actual removal).
>>
>> any enlightenment appreciated...
>>
>> right now I'd say it'd be better to keep the actions coupled.
>>
>
> CVS did not couple the actions, and I copied CVS in this regard.  I agree
> with you now, that coupling them is the right thing to do.  But I fear to
> change it because that might cause problems for existing scripts.
>

How about starting a 2.0 development track that does not guarantee
backwards compatibility in all regards?


>
>
>>
>> j.
>>
>>
>> --
>> 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
>>
>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users