Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Hi. In my company, we also have bandwidth problems, but every office has its own repository, containing modules that office is responsible for. In the rare case somebody needs to checkout modules from another office, he simply does a "15 minute" checkout, instead of one office always having to do the full "30 min" one (assuming each office takes care of 50% of the code). > Just think about it a while and you'll see the problems: > - two users have checked out the same file but from different servers > - they get the HEAD which is rev 1.13 > - both edit the file > - both commit almost at the same time and the result is rev 1.14 > - but these edits now carry: > - different edits (they did not do the same thing) > - different timetamps (they are not *exactly* the same) > - different commit user (obviously) > - but the same revision! > > How could this be solved? Well, this is obviously a conflict and I think it can be solved like any version conflict. In your scenario, when the repositories are being synchronised and one of these conflict is detected, the first version that was committed becomes the real "1.4". In fact, all the changes can simply be applied in the order they got committed (obviously, the UTC times of the files are critical). In the case of a real conflict (different changes on the same line of code got committed on both mirrors) you're in trouble. I guess one way to solve this is to keep the file in both repositories with conflict markers. Seeing how little these conflicts actually occur in my company, I think this would still be a worth-while solution. L.