Pracuję w instytucji rządowej. Stosowana tutaj technologia i metody tworzenia oprogramowania są dość staromodne.

Mają mnóstwo miejsca do przechowywania, ale nie mają odpowiedniego miejsca do przechowywania i utrzymywania aplikacji służących do automatyzacji większości prac w tym miejscu.

Instytucja nie zezwala mi na używanie oprogramowania SCM, takiego jak GIT lub SVN.

Jakie byłoby najlepsze podejście do zachowania jakości kodu i późniejszego dodawania nowych funkcji do aplikacji?

Jak mogę zapamiętać zmiany, które wprowadziłem do kodu bez jego łamania?

EDYCJA: Zapomniałem wspomnieć, że mają dyski sieciowe dla każdego z komputerów i jakoś te dyski sieciowe tworzą lub zapisują kopie zapasowe w okresach. Jeśli jednak nie utworzę własnego planu, który pozwala zapisać moją pracę i móc dodawać nowe funkcje bez zepsucia istniejącego kodu, nie ma dużej przewagi nad rozwiązaniem SCM.

EDYCJA: Ponieważ wiele osób sugerowało przenośny Git, muszę dodać więcej informacji. Próbowałem zainstalować serwer Visual SVN, ale nie powiodło się, ponieważ nie mam uprawnień administratora do zainstalowania. Próbowałem również pobrać zwykłą powłokę Git, ale zapora sieciowa lub ustawienia sieciowe nie pozwoliły mi uzyskać dostępu do strony pobierania Git. Próbowałem nawet, wysyłając przenośnego Gita na mój e-mail, którym jest Gmail. Google wykryło plik exe w pakiecie, a także nie pozwolił mi pobrać przenośnej wersji Git na mój komputer służbowy. Inną rzeczą, o której muszę wspomnieć, zasady sieci stosowane do komputerów w instytucji nie pozwalają na korzystanie z urządzeń pamięci USB. Porty USB można wykorzystać do ładowania smartfona lub zasilania niektórych gadżetów, takich jak małe głośniki. Jak niektórzy wspomnieli, są komputery, na których nawet Internet nie jest dozwolony.

Możesz swobodnie powielić rolę, jaką odgrywa kontrola źródła za pomocą trzech prostych narzędzi:

• Oprogramowanie do tworzenia kopii zapasowych (zatwierdzenia / zameldowania)
• Foldery (oddziały)
• Przeprowadzanie łączenia katalogów między dwoma katalogami za pomocą narzędzia takiego jak KDiff3 (Scalanie gałęzi)

Zasadniczo Twój przepływ pracy wygląda następująco:

1. Utwórz nowy folder (nowy oddział)
2. Skopiuj pliki do nowego folderu (nowy oddział) z istniejącego folderu (istniejący oddział)
3. Utwórz kopię zapasową tego folderu (zakończ tworzenie nowego oddziału)
4. Popracuj trochę
5. Utwórz kopię zapasową nowego folderu (zatwierdzenie)
6. Wykonaj scalanie katalogu z jednego folderu do drugiego (scalanie)
7. Wykonaj kolejną kopię zapasową w innym folderze (dokonaj scalenia)

Bardziej monolityczne systemy kontroli źródła, takie jak SVN lub TFS, w zasadzie robią to za kulisami.

W rzeczywistości wygląda to tak, jakby firma autobusowa mówiła swoim kierowcom, że nie mogą prowadzić autobusów z akumulatorem, zmuszając kierowców do zepchnięcia autobusu ze wzgórza, a następnie wciśnięcia sprzęgła, aby uruchomić autobus ... to straszne i wskazuje, że obecne kierownictwo nie wie nic o prowadzeniu garażu autobusowego. Moje kondolencje.

Ale przynajmniej możesz uruchomić autobus.

Chociaż konsensus byłby z pewnością nie pracować dla tej firmy , nie sądzę, że tak naprawdę odpowiada na twoje pytanie.

Naprawdę nie możesz zastąpić SCM .

Możesz nie potrzebować zwykłych dzwonków i gwizdów pełnego systemu. Na przykład firma może odrzucić żądanie serwera, ale zezwolić na użycie lokalnego SCM. Mogą nie lubić git, ale zezwalają na subwersję (lub inny system kontroli wersji).

Jest oczywiście pytanie: z czego korzystają Twoi koledzy lub inni pracownicy? Jeśli jesteś pierwszym programistą, którego mają, nadszedł czas, aby bardzo mocno naciskać na potrzebne zasoby.

