On Mon, Mar 2, 2015 at 1:37 PM, jungle Boogie <[email protected]> wrote:
> Hi Matt, > On 2 March 2015 at 12:14, Matt Welland <[email protected]> wrote: > > The basic point made in the post by Mark Shuttleworth (in 2007 BTW) is a > > good one. > > > > Cleaning up or refactoring is hard to do and ideally an SCM tool helps > the > > process. Tools that behave inconsistent with expectations induce > legitimate > > FUD leading to reluctance to clean up. There might be some areas where > > Fossil could be improved in this regard. For example, if I clean up and > move > > things around in a Fossil repo and by force of habit do an update before > a > > commit I *lose* some of my clean up effort when Fossil (illogically IMHO) > > brings back the removed files. A minor setback that chips away at the > > willingness and enthusiasm developers have towards refactoring. > > > > I just tested this and my very simple test, this is what I found out: > you need to fossil rm X > rm X > fossil commit -m "deleted file X" > > Has that also been your experience? > My previous experience was: fossil rm X rm X fossil update # X comes back But I just tried to reproduce this removed files coming back behavior using our officially installed 1.28 version of fossil and the file does *not* come back. I've had complaints about this fairly recently but since I can't reproduce it I assume the user involved was accidentally pointing to an older version of fossil. My mistake. Ignore my comment. > > > > Just my $0.02. > > > > > -- > ------- > inum: 883510009027723 > sip: [email protected] > xmpp: [email protected] > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
