[fossil-users] fossil not tracking directories / dir artifacts after switching branches

[Justin Gedge]

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

[Martin Gagnon]

On 2011-12-22, at 15:43, Justin Gedge <justin...@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...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Matt Welland]

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
-=-

[Dmitry Chestnykh]

On Thu, 22 Dec 2011 19:00:18 -0500 Martin Gagnon wrote:

> On 2011-12-22, at 15:43, Justin Gedge <justin...@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

[Richard Hipp]

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

[Mike Meyer]

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

[Matt Welland]

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

[Lluís Batlle i Rossell]

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 :)