RENAME a/b/1.0/test.txt a/b/1.1/1.0/test.txt

Well that's unexpected. i will attempt to reproduce this in the next couple of hours and see if we can't get this resolved. If you have not already checked that in, please don't.

Fortunately for this particular case I was able to revert and then work around the problem (renaming at the individual file level works fine, it's just the rename at the directory level that seems to be broken).

fossil rename a/b/1.0 a/b/1.1

RENAME a/b/1.0/test.txt a/b/1.1/1.0/test.txt

I guess, there's some logic to this. Fossil rename got the basename (1.0) and moved into 'a/b/1.1' directory.

I wonder if the same would fail with --hard switch, as the target dir does not exist.

david@cubi:~$ mv a/b/1.0 a/b/1.1
david@cubi:~$ fossil rename a/b/1.0 a/b/1.1
RENAME a/b/1.0/test.txt a/b/1.1/1.0/test.txt

The root cause has to do with using mv before rename: if we do the same without the mv then it works. The problem is that fossil checks the filesystem for what type of file the first argument is (a/b/1.0) and if it's not there on disk, it does not know that it's a directory. After that, certain parts treat it as if it were a filename but others (a SELECT loop, it seems) treat it like multiple filename matches (i.e. as if it's a directory). Chaos ensues.

How best to resolve that, i'm not currently certain, but the workaround for the time being is to do the fossil rename first, then the mv, or to use fossil rename --hard instead, which will do the move for you.

i might have a solution, so stay tuned. Maybe someone more familiar with that particular code will propose as solution while i try this out.

or to use fossil rename --hard instead

...or fossil set mv-rm-files 1, which enables --hard for fossil mv/rm always.

This option used to be something you had to enable at configure time, but it's been default-on for approximately two years now.

Indeed, I think it's time we just removed the FOSSIL_ENABLE_LEGACY_MV_RM ifdef. I can't say I recall anyone speaking of disabling the option (./configure --disable-with-legacy-mv-rm) so it's just cluttering the "make" output.

Note that I am not advocating that we change the mv-rm-files setting default.

The problem is that fossil checks the filesystem for what type of file the first argument is (a/b/1.0) and if it's not there on disk, it does not know that it's a directory. After that, certain parts treat it as if it were a filename but others (a SELECT loop, it seems) treat it like multiple filename matches (i.e. as if it's a directory).

Is seems that that's only half true. Fossil doesn't initialy realize that it was a local directory but appears to handle that part just fine down in the loop where it matters. However...

i might have a solution, so stay tuned.

Nope.

When a/b/1.0 is first mv'd to a/b/1.1 then this line:

https://fossil-scm.org/fossil/file?udc=1&ln=1096&ci=tip&name=src%2Fadd.c

misbehaves, producing a "zTail" value of "1.0/test.txt", which then gets appended to the destination directory name to produce "a/b/1.1/1.0/test.txt". That line is never hit if the target directory does not (yet) exist in the filesystem, and instead the bit 2 lines down from that is triggered.

What to do about that, though, is not clear to me, so i'm going to put this down for a bit and hope that someone more familiar with that code will chime in soon.

or to use fossil rename --hard instead

...or fossil set mv-rm-files 1, which enables --hard for fossil mv/rm always.

It turns out that --hard doesn't do anything for the case that directory a/b/1.0 exists and target dir a/b/1.1 does not. Why exactly that is, i'm not sure.

Though like you I'm still trying to get my head around what this code is trying to achieve, I will attempt to develop a fix if I do understand it :)

MISSING a/b/1.1/1.0/test.txt

You can try the version [709d2f804].

$ fossil rename a/b/1.0 a/b/1.1
RENAME a/b/1.0/test.txt a/b/1.1/test.txt

$ fossil changes
RENAMED    a/b/1.1/test.txt

Thank you! That fixes the problem for me.