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

[John Arbash Meinel]

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

John Whitley wrote:
> Aaron Bentley wrote:
>>> on files that
>>> don't deserve version control
>>
>> So you are saying that Visual Studio's Intellisense doesn't read actual
>> source files ever?
> 
> FWIW, I don't think I've ever had a random conflict with Visual Studio
> and source control, at least with recent versions (VS7/VS8).  By "I", I
> really mean an entire full-time dev team of (average) 10 developers in
> the past two years, over two SCM systems.  Though I will note that at
> least CVSNT has built-in retry behavior.  IIRC, I've only ever seen that
> triggered for versioned executables that were running during an update,
> or a smattering of similar cases, none of which were attributable to
> Visual Studio.  This does mean only versioning actual "source" files,
> not working files (e.g. Intellisense's .ncb files for Visual Studio).

Note also that CVS versions a single file at a time. So if it got
kicked, you can just update that file again later.
Bazaar versions the whole tree at a time. We haven't put in a way to
track that some files are at a different revision than the rest of the
tree. (And we *really* don't want to put that in, because it leaves you
open to a host of bad things that SVN/CVS can get you into. Like "it
works perfectly here after I committed", but you can't check out that
same tree because everything is at a different version). If you had a
file out of date, you could 'bzr revert foo', but that would lose any
local changes (versus bzr 'update foo')

Anyway, what I would actually like to see is for TreeTransform to try to
rename-into-place and if that fails, it can rename it 'to the side' and
mark the file as conflicted.

This probably has some purity issues for Aaron, as he has always wanted
to detect all conflicts in the beginning, so that by the time he gets
around to actually doing the updates, he knows what will happen.

However, it works for case conflicts, as well as locked files, or files
showing up while you are renaming into place. (I guess that means it
also needs to conflict if the '_apply_deletions' step fails).

Ultimately, I would rather not rollback the entire transaction, instead,
just mark a few more files as conflicted, and put at least .THIS files
around.

> 
>> So you're saying Andrew King had versioned generated/intermediate files?
> 
> It's unclear, but I've never had a problem with either CVS or Perforce
> getting kicked back on update by Visual Studio.  It would be informative
> to know what version of Visual Studio he was using, and what kind(s) of
> files encountered "sharing violations", to use the platform's parlance.
> 
> Here's a straw-man idea for a different approach: consider notifying the
> user of the failure (bleat to the console) then retrying a few times. 
> If the tree update ultimately fails, note in the working tree state that
> the update failed.  E.g. in 'bzr status' this might appear as "update
> failed" or "out of date" or somesuch.  "modified" doesn't seem
> appropriate, as that should capture intentional user changes, not
> recoverable SCM failures.  In the case of 'bzr pull', a subsequent pull
> once the locking (or permissions, or whatever) issues are fixed will
> remedy the tree state.
> 
> -- John


We could try a couple times, but I think you would want to pause
inbetween (what is the sense of retrying 10 times in 10ms). And you
still wouldn't be able to get everything (for example if you are failing
because of a case conflict).

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

iD8DBQFGudH4JdeBCYSNAAMRAoLLAKDH2pcUAfdMfxZivF88p4wwkM0yJQCeMeKN
1FCpkxI7u1GsSbbpmPHXCNY=
=NuX5
-----END PGP SIGNATURE-----