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

[Andrew King]

For everyone's information, I had this problem when using Visual
Studio 2005. It occurred a number of times ( > 3?). I can not be
entirely conclusive that it was due to Intellisense, although this
seemed like the most likely culprit.

We did have .suo, .sln and .csproj in .bzrignore.

However, I haven't had this happen since recently. In the meantime, we
have upgraded to Visual Studio 2005 SP1, and bzr is now 0.18. It is
possible that something else caused the lock (some mis-behaving other
editor, or a terminal, or something)?

I still think the bug is high importance, although I can understand a
lot of work might be necessary to fix it. A temporary "hack" would be
on windows to copy all modified files to a temporary place, do the
update, and if the error is detected, copy the files back and revert,
else delete.

Throwing away hours of someone's work is a good way to get people
hating your versioning system, even if it is because they are using
some flaky operating system :(

Cheers,
Andrew

On 8/8/07, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> -----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-----
>
>