Thorsten Schöning wrote:
I would try to test a bit: Take a dev where the file never was freaky
and let him produce small changes which are committable, e.g. add a
newline at the end of the file and remove it or stuff like that. But
it should be always the same changes.
We will. Let me make sure I understand you: you're suggesting testing
multiple commits, but each consecutive commit will be an "undoing" of
the previous change. If that's true, after many many commits, I have
only ever really committed two different variations of the file, in
alternation. Is that what you intend?
Assuming I understood you correctly above, would there be any value if I
commit a completely new change to the same file each time, perhaps (for
agument's sake) adding a new, predictable, unique line to the file? I
would add the numeral '1' as line one, then next time add the numeral
'2' as line 2, etc etc. always appending. What do you think?
After each change let your
problematic developer N update the file and see if the error happens
and if it always results in the same wrong changes.
Understood. Just to clarify our situation, there no single one
problematic developer (nor file, for that matter). This could happen to
anyone of the team---when some random person updates, a file is "wrong".
It could be any one developer, any file.
I can't believe the error is in the subversion code, sounds more like
a client problem to me. Client side scripts, programs locking the file
and all that kind of stuff.
We are inclined to agree. Will proceed to test. Thanks very much.
-Dave
