Hi, Just to clarify: as I understand the rename detection with inodes is just being used as a heuristic. It will be used to suggest to users that they might want to record a change as a rename, but it won't directly lead to any kind of data corruption if darcs mis-guesses the situation.
Is that correct? If the user blindly accepts the offered renames, or uses record -a, then there still could be a problem as a dodgy patch could get recorded and cause trouble further down the line. One thing to watch out for is that renames to boring files are handled correctly (i.e. rejected/ignored at least by default). Another thought is that even though inodes are a really nice way to capture user actions, it would be good to also have an alternative approach such as detecting similar content, for cases the inode tracking doesn't pick up. Detecting similar content would also be useful in future for inferring hunk move patches once we support those. Cheers, Ganesh On 22/08/2013 17:54, José Neder wrote: > I guess is a little delicate. Maybe there is some editor that write a > backup and then rename, in my experience i haven't had any problem > with gvim, and scratch(elementary editor). Obviously restoring from a > backup would confuse the algorithm and if you rename the file at the > same time it would lose track of it. If you check out an old version > there is not problem, at checkout the inodes in the index are updated. > I am interested in the bzr implementation, if you could throw me a > link or more info about it. I made a quick search but i didn't found > anything about it. > > 2013/8/22 Stephen J. Turnbull <step...@xemacs.org>: >> AntC writes: >> >> > [inode, etc] seems an easy way to keep track of files. Do other >> > VCS's use it? Is there some reason darcs hasn't used it before? >> >> Sounds very delicate to me. Points that would worry me: The ambiguity >> of multiple links to the same file. Breaking of hard links on edit by >> some editors and not others. Resurrection of deleted files (whether >> by checking out an old version or restoring from backup). >> >> bzr (bazaar.canonical.com) does track "containers" (ie, it could know >> which on-disk data is the original and which the copy, and it >> distinguishes between remove from repo + readd under a new name from >> an atomic rename), but it doesn't track inodes. It has its own >> database and identifiers for this. >> >> _______________________________________________ >> darcs-users mailing list >> darcs-users@darcs.net >> http://lists.osuosl.org/mailman/listinfo/darcs-users > _______________________________________________ > darcs-users mailing list > darcs-users@darcs.net > http://lists.osuosl.org/mailman/listinfo/darcs-users > _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
