It pretty much impossible to mis-guess a move unless you really try it, because it means that there are different files with the same inode, and the only way would be to use the same file but change the content and use it like another file. I mean the probability to have the same inode number in a new file is low(once you have deleted the old file of course), and that a file with the same inode ends in the same repo is even lower, much lower. I think the inode number used by a new file is always an increment from the inodes used before, so unless you cover all the numbers in a 64 bit range, you will not face with the same number twice. Maybe i'm wrong. If you restore a file from a backup not tracked by darcs repository renaming the backup to the filename in question, you wouldn't see any change like without "--look-for-moves" because it detects "moves" and not adds and/or deletes. If you change the name you will see a remove like you used to see without ""--look-for-moves". Exemplifying: ~> touch foo ~> darcs record -al -m "foo added" Finished recording patch 'foo added' ~> cp foo foo.bak ~> mv foo.bak foo ~> darcs wh --look-for-moves No changes! [1] ~> mv foo foo2 ~> darcs wh --look-for-moves rmfile ./foo [2]
[1] there are not moves here so there are not changes, even if foo has another inode number, --look-for-moves only marks moves and not removes or adds. [2] darcs lost track of the file because the backup doesn't have the same inode number but if you do this: ~> touch foo ~> darcs record -al -m "foo added" Finished recording patch 'foo added' ~> cp foo foo.bak ~> mv foo foo.bak2 ~> mv foo.bak foo ~> darcs wh --look-for-moves move ./foo ./foo.bak2 [1] [1] darcs doesn't lose track of the file because it is still in the repo so it marks a move even when you maybe wants not to be. In this case i you should turn off --look-for-moves flag to get the desired behavior. It should not lead to "data corruption" unless you do that in which case I guess it was on purpose and there is not data corruption. I think an user can and should blindly accepts the moves if she/he know that limitation. Boring files are filtered by default, so not problem there. It would be nice to have an algorithm to detect similar files/hunks but, how much similarity is enough? this can not be generalized, the only way is trial and error with a lot of examples and even there it would be nice to have the choice to give the percentage threshold of similarity like an option. Is like when you use the fill tool in gimp to paint a zone with a color, without the option to select the threshold the tool would be pretty useless in a lot of cases. 2013/8/22 Ganesh Sittampalam <[email protected]>: > 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 <[email protected]>: >>> 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 >>> [email protected] >>> http://lists.osuosl.org/mailman/listinfo/darcs-users >> _______________________________________________ >> darcs-users mailing list >> [email protected] >> http://lists.osuosl.org/mailman/listinfo/darcs-users >> > _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
