Source Safe проблем
3 отговора
247 прегледа
Source Safe проблем
Ситуация: почвате да правите промяна на програмата, за което ви е нужно примерно седмица. На втория ден идва шефа и казва - аа открих един бъг, оправи го.
Проблемът: вече сте изменили доста неща и не можете да превключите на старата верся, а и не може да ролбекнете и да загубите промените. Другите са променили доста неща и дори да имате етикет от началото на седмицата той вече не е актуален. Ако вземете нещата на колегите пък трябва да се сливат файлове за което още не сте готови ... знам че мърдж не се пропорачва, но в някои фирми така се работи :(
Решение :?? как избягвате подобни проблеми?
Проблемът: вече сте изменили доста неща и не можете да превключите на старата верся, а и не може да ролбекнете и да загубите промените. Другите са променили доста неща и дори да имате етикет от началото на седмицата той вече не е актуален. Ако вземете нещата на колегите пък трябва да се сливат файлове за което още не сте готови ... знам че мърдж не се пропорачва, но в някои фирми така се работи :(
Решение :?? как избягвате подобни проблеми?
Re: Source Safe проблем
как избягвате подобни проблеми
Организация. Доколкото разбирам, промените на останалите ти колеги (след евентуалният label) трябва да се приложат, а твоите не.
Можеш да check-in твоите сорсове и да ги Pin-неш на предишна версия, но това трябва да направят и всички останали, докато не си напълно готов. Другото по-дивашко е: copy в някаква директория на диска, Undo Check-out, fix, Check-In, Check-out, merge от директорията и така до следващото обаждане на шефа.
А нещата може да се организират по-просто:
Такуща SourceSafe база - Current.
База с последните stable и/или това което работи при клиента сорсове - Previous, като тя включва labels за всичките releases, които работят при клиентите.
Клиента получава fix-нат build от Previous на съответната му версия (по label) или последно възможната stable такава.
Разбира се, фиксовете от Previous трябва да го прилагаш и в Current.
Те за това да имаш QA зад гърба е яко
P.S. Забравих да кажа: след всеки release който се прави в Current базата и получава съответният си label, Previous базата се подменя със съдържанието на Current .
---
...и аз пиша на кирилица!
Организация. Доколкото разбирам, промените на останалите ти колеги (след евентуалният label) трябва да се приложат, а твоите не.
Можеш да check-in твоите сорсове и да ги Pin-неш на предишна версия, но това трябва да направят и всички останали, докато не си напълно готов. Другото по-дивашко е: copy в някаква директория на диска, Undo Check-out, fix, Check-In, Check-out, merge от директорията и така до следващото обаждане на шефа.
А нещата може да се организират по-просто:
Такуща SourceSafe база - Current.
База с последните stable и/или това което работи при клиента сорсове - Previous, като тя включва labels за всичките releases, които работят при клиентите.
Клиента получава fix-нат build от Previous на съответната му версия (по label) или последно възможната stable такава.
Разбира се, фиксовете от Previous трябва да го прилагаш и в Current.
Те за това да имаш QA зад гърба е яко
P.S. Забравих да кажа: след всеки release който се прави в Current базата и получава съответният си label, Previous базата се подменя със съдържанието на Current .
---
...и аз пиша на кирилица!
Редактирано от ess на
Re: Source Safe проблем
благодаря ти за съветите, мислих по това което писа , аз досега изпозлвах "по-дивашкия" вариант описан от теб. А тогава просто оправих бъга при себе си и после само копирах кода на един колега. Не знам как мога да чек-инна само част от файл, но не ми се и занимаваше ..
"Те за това да имаш QA зад гърба е яко" Да знам, но тук аз съм си и качествен контрол, знам че не е добре ама не зависи от мен
"Те за това да имаш QA зад гърба е яко" Да знам, но тук аз съм си и качествен контрол, знам че не е добре ама не зависи от мен