> a) having a .bak file completely undermines the reason for using > source control. It reveals old habits from pre-SCM days, which are no > longer relevant once one has an SCM.
Not necessarily. If the tool *needs* the file and the .bak file, then you need to keep both around and you'd better put them under revision control for integrity's sake. You can't expect each and every tool that needs a file and its previous version to cater for each and every type of SCM tool to obtain the last version of the file. In my case the .bak file is indeed just a backup file, the tool renames the old file before saving the new one, so if the system crashes and the new file can not be written out successfully, then you have something to go on. The tool does not (and can not) assume that you have an SCM, that's why it does it. That's why I don't care that as a quick and dirty solution the .bak file is simply taken out of the SCM's scope. But that may not be the case with every tool, really. Plus, you can't avoid programs every now and then generating the exact same content under different filenames, which would lead to similar situations, wouldn't they? Zoltan _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
