[RFC] making TreeTransform more resistant to unexpected failures / writing problems

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kuno Meyer wrote:
> The following is my experience with Visual Studio (as my daily working
> environment) with C#-Projects:
> 
> - VS *does not* hold locks on source code files (*.cs and others),
> project files(*.csproj) and solution files (*.sln).
> 
> Thus everything that needs to be versioned is kept lock-free.

That means bzr is free to delete them, at all times, right?

> So yes and no:
> - Intellisense uses source-code parsing for files of the current
> project/compilation unit

Yet, you believe it is safe to delete files while they are being parsed?
 Or are you saying that it's unsafe, but predictably so?

>> In Unix, there's no need to remember to close such documents when
>> running bzr.
> 
> Windows is not Unix ;-)

Yes, and that makes Windows infuriating at times.

>> Write-protection of files on Unix does not prevent renames, it prevents
>>  writes.
> 
> On Windows, it prevents writes and deletion, but not renames. The error
> happens when deleting the (moved) file from the limbo directory.

Ah.  My misunderstanding.

>> Your opinion is certainly valid, but I have done my best.  I have
>> documented most of the public methods and many private ones, too.  As
>> the main author of TreeTransform, I may not have the perspective needed
>> to update the documentation, but I would welcome advice or patches.
> 
> Didn't wanted to blame you. It was just my impression after having
> looked for half an hour into the code.

Well, I do want to make TT more accessible.  What are your biggest
questions?

>> I don't think that changing finalize will change much.  If a transform
>> has been successfully applied, then there will be nothing in limbo
>> anyway.
> 
> At least, this is the position where my script in the last comment of
> bug 67699 fails

I suspect finalize is only attempting to delete that file because
apply() has failed.

>>> 2) Newly created or modified files shall not have the write protection
>>> flag set (enforce chmod u+w)
>>>
>>> Would this be acceptable an acceptable behaviour?
>>
>> That is not necessary or desirable on UNIX.  In fact, we try to preserve
>> the existing file permissions if at all possible.  How would this help
>> on Windows?
> 
> This was my intention for this second proposal (ignoring
> write-protection flags):
> 
> 1) Bazaar has a quite nasty behaviour when occurring access problems
> while tree transformation. Therefore, if we can work around the problem
> easily (e.g. by ignoring the write protection flag), we should do so.

To me, this describes ignoring the write protection flag on files that
already exist.  That sounds fine to me.

Are you saying you were describing ignoring the umask?  Just ignoring
the umask is not an adequate solution, if we can't cope with files that
are already u-w.  But if we can cope with u-w files, then surely we
don't need to ignore the umask.

> 2) Write protection in the working copy somehow contradicts the idea of
> a VCS (especially a distributed VCS), where we have versioning and
> branching to remember a specific state.

Users have asked us to preserve file modes.  So we do.  I don't think we
should change that policy lightly.

> And for my personal use case:
> 
> 3) Write protection of individual files is an (unnecessary) feature of
> all Microsoft Version Control systems, and I have a lot of crashed
> transations because of this. Perhaps I'm not the only developer working
> in this way?

So far, you've made a case that could justify trying to defeat u-w
permissions, but I'm not convinced that we should leave it set as u-w
when the transform is complete.  I don't see any advantage in creating
files with u+w against the user's wishes, since if we can handle
existing files with u-w, we can handle new files with u-w.

And if u-w needs to be handled only for deletions, it would be trivial
to add support.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGuPz90F+nu1YWqI0RAqmWAJ9smeu6DOqtSCPnaCrd6XR2aRK7TACeMQA+
JbMOjIPkoSE++hoUmOuWbE4=
=Ct7I
-----END PGP SIGNATURE-----