On 31 July 2015 at 18:05, Joe Mistachkin <[email protected]> wrote:
>
> Michai Ramakers wrote:
>>
>> I don't think I understand what goes on here; I can't see the
>> difference between filesystem-mv (no fossil involved), and 'fossil mv
>> --hard', really.
>>
>
> Sometimes, Fossil will show a rename as a delete/add pairing. I've seen
> this happen when I edit the file at the same time I'm renaming it (and in
> some other circumstances). I'm not 100% sure what causes this behavior;
> however, it seems "mostly harmless".
ok; from what you said, I understood that this could be partly a
timeline-issue/-feature/-flaw.
I think I'm missing the point of what 'mv --hard' should do (before or
after the recent fix).
What I see now, is that 'fossil mv --hard dir1 dir2' has, apart from
printing 2 lines ('RENAME.... \nMOVED_FILE ...'), the exact same
effect as doing "mv dir1 dir2' (fossil not involved).
I can't see any difference. After either command, files in 'dir2' are
seen as extra files, files in 'dir1' are seen as missing, and so on.
Resulting timelines look the same as far as I can see.
When using 2 commands to move 'dir1' to 'dir2', as in
1) mv dir1 dir2
2) fossil mv dir1 dir2
...I could create a check-in containing that single action - renaming
a dir. When viewing the history of a file in 'dir2' or 'dir1' as per
'/finfo' page, one could traverse the history accross the
rename-action. That is not reallly possible when using 'fossil mv
--hard'.
Perhaps moving dirs using 'mv --hard' like this is a corner-case, or
I'm still not getting the point :-) Isn't 'mv --hard' the same as *nix
'mv' in my case..?
Thx,
Michai
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
