On 5/16/16, Ross Berteig <r...@cheshireeng.com> wrote: > >>> That would require a backwards-incompatible change to the manifest format > > Unless some clever trick can be invented that will let older versions of > fossil simply see such files as newly added at the time of the copy > while letting a new version also track the history across that event. > > I'm not steeped enough in the manifest details to know what is possible > myself, however. >
I think this could be done using the existing F-card in the Manifest artifact (https://www.fossil-scm.org/fossil/doc/trunk/www/fileformat.wiki#manifest). Merely put the name of the file copied from in the old-name field, and then add a new letter (perhaps "c") to the permissions field to let Fossil know that the file was copied from old-name rather than moved from old-name. The extra "c" character in teh permissions field is necessary to distinguish between these cases: Case 1: (this is not a copy) fossil mv abc.txt def.txt echo hi >abc.txt fossil add abc.txt Case 2: fossil cp abc.txt def.txt The "c" flag in permissions would only occur for Case2. There are other interesting cases to be on guard against, for example: Case 3: fossil mv a.txt temp.txt fossil mv b.txt a.txt fossil mv temp.txt b.txt That part is easy I think. The hard part will be updating the current Fossil implementation to understand the implications of forks in file change graphs. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
