On Sun, Dec 12, 2010 at 8:04 PM, James Turner <[email protected]> wrote:
> I would think if I merge a branch that deletes the file and I have local > changes the file would still exist on disk but would be treated like a > untracked file. Meaning, if I was to run fossil extras after the merge the > file would show up. Does this make sense? > It "makes sense" in the sense that I understand what you are saying. But I don't understand the "why". Please explain why you want the file to become untracked? To me, it seems like this would open you up to errors, since having untracked files laying around might cause your local tests to work, but then fail when somebody else checked out the same version that lacks those same files. FWIW, Fossil used to behave as you describe (it left untracked files laying around), but I changed it yesterday to actually delete the file from disk. I thought that change was a bug fix. Am I wrong? (Note: you can still recover the file using "fossil undo") See http://www.fossil-scm.org/fossil/info/70744b76e6 > > On Dec 12, 2010, at 7:30 PM, Richard Hipp wrote: > > > > On Sun, Dec 12, 2010 at 7:24 PM, Joerg Sonnenberger < > [email protected]> wrote: > >> On Sun, Dec 12, 2010 at 06:57:56PM -0500, Richard Hipp wrote: >> > Suppose you have the "trunk" branch checked out and you have made >> changes to >> > file xyz.txt locally, but have not checked them in. Then you do a merge >> of >> > branch "other-branch": >> > >> > fossil merge other-branch >> > >> > The file xyz.txt has been deleted in other-branch. What should fossil's >> > response be? Should it retain the locally edited copy of xyz.txt, or >> should >> > it delete file xyz.txt? >> >> Consider it a merge conflict. >> > > You mean refuse to do the merge? > > Certainly a conflict warning will be issued, but it seems like a flat-out > refusal to do the merge is the wrong approach. In addition to the conflict > warning, Fossil needs to do something with the file. > > As I ponder this question further, I'm leaning toward making a DELETE > action override any EDIT or RENAME action. So if a file has been deleted in > the local version, then a merge from a version where the file still exists > keeps the file deleted. And if a file still exists in the local version, > then a merge from a version where that file is deleted cause the file to > become deleted locally. Any objections to this approach? > > > >> >> Joerg >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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
