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

[John Whitley]

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 that it _is_ possible to open a file in shared mode on  
Windows... just not the (sane <cough>) default.  At least recent  
versions of Visual Studio seem pretty well behaved in this regard, as  
this would plague interoperation with any source control system, not  
just Bazaar.  Likewise, I often edit outside of Visual Studio, and  
I've never gotten a lock conflict on write, just the usual external  
update notice in VS.  Instead of holding locks, VS appears to  
register file/directory watches and notifies the user if any  
currently opened files were changed externally.

> 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