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

[John Arbash Meinel]

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

Andrew King wrote:
> 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.

Well, you *should* have .sln and .csproj versioned. Since they define
your project layout. (Just like having Makefile versioned.)

However .suo is a binary file which is the specific user preferences at
the time of opening the project. Which means it changes randomly, and
changes every time you open/close a file, etc. It should be quite
specific to the user, and shouldn't be versioned. (Earlier versions had
the same thing, but it was a .ncb file).

> 
> 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
> 

(Note: I completely agree with you)
There is one workaround. Work in fully distributed mode. Then there is
no 'update' to worry about. And you just do a 'commit' of all your work
before you do a 'merge' of someone else's. Then you never lose anything
that you have done.

I realize that changes how people think about things, though. And we
really do want to support the centralized model. (It is extra important
on Windows, as I believe you have more people who don't have much of an
idea of what VC is, and just follow the script they were told. There are
just a lot more people, so you get a much wider distribution of
expectations/knowledge bases).

I don't know if you saw my other post. But *my* feeling is that
conflicts at 'rename into place' time should be considered just that. A
conflict, being marked as such, and dumping a .THIS file for what we
wanted it to be.

It isn't quite as nice as being able to try a 'bzr update' again, but I
think it is better than not apply anything in the tree. (Note that this
also effects when we have case insensitivity conflicts, which can never
be applied without conflict).

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

iD8DBQFGudPTJdeBCYSNAAMRAiB9AJ9yLwSvy2moj56ioVglU1Bsts2yKQCfYvP7
l/wlMRct21kk7Z8yqAVbat8=
=DSBH
-----END PGP SIGNATURE-----