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