Visual Studio 2008: jak uniknąć piekła scalonego pliku projektu?

Podczas pracy nad projektem VS C# z wieloma programistami, którzy wszyscy dodają nowe projekty i pliki do tego samego rozwiązania, ostatni, który próbuje sprawdzić swoje zmiany, powoduje konflikty w pliku rozwiązania projektu, które nie są łatwe do scalenia .Visual Studio 2008: jak uniknąć piekła scalonego pliku projektu?

Najprostszym rozwiązaniem tego problemu jest odrzucenie moich własnych zmian i zaakceptowanie najnowszej wersji serwera. Potem ponownie włączam moje własne zmiany. W zależności od ilości nowych plików dodanych do projektu może to być łatwe lub bardzo irytujące.

Zastanawiam się, czy jest łatwiejszy sposób na zrobienie tego. Przeczytaj: czy mogę zrobić VS/TFS/merge zrobić to dla mnie?

Źródło

2010-03-16 n3wjack

Co jest trudne o scalanie plików XML? –

Automatyczne scalanie nie jest złe w obsłudze plików projektu w moim odczuciu i oferuje tę opcję dla ciebie (którą obecnie anulujesz!). –

Jak często dodajesz projekty? Dodawanie projektów do rozwiązania nie powinno być codziennym zadaniem, gdy twoja architektura jest układana z góry. Być może powinieneś nawet wprowadzić zasadę, że programiści powinni zapytać starszego programistę lub architekta, czy projekt może zostać dodany. Nawet dodawanie plików powinno być dość rzadkie. – Steven

Moja sugestia to aktualizacja i zatwierdzanie częściej. W szczególności upewnij się, że uruchamiasz program Get Latest przed oczekiwaniem na jakiekolwiek zmiany w pliku rozwiązania.

"Połącz piekło" z takimi obiektami, jak pliki XML i pliki tekstowe (które wszystkie pliki projektów i rozwiązań są) zwykle występuje tylko dlatego, że ludzie próbują zatwierdzić pojedyncze zmiany, które są bardzo duże.

Jeśli masz zwyczaj robienia regularnych zobowiązań, scalenia są zwykle mniejsze, a narzędzia zwykle wykonują perfekcyjną robotę.

Źródło

2010-03-16 16:52:00

Proponuję również, aby zapewnić swoim ludziom wygodne zatrzymywanie i zadawanie pytań, jeśli nie są oni pewni, jak scalić plik rozwiązania. Pracowałem w miejscu, w którym kilka razy w tygodniu musiałbym ręcznie wyczyścić plik rozwiązania, ponieważ ludzie mogliby automerge zamiast sprawdzać wyniki. (A SLN to nie XML). –

@Reed, muszę się nie zgodzić. Czy rzeczywiście uruchomiłeś narzędzie automerge przeciwko plikowi * .sln, w którym dwie osoby dodały nowe projekty? Dosłownie nie ma mowy, aby się to udało z powodu sposobu, w jaki projekty mają przypisane liczby. –

@Richard: Jeśli często aktualizujesz i zatwierdzasz, nie powinno to nigdy nastąpić. Osobiście sprawiam, że mój zespół zawsze aktualizuje się przed zatwierdzeniem. Osobiście uważam, że nowy projekt, który zostanie dodany, powinien być zobowiązaniem całościowym. Oznacza to, że aktualizujesz, zatwierdzasz wszelkie zmiany. Następnie dodaj swój projekt i zatwierdź go. Zasadniczo, NIGDY nie powinieneś mieć dwóch "nowych" projektów do scalenia, chyba że dwie osoby spróbują dodać nowy projekt w ciągu tych samych kilku minut (bardzo mało prawdopodobne) ... –

Nigdy nie dodaję plików do rozwiązania, tylko projekty. Jeśli chcesz dodać pliki, dodaj je do projektu.

