Guten Tag Dave Tingling, am Donnerstag, 12. Mai 2011 um 16:26 schrieben Sie:
> 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? Yes. > 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? Using this approach you get to many differences over time and maybe it's too hard to see any correlations to the changes made which result in the freaky file. You only add one line in your commit but the result is that you never repeat the exactly two updates you have with my suggestion. You always have a new file with completely different content and not only to versions of the file. But I'm really only guessing, your problem really sounds strange. > 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. You have to start somewhere. In problems like yours I would suggest running Filemon during the update but the logs surely will get huge and if you manage to get the error itself reproducible somehow running Filemon next time will be of more benefit. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
