[RFC] making TreeTransform more resistant to unexpected failures / writing problems
whitley at acm.org
Wed Aug 8 00:05:49 BST 2007
Aaron Bentley wrote:
>> on files that
>> don't deserve version control
> So you are saying that Visual Studio's Intellisense doesn't read
> 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
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
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.
More information about the bazaar