W końcu, jeśli twoja firma nie szanuje twojej roli i doświadczenia i nie pozwoli ci na narzędzia, których potrzebujesz, wtedy napotkasz jeszcze gorsze (i bardziej stresujące) problemy niż brak kontroli źródła.

Zasadniczo istnieje problem z zarządzaniem (Twoja organizacja nie rozumie podstaw procesu tworzenia oprogramowania , np. Model V ), powodujący niemożność korzystania z minimalnego przepływu pracy, metodologii i narzędzi z obecnej epoki. Jest to powszechne (czytaj o zasadzie Piotra ).

^{BTW, myślę, że niedawny incydent kolejowy SNCF w Paryżu pod koniec 2017 r. Ma podobną przyczynę (całkowity brak kultury oprogramowania na wysokim szczeblu zarządzania, a zatem blokada głównego dworca kolejowego w Paryżu na dłużej niż jeden dzień; oczywiście są bardzo kompetentni Zespoły IT w SNCF, ale nie są konsultowane przy podejmowaniu ważnych decyzji). Potrafię wymienić kilka europejskich branż z całkowitym brakiem kultury oprogramowania i na pewno będę w stanie znaleźć podobne rzeczy nawet w USA.}

Główny problem brzmi: czy pracujesz sam na bazie kodu, czy współpracujesz z kolegami?

Jeśli pracujesz sam, możesz używać git lokalnie na swoim komputerze i .gitokresowo tworzyć kopie zapasowe swojego kodu (i prawdopodobnie nawet repozytorium) (do tego zewnętrznego miejsca do przechowywania). Pamiętaj, aby nigdy nie stracić więcej niż pół dnia pracy (więc wykonuj kopie zapasowe danych okresowo i niezawodnie).

