Re: [fossil-users] fossil not tracking directories / dir artifacts after switching branches
On Thu, Dec 22, 2011 at 08:15:35PM -0500, Richard Hipp wrote: The rmdir(2) system call on Posix is a no-op if the directory is not empty. So I was thinking that we could just invoke rmdir() (or _rmdir() on windows) on the directory of a file every time a file is deleted, and let the OS worry about whether or not the directory is empty. But then I read this on the Linux rmdir(2) manpage: Infelicities in the protocol underlying NFS can cause the unexpected disappearance of directories which are still being used. I consider that bad documented documentation! No examples, no source for that claim. Not a rare case in manpages. Good that you read those details though :) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil not tracking directories / dir artifacts after switching branches
In one of my projects I've been working on a development branch. In the new branch- I've moved several directories around. All the files are tracked perfectly- but when switching between branches, my work space, or checkout area has these artifacts, or empty directories from the previous checked out branch. All the files are being moved and handled properly, which is good, but it's annoying after cleaning up and re-architecting a development branch- only to have these directory artifacts lying all over the place when I switch between branches. I can write a script to clean out and remove empty directories but it would be nice if this was handled by the scm. -jmg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil not tracking directories / dir artifacts after switching branches
On 2011-12-22, at 15:43, Justin Gedge justin.ge...@gmail.com wrote: In one of my projects I've been working on a development branch. In the new branch- I've moved several directories around. All the files are tracked perfectly- but when switching between branches, my work space, or checkout area has these artifacts, or empty directories from the previous checked out branch. All the files are being moved and handled properly, which is good, but it's annoying after cleaning up and re-architecting a development branch- only to have these directory artifacts lying all over the place when I switch between branches. I can write a script to clean out and remove empty directories but it would be nice if this was handled by the scm. If it remove directories, what fossil should do if there's some untracked files in those directories, delete the whole directory with all those files in it? Just wondering. May be another case for a so multipurpose -f switch ? ;) -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil not tracking directories / dir artifacts after switching branches
I think a good algorithm would be quite simple: If a file being removed as part of a checkout to a different branch is the last file in a directory and the directory is not listed in the empty-dirs entry then remove the directory. This should have zero negative impact on anyone and during the early phases of a project where things are moving around a lot it would be really really appreciated to not see the droppings from a different branch which can be very confusing. Especially to learners and refugees from other SCM tools. Some of the things that have been mentioned on the list would be better handled as tickets. What is the current process for submitting a ticket? A quick perusal of the fossil-scm.org site didn't yield any hints for me. Thanks! Matt -=- On Thu, Dec 22, 2011 at 5:00 PM, Martin Gagnon eme...@gmail.com wrote: On 2011-12-22, at 15:43, Justin Gedge justin.ge...@gmail.com wrote: In one of my projects I've been working on a development branch. In the new branch- I've moved several directories around. All the files are tracked perfectly- but when switching between branches, my work space, or checkout area has these artifacts, or empty directories from the previous checked out branch. All the files are being moved and handled properly, which is good, but it's annoying after cleaning up and re-architecting a development branch- only to have these directory artifacts lying all over the place when I switch between branches. I can write a script to clean out and remove empty directories but it would be nice if this was handled by the scm. If it remove directories, what fossil should do if there's some untracked files in those directories, delete the whole directory with all those files in it? Just wondering. May be another case for a so multipurpose -f switch ? ;) -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil not tracking directories / dir artifacts after switching branches
On Thu, 22 Dec 2011 19:00:18 -0500 Martin Gagnon wrote: On 2011-12-22, at 15:43, Justin Gedge justin.ge...@gmail.com wrote: If it remove directories, what fossil should do if there's some untracked files in those directories, delete the whole directory with all those files in it? Just wondering. May be another case for a so multipurpose -f switch ? ;) Fossil check-ins mirror the state of working trees and vice versa, excluding extra files in the working tree that are not present in any of the check-ins. All actions in Fossil related to this mirroring (checkout, update, commit) are not destructive in these cases: * File has changes. * File is absent. * Another file with the same path, but different contents exists. (Fossil asks to overwrite such file.) Not deleting empty directories looks like a bug, because it breaks the mirroring. For example, if a subsequent check-in removes a file, when you checkout this commit (while the working tree is in the state of previous commit), the file gets removed (unless it has changes, see above). Consider this case: Check-in 1: file.txt dir1/file1.txt dir1/file2.txt dir2/another.txt Check-in 2: file.txt dir1/file1.txt The obvious way to mirror going from check-in 1 to check-in 2 in the working tree is: 1) Remove dir1/file2.txt, because it's not present in the commit. 2) Remove dir2/another.txt, == Now, it's helpful for this exercise to treat the whole path as a file instead of looking at it as a directory/file structure: 3) Do we have files named dir1/* either in the commit or as extras in the working tree? Yes, thus, not removing dir1 part. 4) Do we have files named dir2/* in the commit or as extras? a) If we have, don't remove directory. b) If we don't, we no longer have any files with such names, thus we should remove this empty directory. Another way to look into going from ci 1 to ci 2, which is easier to understand: * KILL EVERYTHING in the working tree... except extra files. * Checkout commit 2. So, my points: + Fossil should remove empty directories. + There's no need for -f option to kill extra files. For this, we have `fossil clean` command. -- Dmitry Chestnykh http://www.codingrobots.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil not tracking directories / dir artifacts after switching branches
The rmdir(2) system call on Posix is a no-op if the directory is not empty. So I was thinking that we could just invoke rmdir() (or _rmdir() on windows) on the directory of a file every time a file is deleted, and let the OS worry about whether or not the directory is empty. But then I read this on the Linux rmdir(2) manpage: Infelicities in the protocol underlying NFS can cause the unexpected disappearance of directories which are still being used. Is that something to worry about? Anybody know? -- 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
Re: [fossil-users] fossil not tracking directories / dir artifacts after switching branches
On Thu, 22 Dec 2011 20:15:35 -0500 Richard Hipp d...@sqlite.org wrote: The rmdir(2) system call on Posix is a no-op if the directory is not empty. So I was thinking that we could just invoke rmdir() (or _rmdir() on windows) on the directory of a file every time a file is deleted, and let the OS worry about whether or not the directory is empty. But then I read this on the Linux rmdir(2) manpage: Infelicities in the protocol underlying NFS can cause the unexpected disappearance of directories which are still being used. I'm used to seeing it the other way 'round. You can't delete an empty directory on an nfs mounted file system because the nfs server has issues about doing so. And I'd say it's not an infrequent occurrence. mike ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil not tracking directories / dir artifacts after switching branches
On Thu, Dec 22, 2011 at 6:15 PM, Richard Hipp d...@sqlite.org wrote: The rmdir(2) system call on Posix is a no-op if the directory is not empty. So I was thinking that we could just invoke rmdir() (or _rmdir() on windows) on the directory of a file every time a file is deleted, and let the OS worry about whether or not the directory is empty. But then I read this on the Linux rmdir(2) manpage: Infelicities in the protocol underlying NFS can cause the unexpected disappearance of directories which are still being used. Is that something to worry about? Anybody know? I use rmdir -p --ignore-fail-on-non-empty /path/to/dir to remove all non empty dirs on a specific path extensively in scripts and I've never seen wrong behavior on NFS. It will remove all the empty dirs starting at the leaf and then stop without error on the dir that contains other dirs or files. I'm not sure how those switches translate to the C library calls or even it they do at all. -- 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users