Folks: This is a general lesson that I've learned over the years, from following the darcs project among other things.
Consider this use case: There is a person who uses Tahoe-LAFS vX, and she shares files with other people who use Tahoe-LAFS vX, such as friends, family, or members of her organization or company. She wants to upgrade her Tahoe-LAFS to vX+1 even though the people that she shares with aren't ready to upgrade theirs. *And* she doesn't want to change anything about her work-flow or configuration, nor does she want to read the NEWS file carefully and think about compatibility issues. This implies that any new backwards-incompatible feature that is added in Tahoe-LAFS vX+1, such as immutable directories, has to be disabled by default, and to be turned on only by explicit action on the part of the user. So concretely, we should make sure that in Tahoe-LAFS v1.6 directories are created mutable by default, just like in Tahoe-LAFS v1.5. This is easy because the way that directories were created in Tahoe-LAFS v1.5 was to create a new empty mutable directory, and there is no point in creating a new empty immutable directory. :-) It would probably be wise to make the "tahoe backup" command continue to create mutable directories by default, because there might be people who use "tahoe backup" to create directories which they then share with their friends. I know that immutable directories in "tahoe backup" are sweet (#606), and I want people to use them, but for Tahoe-LAFS v1.6 the way to get people to use them should be to announce them in the NEWS and explain them in the docs and tell people to turn them on in their configuration. Anyway, part of my reason to post this is to inform developers and to reassure users that the use case sketched above is important to me. If this use case isn't taken care of, then what happens is people just put off upgrading until all of the people they share with have upgraded, which can sometimes mean forever. I would like people to get used to the idea that they can always upgrade to the new version of Tahoe-LAFS and continue sharing with their more conservative friends without having to even think about these issues. This is also why "forward-compatibility" features are so important to me. They can sometimes ease these transitions. Here is the list of tickets tagged "forward-compatibility": http://allmydata.org/trac/tahoe/query?status=%21closed&keywords=% 7Eforward-compatibility Regards, Zooko http://allmydata.org/trac/tahoe/ticket/606# backupdb: add directory cache _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
