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
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
