Pytanie o TFS

Cześć, napotkałem problem i nie wiem, jak go rozwiązać.
Sytuacja wygląda tak. Dostajemy kody programu bezpośrednio od producenta. To jest program A w wersji 1.0.

Teraz robimy swoje zmiany i wypuszczamy to jako program B.

Po jakimś czasie producent wypuszcza A w wersji 1.1
I od nowa musimy robić swoje zmiany (co trwa około 2, 3 tygodni), żeby zrobić z tego program B.

Czy można w jakiś sposób współpracować z TFSem tak, że dać mu program A w wersji 1.1, zmergować z naszym programem B i, żeby nasze zmiany nie zostały usunięte?

Wrzućcie wersję A do jednej gałęzi, zróbcie nową gałąź dla wersji B, potem scalajcie.

No to właśnie nie takie proste. Bo jeśli będę chciał scalić A 1.1 z wersją B, to w efekcie część zmian z wersji B zniknie. Ewentualnie będę musiał przeklikać kilka tysięcy plików.

Co znaczy „część zmian z wersji B zniknie”? Musisz przy scalaniu gałęzi A 1.1 do B zadbać o to, żeby nie zniknęło, tutaj nie ma czarów, trzeba porządnie połączyć gałęzie.

U nas jest podobna sytuacja - jest core systemu i wersje przeznaczone dla klientów, zawierające zmiany zrobione specjalnie pod nich. Ponieważ część błędów, optymalizacji i nowych ficzerów robi zespół od core'a, to musimy się regularnie mergować (swojego czasu też przez tfs, teraz już przez git). Jest sposób na niepowodowanie konfliktów - DI z odpowiednią konfiguracją kontenera IoC. Otóż nasze customy lądują w osobnych klasach implementujących te same interfejsy, co klasa do przeznaczona do wprowadzenia customowych zmian i dziedziczących po tej klasie. Nowa klasa jest opatrzona odpowiednim atrybutem, przez co kontener IoC wie, że ma użyć tej klasy w miejsce poprzedniej. W ten sposób nie robimy żadnych zmian w głównym kodzie systemu, a mimo to mamy rzeczy specyficzne dla klientów.

Juhas napisał(a):

Czy można w jakiś sposób współpracować z TFSem tak, że dać mu program A w wersji 1.1, zmergować z naszym programem B i, żeby nasze zmiany nie zostały usunięte?

Wersjonuj w Gicie, zmerdżuj, potem zmiany wypchnij to TFSa korzystając z git-tfs.