On Thu, 17 Mar 2011 15:05:13 +0200 <johnfo...@evrocom.net> wrote: > The problem is not because fossil doesn't track the individual files > base version, but > because fossil fails to determine properly the nearest common > ancestor of the file. > > In my example, after the update, the nearest common ancestor, in > fact, is [18a3dfdd], > but when fossil makes merge, it continues to consider [0a5a95eb] as > nearest common ancestor. > > IMHO, that is why it fails to merge properly. On the other hand, when > I browse the file history, > the graph is correct: > https://chiselapp.com/user/johnfound/repository/bad_update_test/finfo?name=A.txt > It means fossil knows the history of the file and still consider > "nearest" common > ancestor to be the wrong file. > > ...or I still can't understand something? So, please explain then.
I think a typical DVCS finds common ancestor using whole check-ins and it appears that fossil is no different in this regard. So if you did a local edit to your file and then committed this change, fossil simply does not record the fact your local edit resulted from [fossil update] and not from direct modification using a text editor or by some other means. That is, my understanding is that it's check-ins (changesets) that are versioned, not files, and so it's the relations between check-ins which are considered when doing merges. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