^{(Przypuszczam, że znasz przynajmniej jedno giti svnże znasz wyższość techniczną git; jeśli nie możesz nawet zainstalować narzędzia takiego jak gitna komputerze w pracy, musisz poważnie porozmawiać z szefem na ten temat: potrzebujesz zdolność i autoryzacja do instalowania zewnętrznych narzędzi open source (i to odpowiada za ich wybór, konfigurację i instalację mądrze i ostrożnie oraz bez znanych słabych punktów )}

Jeśli pracujesz z kilkoma kolegami (wydaje mi się, że jest ich mniej niż tuzin), musisz przekonać wszystkich do korzystania z systemu kontroli wersji i prawdopodobnie musisz o tym powiedzieć swojemu bezpośredniemu (i zwykłemu) szefowi. Mógł (prawdopodobnie) zdecydować (lub po prostu domyślnie zaakceptować), że jakaś maszyna (być może nawet stary pulpit, może nawet własny pulpit) jest używana jako serwer git. Absolutnie musisz skonfigurować ten serwer, aby kopia zapasowa git była tworzona co najmniej co godzinę; nie możesz sobie pozwolić (i musisz porozmawiać z szefem) o utratę ponad godziny pracy swojego zespołu.

^{BTW, uwielbiam Linuksa i polecam zainstalowanie Linuksa na maszynie działającej jako gitserwer; wtedy instalowanie giti konfigurowanie okresowych kopii zapasowych (z pewnymi crontabzadaniami) jest bardzo łatwe; zwróć uwagę, że gitserwer może uruchamiać Linuksa przy użyciu klientów Windows. Sugerowałbym nawet, abyś mógł zmienić swoją maszynę programistyczną na Linux. Jest „tańszy” i znacznie bardziej przyjazny dla programistów}

Ale musisz użyć SCM. Możesz zadać swojemu szefowi inne pytanie: czy Twój zespół powinien użyć istniejącego SCM, czy powinien wynaleźć koło i stworzyć własny SCM? Szefowie są generalnie przeciwni pomysłowi wynalezienia koła. Jeśli możesz wymyślić koło na nowo, powiedz swojemu szefowi, że jest to praca na pełny etat przez co najmniej rok (to prawdopodobnie sprawi, że twój szef będzie płakał, a następnie zaakceptuje oczywisty sposób) i baw się dobrze, tworząc własny SCM. W takim mało prawdopodobnym przypadku należy przestudiować istniejące systemy SCM i poprosić o uczynienie z systemu SCM jakiegoś bezpłatnego oprogramowania (do wykorzystania i ulepszania przez inne zespoły).

Być może trzeba przygotować (w ciągu kilku dni) to precyzyjne i konkretne argumenty za potrzebie SCM : najpierw dla swoich kolegów, a następnie do bezpośredniego szefa. Pamiętaj również o zaproponowaniu konkretnych rozwiązań (takich jak uruchamianie serwera git na komputerze stacjonarnym lub innym „starym” serwerze i tworzenie kopii zapasowej co godzinę przez crontabzadanie)

Nie instaluj żadnego oprogramowania (z zewnątrz, nawet typu open source) na swoim komputerze służbowym bez pozwolenia (w większości krajów, szczególnie w przypadku delikatnej pracy IT dla państwa, instalowanie oprogramowania bez pozwolenia jest prawnie przestępstwem, a możesz stracić swoje pracę lub pójść do więzienia, jeśli to zrobisz ... więc upewnij się, że masz do tego prawo; być może zakryj swoją dupę, prosząc o pozwolenie na piśmie lub przynajmniej pocztą elektroniczną).

^{(albo będziesz musiał pytać indywidualnie dla każdego przypadku, albo musisz uzyskać zaufanie od swojej organizacji, aby zezwolić na instalację dowolnego legalnego oprogramowania - głównie oprogramowania typu open source lub wolnego oprogramowania - na komputerze służbowym).}

PS. Jak technicznie zbudować, skonfigurować, zainstalować, a następnie użyćgit (z kodu źródłowego darmowego oprogramowania) - lub większości innych darmowych programów VCS - na maszynie (nawet bez pozwolenia administratora) to zupełnie inne pytanie (zadane gdzie indziej). Możliwe jest zainstalowanie, a następnie użycie gitbez pozwolenia administratora, pod warunkiem, że masz wystarczającą ilość zasobów (czas, miejsce na dysku, kompilator C itp.).

Próbowałem zainstalować serwer Visual SVN, ale nie powiodło się, ponieważ nie mam uprawnień administratora do zainstalowania.

To jest rozwiązywalne przez jakiegoś konkretnego konfiguracji i kompilacji twojego gitlub svnz wolnego oprogramowania kodu źródłowego gitlub Subversion -nie tylko binarny PAKIET (a także kodu źródłowego z zależnościami ); jak to zrobić technicznie, to inne pytanie (ale takie pytania techniczne powinny znaleźć się w innym miejscu). Oczywiście powinieneś poprosić o pozwolenie (od swojego szefa) na skompilowanie kodu źródłowego gitprzed zrobieniem tego. Powie ci lub omówisz z nim praktyczne szczegóły (jeśli zaakceptuje takie rozwiązanie) dotyczące przenoszenia tego kodu źródłowego z zewnątrz na komputer w pracy.

Pierwszą rzeczą, którą chciałbym zrobić, to konkretnie określić, czemu sprzeciwia się agencja rządowa (prawdopodobnie dział IT). Jeśli mają miejsce do przechowywania, ale nie ma możliwości hostowania maszyn wirtualnych dla serwerów, problem może być taki, że dział IT odmawia serwerowi SVN lub GIT i to jest duże rozróżnienie. Jeśli problemem jest kraj pochodzenia - tzn. Nie ufamy narzędziom tworzonym przez podmioty zagraniczne - to jest inny problem.

Możesz uruchomić GIT całkowicie w systemie plików, co zrobiłem przy małych projektach, zanim będę gotów cokolwiek z nimi zrobić. GIT nie wymaga również uprawnień administratora do instalacji.

Jeśli absolutnie nie możesz używać Gita z jakiegokolwiek powodu, masz do dyspozycji kilka opcji:

• Edukacja: nie zezwalając na kontrolę wersji, wprowadzają znaczne ryzyko. Potrzebujesz możliwości wycofania się ze zmian, które okazują się bardziej problematyczne. Potrzebujesz możliwości zaoszczędzenia pieniędzy i czasu, a SCM to robi. Musisz być w stanie jasno wyjaśnić, w jaki sposób. Prawdopodobnie musisz również przeprowadzić analizę alternatyw, aby naprawdę osiągnąć cel.
  • Jedną alternatywą byłby hosting Git
  • Kolejny system plików Git
  • Wybierz co najmniej jedno, ale nie więcej niż dwa alternatywne narzędzia SCM
  • i wreszcie, jak to jest pracować bez kontroli wersji
• Idź rozwój 70s era: Jest powód, że patchi diffzostały wykonane tak dawno temu (80 lat). Były to technologie umożliwiające kontrolę wersji.

Jak wygląda rozwój w latach 70.? To nie jest ładne, ale tak zaczęliśmy. Aplikacje były znacznie mniejsze. Zasadniczo mieli kilka wspólnych rzeczy:

• Była koncepcja złotego standardu . To był główny kod źródłowy z kompletnymi funkcjami.
• Był zespół ds. Zarządzania konfiguracją (CM). Ich zadaniem było prawidłowe wprowadzenie zmian z rozwoju w złoty standard. Tutaj potrzebujesz patchi diffzastąpić zespół.
• Pracowałeś z lokalnej kopii kodu źródłowego. Zakończysz funkcję w całości i prześlesz ją do zespołu CM w celu integracji. Zwykle jest dokument towarzyszący, dzięki czemu tworzone są nowe pliki, a przestarzałe pliki są usuwane itp.
• Następnie naprawiasz wszelkie błędy z procesu integracji.
• Zanim będziesz mógł zająć się inną funkcją lub poprawką, otrzymasz nową kopię złotego standardu.

Zasadniczo jest to proces podatny na błędy, który ma wiele potencjalnych przyczyn niepowodzenia. Pomysł „rozgałęzienia” jest łatwy do wdrożenia, ale koszmar do zarządzania. Głównym problemem jest to, że gdy masz zbyt wiele kopii kodu źródłowego, trudno jest zrozumieć, jaki jest właściwy poziom bazowy dla produkcji. Ze względów praktycznych musisz być jednowątkowy.

Oto, co musisz uwzględnić w swojej analizie alternatyw.

Biorąc pod uwagę ograniczenia, o których wspomniałeś w komentarzach (np .: nie mogę dostać się do strony pobierania Gita, platformy Windows i programu Visual Studio 2005), widzę 2 opcje, z których obie korzystałem wcześniej w podobnej sytuacji:

1. Użyj Visual SourceSafe, jak sugeruje Emerson w komentarzu. Kilka lat temu współpracowałem z zespołem korzystającym z VS 2005, podczas gdy większość reszty firmy używała standardowej kontroli wersji w systemie Linux / Unix i chętnie korzystali z Visual SourceSafe dla swoich CM. W tym momencie jest dość staromodny, ale lepszy niż nic.
2. Mówiąc o czymś lepszym niż nic, sam byłem w podobnej sytuacji. Jeśli nie możesz nawet użyć VSS (być może wtyczka nie jest zainstalowana?), A ponieważ mówisz, że jest dużo dostępnej przestrzeni dyskowej, mam nadzieję, że możesz z niej korzystać. Zaimplementowałem ręczny protokół kontroli wersji oparty na plikach. Pod koniec każdego dnia roboczego kopiowałem bazę kodu do nowego katalogu z datą. Gdybym musiał powrócić do poprzedniej pracy (lub wycofać), spojrzałbym na poprzednie katalogi z datami, aby znaleźć potrzebną zmianę. Ponieważ masz program Visual Studio, w ciągu kilku godzin prawdopodobnie możesz użyć VS 2005 do napisania prostego narzędzia, które pomoże zautomatyzować tworzenie katalogu i kopiowanie plików.

Mają mnóstwo miejsca do przechowywania

Czy możesz używać go według własnego uznania?

Jeśli tak, możesz utworzyć zdalne repozytorium systemu plików, które jest lepsze niż nic. Minusem jest to, że pchanie staje się powolne, gdy projekt się rozwija, ponieważ gitmusi pobrać całe repozytorium, aby wyszukać zmiany ...

jak dotąd komputery zachowują się jak zwykli użytkownicy, co zabrania mi instalowania oprogramowania innych firm.

gitjest również przenośną aplikacją, dzięki czemu można ją zainstalować na ścieżce $ HOME lub% USERPROFILE%.

Podsumowując: nie pozwolę im zabronić używania SCM ¹ . Użyłbym tego „prywatnie”. W końcu nikt nie jest w stanie stwierdzić, czy Twój kod został opracowany z zameldowaniem, czy bez niego ...

¹ ) kiedy zacząłem używać gitkilka lat temu, mój klient wolał inny SCM, który był dość powolny i zawodny (co jest w końcu czymś w rodzaju NOGO dla SCM (o;). Użyłem git„prywatnie” nad innym SCM ze zdalnym „opartym na plikach” w udziale sieciowym i zalogowanym do SCM dopiero po wydaniu nowej wersji produktu.

Twoje środowisko

Przede wszystkim nie byłbym tak pesymistyczny, jak pokazano w wielu komentarzach i odpowiedziach. Tak, to jest „epoka kamienia łupanego”, ale są znacznie gorsze okoliczności. Jeśli twoje ogólne środowisko pracy (koledzy, lokalizacja, wynagrodzenie, ciekawe prace programistyczne itp.) Jest w porządku i według twojego gustu, to zdecydowanie trzymaj się tego. Jeśli chodzi o IT, to jest to, czym jest. Dzieje się tak nie tylko w agencjach rządowych, ale także w bankowości, ubezpieczeniach lub wszędzie tam, gdzie bardzo duży nacisk kładziony jest na bezpieczeństwo lub bardzo stare struktury.

Włożenie pamięci USB i uruchomienie pliku .exe z tego miejsca byłoby bezpośrednią przyczyną zakończenia w innych miejscach, więc nie sugeruję, abyś próbował cokolwiek obchodzić.

Spróbuj jeszcze raz git

Teraz do wyboru. Zdecydowanie poleciłbym dla ciebie git zamiast svn. Jeśli i tak wykonujesz projekty jednoosobowe, to git to tylko lokalny katalog .gitw katalogu głównym aplikacji, nic więcej.

Nie proś szefa / IT o „SCM”, ale poproś go o zainstalowanie go gitna twoim komputerze, abyś mógł rozwijać się szybciej i mieć wyższą jakość. Wyjaśnij im, że nie chcesz wypychać kodu w inne miejsce, że nie potrzebujesz serwera działającego gdzieś i że nie zużyje on znacznej ilości miejsca lub czasu na konserwację.

Git zwiększy dla ciebie szybkość i jakość po prostu dlatego, że możesz pracować z większą pewnością (ponieważ możesz cofnąć wszelkie dokonane zmiany) i pozwolić ci pracować na wielu gałęziach jednocześnie. To znaczy, jeśli pracujesz nad dużym zadaniem i pojawia się coś, co wymaga twojej natychmiastowej uwagi, możesz po prostu przejść do nowej gałęzi, szybko to naprawić, a następnie powrócić do zadania długotrwałego.

Robi to ręcznie

Jeśli po prostu nie jest to w ogóle możliwe, możesz oczywiście wykonać ręczną kontrolę źródła. Utwórz ręczne „tagi”, samodzielnie kopiując kod (może utwórz nowy katalog z datą / godziną i krótkim opisem zmian). Prowadź dziennik zmian z szczegółowymi listami nie tylko twoich zmian, ale także plików, które zmieniłeś, a może nawet więcej szczegółów.

Utwórz „gałęzie”, ponownie kopiując swoją pracę, a kiedy nadejdzie czas ponownego scalenia, kreatywności za pomocą dowolnych narzędzi „diff” lub „diff3” - nie wiem, czy masz jakieś dostępne, musisz dowiedzieć się.

Jeśli to wszystko kosztuje dużo czasu, dobrze przyjrzyj się, czy naprawdę warto emulować SCM. Jeśli okaże się, że jest tego warta, a następnie porozmawiać z szefem ponownie. Pokaż mu zalety ręcznego SCM (nie tylko „Mam kopię całej mojej starej pracy”, ale „kiedy wystąpił błąd XYZ, natychmiast znalazłem przyczynę, 5 wydań temu”). Następnie powiedz im, o ile szybciej to będzie git.

Oczywiście, jeśli doprowadza cię to do szaleństwa, zawsze możesz znaleźć pracę.

Myślę, że wielu osobom brakuje tutaj „instytucji rządowej” tego pytania. Niektóre sieci rządowe mają bardzo surowe przepisy dotyczące dozwolonego oprogramowania, a łamanie tych zasad jest przestępstwem ogniowym, a może nawet kryminalnym. Przekazałbym to przez zarządzanie, aby zobaczyć, czy możesz uzyskać ZATWIERDZONY ruch po zainstalowaniu oprogramowania. Nie chciałbym zostać kowbojem i sam zainstalować rzeczy. Jeśli korzystasz z systemu Linux / UNIX, sprawdź, czy są zainstalowane RCS (polecenia ci / co) lub SCCS (polecenie sccs). Są to stare narzędzia SCM, które były dość standardowe. To nie jest ładne, ale lepsze niż to, co zamierzam napisać poniżej. :)

