Can someone explain me how exactly fossil manages moves? The actual problem is the following.
Let's have a project, foo, with the following structure: foo/x/a.c foo/x/b.c foo/y/c.c foo/y/d.c The project sits on a central server. Two developers, Alice and Bob have their local clones on their machine and checked out the project in the above state. Alice modifies a.c and c.c. In the meantime, Bob also edits files, but different ones to those edited by Alice, so there are no merge conflicts. However, Bob also decided to re-organise the project source tree and moves files around, with 'fossil mv'. So now they have the following state (capital filename indicates modified file but of course the actual filename is lower case): Alice: foo/x/A.c foo/x/B.c foo/y/c.c foo/y/d.c Bob: foo/z/q/a.c foo/z/q/b.c foo/z/q/C.c foo/y/D.c Now Alice commits to the server, and it goes through without a hitch. The problem arises when Bob, before his commit wants to fossil update (auto-sync is on). At that point fossil seems to simply delete C.c (i.e. Bob's modifications to that file are completely lost) *and* also, it seems, Bob's moves are ignored - the original project structure is restored. All that remains from Bob's work is his edits of d.c -> D.c but everything else he's done is gone. In the real case where this happened we're not talking about 4 files but hundreds, of which at least 20-30 have been moved around by Bob and similar amount edited by both parties; re-doing the whole thing would be a real PITA. So, my questions are the following: Fossil on Bob's machine can know that x/A.c on the server is the modified version of Bob's z/q/a.c, so it could just change z/q/a.c to z/q/A.c, i.e. merge Alice's file content change with Bob's file location change. Considering that they are orthogonal, there's no merge conflict. But even if Bob edited his a.c, fossil could just merge the server's x/A.c with Bob's z/q/A.c, just as it would with an un-moved file. Question 1: is there a way to ask fossil to do that? Question 2: why does fossil delete a modified file (C.c)? That, I believe, is something that fossil was designed to never do. As far as I know, fossil would under no circumstances discard unsaved work unless the user explicitly and specifically instructs it to do so. It seems that fossil mv can drive fossil into a state where it discards user changes without confirmation - we needed to use fossil undo to restore the mods when we realised what happened during fossil update. Thanks, Zoltan _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
