ClearCase chce scalić niezmienione pliki po dostarczeniu do alternatywnego celu
Korzystając z Rational ClearCase v. 7.0.1.1 z UCM, mam problem z używaniem funkcji ClearCase „Deliver from Stream to Alternate Target”.
Wyobraź sobie, że mamy jeden strumień integracji projektu i dwa strumienie programistyczne A i B z niego pochodzące. Teraz zmieniam plik w strumieniu A. Chcę, aby delevoper będący właścicielem strumienia B mógł korzystać z mojej pracy bez konieczności dostarczania pliku do strumienia integracji, więc dostarczam ze strumienia A do alternatywnego strumienia docelowego B.
Jak na razie dobrze. Wykonuję kolejną zmianę w pliku, ale programista strumienia B nie potrzebuje tej zmiany, więc nie dostarczam go do niego.
Po pewnym czasie dostarczam swoją pracę do głównego strumienia integracji. Działa to dobrze, chociaż zastanawiam się, dlaczego ClearCase oznacza scalanie jako normalne „Połączone” zamiast „Połączone (trywialne)” - nikt oprócz mnie nie wprowadził zmian w pliku.
Po dostarczeniu tworzona jest nowa linia bazowa w głównym strumieniu integracji.
Prawdziwy problem pojawia się, gdy programista B próbuje ponownie obsadzić swój strumień. Ponieważ deweloper B nigdy nie wprowadził żadnych zmian w pliku, spodziewałbym się, że scalenie będzie trywialne bez konieczności interakcji. Ale to, co się dzieje, jest takie, że programista B jest zmuszony graficznie rozwiązać konflikt scalania w tym pliku, pozwalając mu wybrać pomiędzy wersją bazową w strumieniu integracji, wersją, którą mu dostarczyłem, a wersją, którą dostarczyłem do strumienia integracji.
Zamieszanie pojawia się, gdy po rozwiązaniu scalenia i zakończeniu rebase, deweloper B chce wykonać dostawę do głównego strumienia integracji. Oprócz działalności, którą pierwotnie mu dostarczyłem, oferuje on również usługę o nazwie rebase _..., której nigdy nie spodziewałbym się zaoferować do realizacji.
Czy coś mi umyka? Czy używamy ClearCase nieprawidłowo, czy jest to znane ograniczenie / błąd? Czy ktoś doświadczył tej funkcji?
Z góry dziękuje za twoją pomoc!
Jan