Matthieu Moy <[EMAIL PROTECTED]> writes: > Mark Triggs <[EMAIL PROTECTED]> writes: > >>> To avoid that, you should use the bookmark missing feature, and merge only >>> patches with the mention [NOT MERGED]. In the case above, this would have >>> indicated Stefan's patch. >> >> Yeah, this is what I've been doing. > > Ah ah, look: > > [EMAIL PROTECTED]
[...] > Look at your patch 103. This is a merge from me or from Masatake. It > was commited the 24th at 6 o'clock. Then comes Stefan's patch, (the > same day at 8 o'clock in the evening) which doesn't merge from you. (I > think he just couldn't because you didn't push your patch-103 on your > mirror when he commited :-( ). Ah yep, that explains it. I was tending to not commit merges immediately to try to batch them together and avoid creating a whole lot of extra patches, but obviously this doesn't work well. So I guess a good policy would be to always commit and push after merging. > However, each problem has a solution : After merging from Stefan, if > you suspect something goes wrong, try to answer the following > question: "What does Stefan have that I haven't?" Hmm, Stefan misses > your patches 103 and 104, but both of them are merges of patches > present in Stefan's archive. Therefore, your tree and his tree should > be the same. Try to tla-changes your tree against his one, the only > two differences should be the logs for your two patches. Yep, this is pretty much what I did yesterday when I noticed duplication. My main concern was what would happen if I didn't notice, but ensuring that all commits get pushed to my mirror should help to avoid this problem (at least, it should make it less likely). Thanks, Mark -- Mark Triggs <[EMAIL PROTECTED]>
