On Wed, Aug 5, 2015 at 4:02 PM, Warren Young <[email protected]> wrote:
> On Aug 5, 2015, at 9:35 AM, Andy Goth <[email protected]> wrote: > > > > It creates an empty file called dir2 and leaves dir/file alone. > > Okay, this isn’t an argument about proper semantics after all, it’s a bug > report. The behavior you’re seeing is simply wrong. > > I suspect the core problem is that Fossil doesn’t version directories, > only files. That is, there is no “fossil mkdir” command, and “mkdir foo ; > fossil add foo” is a no-op. I’ve run up against this several times since > switching from Subversion. > True. See below. > > > Unix mv would have renamed the directory from dir to dir2 > > Yes. “fossil mv --hard” should do that, too. > Agreed. > > Instead, it should realize that the mv destination doesn’t exist, so it’s > clearly a “rename" type mv, not a “move” mv. So, it should call rename(2) > on the directory entry, then record whatever it needs to in its DB to > remember that foo2 was once called foo, and all of foo’s current contents > are now under foo2. > > The contents of foo should not be touched at all. Since Fossil doesn't track directories, during a rename/move operation, it needs to check if the entity being renamed/moved is a directory. If so, then every thing under the directory has to be renamed/moved. This is because to Fossil "dir/file.c" is a file named "dir/file.c", not a file in a directory. How this is best implemented inside Fossil is up to the Fossil devs. Conceptually, the command: fossil mv dir dir2 would be equivalent to something like: find dir -type f -print | perl -ne 's/^dir//; qx(fossil mv "dir$_" "dir2$_");'
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
