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

[Andrew King]

On 8/9/07, John Arbash Meinel <john at arbash-meinel.com> wrote:
> -----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.)
>
Ah, that is, unless your .sln and .csproj files are generated, like ours are :)

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

Yep, guess this would work. We do in fact work in fully distributed
mode, but that "pull" command is so appealing :) People don't like the
fact that the version number tends to do funny things if you merge :(
I told people to ignore that number, but old habits die hard.

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