Jeśli nie chcesz scalać, alternatywą jest, jeśli ktoś sprawdzi w rozwiązaniu z nowym projektem, następnie wycofaj projekt i rozwiązanie, nadpisując własny plik rozwiązania, a następnie dodaj projekt ponownie rozwiązanie i sprawdź to z powrotem. Teraz rozwiązanie ma zarówno swój projekt, jak i twój.

Źródło

2010-03-16 16:54:16 AaronLS

Niektóre pliki są fajne, aby mieć jedno rozwiązanie jako odniesienie. Przykłady, z których korzystałem w przeszłości, to zespoły stron trzecich, silne klucze nazw, uwagi ogólne i współużytkowane pliki konfiguracyjne. –

Umieszczam je w pustym projekcie. Problem polega na tym, że foldery "wirtualne" używane przez rozwiązania mogą powodować niespójności między maszynami. Po sprawdzeniu rozwiązania i plików na innym komputerze mogą one nie być w tej samej względnej strukturze katalogów, które były dla programisty, który dodał pliki. Rozwiązania pozwalają również na odniesienia do plików takich jak ".. \ .. \ OutsideFolder", które mogą powodować spustoszenie, gdy inny programista próbuje pobrać rozwiązanie z kontroli źródła. – AaronLS

Zgadzam się z aaronis, że trzeba uważać na względne ścieżki. Jednak jest całkiem normalne dodawanie zestawów firm trzecich do rozwiązania, jak wyjaśnia Matthew. Zawsze tworzę katalog o nazwie "Shared Assemblies" dla biblioteki DLL innej firmy w katalogu rozwiązania i tworzę folder rozwiązania o tej samej nazwie. W ten sposób nigdy nie mam żadnego z problemów opisanych przez aaronis. – Steven

Jedna sugestia, aby dodać do puli komentarzy ...

Praca na zminimalizowaniu zmiany wprowadzone w pliku SLN kiedy popełnić, aby ułatwić innym scalić.

(Oczywiście to samo dotyczy również innych).

Aby zilustrować, zakładamy, że plik SLN obecnie wymienia cztery projekty:

SLN: A, B, C, D

Ty i współpracownik zarówno dokonać zmian. Dodasz projekt e, plus (z jakiegoś powodu) rzeczy się następującą kolejność:

Yours: A, E, D, C, B

współpracowników Zmiany dotyczą dodawania projektu F:

Co-Worker: A, B, C, D, F

Jeśli swoje zmiany, jak jest, to swoje CO -worker musi połączyć te dwa:

SLN: A, E, D, C, B 
Co-Worker: A, B, C, D, F

Nasty.

Zamiast tego, jeśli (ostrożnie!) Pracować, aby zminimalizować swoje różnice, można dokonać kopia robocza wyglądać następująco:

Yours: A, B, C, D, E

W tym przypadku, gdy współpracownik musi łączyć, będą musieli zmierzyć się z tym:

SLN: A, B, C, D, E 
Co-Worker: A, B, C, D, F

Znacznie łatwiej scalić.

Źródło

2010-03-17 21:01:02 Bevan

Ja też miałem dość problemów z połączeniem z plikami projektu. (W pewnym momencie starałem się rozwiązać 9000+ konfliktów w jednym pliku projektu.)

Więc zrobiłem coś o tym: http://www.projectmerge.com

Choć zaczynał jako plik projektu porównać/scalić narzędzie, szybko ewoluował w coś, co może porównywać i łączyć dowolny plik XML.

Mam nadzieję, że okaże się przydatny.

Źródło

2010-08-14 15:03:03

Zrobiłem narzędzie, które służy do porównywania/scalania pliku rozwiązania (i może być również używane do dynamicznego tworzenia filtrowanego rozwiązania).

Można go znaleźć pod adresem: http://slntools.codeplex.com/

Źródło

2010-09-02 17:27:53

Wow, dzięki, spróbuję tego. Życz mi szczęścia! – toddmo

Właśnie uratowałem mi dużo headbanging. Dzięki :) –

Visual Studio 2008: jak uniknąć piekła scalonego pliku projektu?

Odpowiedz

Powiązane problemy