2011/2/11 Lluís Batlle i Rossell <virik...@gmail.com>: > > I think the approach taken by most VCS I've seen is far better than what > fossil > provides now: leave the conflict files in the working directory with a > different > name, like it could be src/update.c.conflict for example.
Yes, something like that. As I recall, SVN update leaves a file with ".rNN" as the extension, where NN is the revision number, and another file with the trial merge, while leaving the local copy as-is. (Of course, using the revision as a file extension does not work well with most DVCSs.) > As I understand now, I've either to use the stash or commit somewhere and try > the operations susceptible of file merges (update/merge) always with a working > directory clean of changes. I personally dislike having to have this care. > > Any thoughts? Agreements? Disagreements? I agree, a VCS - any VCS - should not overwrite or delete local changes - or anything unmanaged. That said, I long ago learned (the hard way) the first axiom of version control: A VCS is not a backup system. So, I do make backups before I update my local working copies. Hopefully, nothing goes wrong and do not need to restore anything from a backup. But please, do provide better handling of local changes and unmanged files. > (And of course I'm writing this after just having lost some lines of code) I know what you mean. No matter how often you make backups, once in a while you wish you made them more often. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
