[darcs-users] [planet darcs] Automatic detection of file renames for Darcs

Ganesh Sittampalam ganesh at earth.li
Thu Aug 22 18:06:43 UTC 2013


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.



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 <stephen at 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 at darcs.net
>> http://lists.osuosl.org/mailman/listinfo/darcs-users
> _______________________________________________
> darcs-users mailing list
> darcs-users at darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-users

More information about the darcs-users mailing list