Ponieważ masz „dużo” miejsca na dysku, utwórz drzewo źródłowe. Jakie są podstawy SCM na małą skalę? Będąc w stanie rejestrować zmiany, sprawdzać, co się zmieniło, oznaczać rzeczy i w razie potrzeby wrócić do starych wersji. Jeden poziom powyżej drzewa źródłowego, utwórz plik Makefile lub skrypty, w zależności od tego, co masz dostępne, które wykonują następujące czynności (są to wersje o smaku Linux / UNIX, polecenia Windows byłyby inne)

make checkin - cp -a source-tree-source-tree-date (przynajmniej do minuty, jeśli nie druga, na przykład source-tree-20171205115433)

make status - diff -R źródło-drzewo źródło-drzewo-data | mniej (byłaby tu trochę logiki, domyślnie jest to najnowsza kopia zapasowa lub podaje argument, aby odróżnić się od wersji

make tag - ln -s source-tree-date release1.0 (link do konkretnej wersji)

make revert - rm -r źródło-drzewo && cp -a drzewo-źródło-data źródło-drzewo

Sprzedaj im to

Zostawiłeś ten komentarz :

Mają dysk sieciowy, który nie wiem jak, ale tworzy kopie zapasowe w okresach. Tak. Korzystam z niego i przechowuję tam moje aplikacje.

Idź do przełożonego i powiedz coś w tym duchu:

Szefie, zauważyłem, że mamy system, w którym umieszczamy aplikacje na dysku sieciowym, a jakaś usługa tworzy kopie zapasowe i śledzi historię. Wydaje mi się, że właśnie wdrażamy nasz własny system kontroli źródła. Prawdopodobnie moglibyśmy zwolnić dużo miejsca i uprościć cały system, przechodząc do dedykowanego systemu zarządzania kontrolą źródła, takiego jak SVN lub git. Dostalibyśmy wiele korzyści: prostsze kopie zapasowe wersji historycznych, narzędzia do zrozumienia, jakie zmiany wprowadzono w plikach w czasie (bardzo przydatne informacje do debugowania), łatwiejsze sposoby cofania błędów i łatwiejsze łączenie zmian różnych osób.

Użyłem tego rodzaju systemów już wcześniej i są one bardzo dobre w wykonywaniu zadań niestandardowej konfiguracji. O wiele trudniej jest popełnić z nimi błędy niż w naszym obecnym systemie. Są to również bardzo dojrzałe i szeroko stosowane technologie; narzędzia te są szeroko stosowane od ponad 20 lat. Co więcej, możemy korzystać z najpopularniejszego oprogramowania, nie płacąc ani grosza za licencję.

Z przyjemnością pomogę wybrać klienta i serwer oraz je skonfigurować. Spodziewam się, że [insert estimate here]zainstalowanie go zajmie tylko godziny, jeśli zdobędę maszynę. Zrobiłaby to każda maszyna, nawet stary pulpit, który miał zostać wycofany, pod warunkiem, że będziemy mogli uzyskać do niego dostęp przez sieć.

Podsumowanie na wysokim poziomie jest takie, że musisz je sformułować w sposób zrozumiały i prawdopodobnie uważają, że warto:

• Uwalnianie zasobów (sprzętu i ludzi) do innych celów
• Niższe ryzyko (błąd ludzki, stabilna technologia)
• Zwiększona produktywność
• Mały koszt wdrożenia

Twoi przełożeni nie są ludźmi technicznymi i nie dbają o problemy techniczne. Ale jeśli potrafisz rozwiązać problem w kategoriach pieniędzy i rzeczy, które kosztują pieniądze, ich uszy mogą nieco ożywić.

Po przeczytaniu pytania i wielu komentarzy zrozumiałem, że masz następujące ograniczenia / scenariusz:

• 1 osoba na projekt;
• po prostu nie możesz używać zewnętrznych narzędzi innych niż Visual Studio 2005 do swojego projektu; nie możesz używać GIT ani żadnego innego SCM;
• pracując lokalnie, nie możesz pozwolić, aby projekt był w stanie zepsutym, ponieważ od czasu do czasu masz automatyczne kopie zapasowe i musisz cały czas działać;
• potrzebujesz historii, aby śledzić zmiany;

Jeśli nie możesz użyć Visual Source Safe (który ma wtyczkę do pracy z VS 2005), możesz zastosować inne podejście.

W oparciu o powyższe elementy sugeruję uporządkowanie folderów projektu, takich jak poniżej:

trunk           //last functional version of the app. IMPORTANT: YOU DON'T WORK WITH THIS FOLDER
    UnitTests   //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln
temp              //your working folder; has structure similar to trunk; changes will be commited to trunk;
    UnitTests     //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln  
build
    .history    //folder to contain changes in files and your comment (like commits in git)
    build.bat   //calls MSBuild to build temp\YourProject.sln, and run all unit tests
    save_on_trunk.bat   //if build is working, saves info from "diff.bat" in folder within ".history" with timestamp, and also overrides "trunk" with content from "temp"
    diff.bat         //compares files from "temp" and "trunk", using "dir" and "fc" commands
    history.bat  //outputs content from .history folder (contains file changes and comments)

Podstawowe zasady, których należy przestrzegać tutaj:

• kontrola kodu będzie wykonywana w folderze projektu;
• nigdy nie pracujesz w „bagażniku”;
• pracujesz w „temp” , wdrażasz testy jednostkowe , wywołujesz build.bat , a następnie save_on_trunk.bat ;
• WAŻNE: wdrażaj testy jednostkowe, które działają w całkowitej izolacji; potrzebujesz tego, aby zagwarantować, że nowy kod nie zepsuje łącza;
• ponieważ masz automatyczne kopie zapasowe, szanse na utratę kodu będą mniejsze; dlatego wystarczy, aby kod „trunk” był cały czas w stanie roboczym.

Skończyły Ci się rozwiązania techniczne. Pozostają tylko rozwiązania polityczne.

1) Unionize the developers. Jeśli istnieje już związek zawodowy, kwestionuj jego pozycję jako nieuczciwego reprezentowania klasy pracownika, który jest programistą. Jeśli utworzenie związku programistów nie uzyska poparcia połowy programistów, GO. Jesteś w złym stanie.

