On Oct 25, 2009, at 2:27 PM, Zed A. Shaw wrote: > Currently, the behavior is that fossil overwrites files without any > prompting using the "latest one wins" method.
It shouldn't be doing that! Can you give me an example so that I can track down the problem? > Now, latest one wins is > fine, but having it obliterate hours of potential work in one swift > motion is seriously uncool. Fossil *should* be so that it never destroys work. If it does overwrite something, there should always be a way to get that something back. Again, please give me a specific example so that I can fix the problem. > > So, my question is: how do other people handle this? It there some > trick > or flag I'm not seeing to prevent a merge from destroying my carefully > crafted source code? > > Ideally, I'd be looking for one of about three things: > > 1) fossil update -y to make it prompt for for who wins. > 2) fossil update makes backups (and tells you about them). Update already does make backups. If you do "fossil update" and don't like the results, just type "fossil undo" and everything should revert to the state it was in before the update. > 3) fossil sync -d to sync and print a diff of what might blow up. > > So, are these supported or do they need to be implemented? > > -- > Zed A. Shaw > http://zedshaw.com/ > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users D. Richard Hipp [email protected] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
