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?
> 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,
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Received on 2011-05-12 16:41:08 CEST