2) Reklama w gazecie. Jeśli twój rząd nie zagwarantuje wolności słowa jako uznanej kwestii prawnej, spowoduje to zwolnienie z pracy.

Git dla Windows ma wersję „przenośną” . Możesz skopiować to na komputer lub zachować na karcie pamięci, bez potrzeby instalowania czegokolwiek. Jeśli problemem jest po prostu instalacja, byłoby to obejście.

Zwróć uwagę, że jeśli są zdecydowanie przeciwni SCM, możesz zadać spytane pytania dotyczące ISO-9001, DO-178B lub innych odpowiednich standardów opracowywania oprogramowania.

Po prostu uruchom git na czystym katalogu, bez żadnego serwera. Nie ma znaczenia, że ​​nikt inny nie używa kontroli wersji, ponieważ możesz kontrolować wersję swojego katalogu. Git został zaprojektowany specjalnie dla tego nieuczciwego scenariusza wprowadzenia SCM i działa dobrze.

Staniesz się bohaterem, gdy druga osoba zacznie go używać, nawet jeśli musisz poczekać, aż jakiś dinozaur wyrzuci wiadro, aby się rozprzestrzenił. Zarządzanie dużymi bazami kodu bez SCM jest teraz niekompetencją. Właściwie to jak prowadzenie firmy bez audytu.

Istnieją trzy rzeczy, na które chciałbyś nalegać jako profesjonalny programista: recenzje kodów, historia wersji i żądania zmian śledzenia.

Możesz samodzielnie śledzić żądania zmian. Nie tak fajnie, jak w przypadku odpowiednich narzędzi, ale możesz. Druga część to recenzje kodu. W tym celu potrzebujesz poprzedniej kopii kodu i narzędzia różnicowego. Gdy uważasz, że zmiana jest gotowa, przejrzyj ją samodzielnie, porównując ostrożnie z poprzednią wersją, a następnie zastąp poprzednią nową.

Do kontroli wersji, jeśli twoje miejsce pracy nie pozwala na żadne przyzwoite rozwiązanie, potrzebujesz pudełka z zapisywalnymi płytami DVD. Za każdym razem, gdy masz wersję, do której chcesz wrócić, tworzysz nową płytę DVD.

(Oczywiście to wszystko nie jest wskazówką, którą należy przyjąć, chyba że znajdujesz się w naprawdę złym miejscu pracy, takim jak PO).