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