Провівши весь ранок, намагаючись щось перевірити, я тепер розумію, що втратив роботу, яку потрібно пару днів.

Це сталося раніше - і, мабуть, часто зустрічається з SourceSafe. Чи можна SourceSafe успішно використовувати без проблем, і якщо так, то як?

Мій погляд простий, перейти на щось інше якнайшвидше. Це не займе багато часу (1-2 тижні WAG), і незалежно від того, скільки часу триватиме міграція, обґрунтувати це керівництвом легко. Трохи часу для міграції прирівнюється до контролю твердого джерела та дуже мало шансів втратити вихідний код. Швидко пошукайте Google за "джерелами страхіття, безпечними для джерел" чи подібними, якщо ваш начальник скептично налаштований.

Найгірше. СКМ. Колись.

Все, що в SCM не так, втілено у VSS. Навіть StarTeam кращий за Source Safe. Source Safe - це Internet Explorer 1 світу управління версіями: повністю витіснений будь-якою іншою реалізацією.

Як я ним користувався?

Мій типовий робочий процес для виконання справ був

1. Перевірте проект
2. Блокуйте всі файли (щоб уникнути злиття ні з ким, бо відкрив нечесні ворота Пекла)
3. Зробив мою роботу
4. Кожен день перевіряв мої зміни в
5. Знову перевірив усе, і виправив усі проблеми з інтеграцією
6. Знову перевірив

Порівняно з Subversion, вищезазначене є смішним (окрім перевірки, що ви не зламали збірку).

Обмеження щодо практики програмування моєї команди

Це правила, над якими повинна була працювати команда, щоб вона працювала на нас. Ваш пробіг може відрізнятися.

1. Лише одна людина може редагувати файл (Небеса допоможуть вам, якщо вони поїдуть у відпустку)
2. Не розгалужуйте це занадто важко в управлінні
3. Ніколи не намагайтеся повернутися до попередньої редакції

Що можна зробити?

Polarion має гарний набір інструментів для міграції з подібних даних Source Safe в Subversion (SVN), що є чинним де-факто стандартом для більшості підприємств для контролю версій з відкритим кодом. Subversion страждає від того, щоб вимагати, щоб сервер був доступний для дозволу перевірки (на відміну від GIT або Mercurial, які призначені для розподілених офлайн-команд).

Змініть джерело керування на SVN / Mercurial / Git і ніколи не озирайтеся!

Ми вивели його з експлуатації близько року тому.

Кілька разів траплялося, що те, що я зареєструвалась в попередній вечір, просто не було наступного ранку. Я не вважав це кумедним, бо це виглядало підозріло, ніби я просто не закінчив свою роботу. Оскільки я був новим у компанії, то, можливо, це було для мене небезпечно.

Ми з ними перейшли до TFS і з тих пір він працює безперебійно.

Мій погляд?

Є кращі, які простіші у використанні, безпечніші у користуванні та абсолютно безкоштовні. Навіщо взагалі турбуватися його використанням?

Це одна сфера розвитку, де у нас є великий вибір; більшість, або всі, краще, ніж VSS.

• Підрив
• Меркуріал
• Git
• Більше

Використовувати SourceSafe у комерційній операції - це як обігрів будівлі за допомогою спалювання доларових купюр.

У 2000 р. Моя восьмирічна компанія-розробник, ймовірно, втратила 5-10% своєї продуктивності через пошкодження баз даних VSS в середньому двічі на день. Це було лише таким низьким рівнем, тому що ми перейшли до погодинного резервного копіювання.

З моменту відходу від VSS до Perforce, svn та git, у мене ніколи не було пошкоджено базу даних SCM.

Я можу зголоситися на пеклі з цього приводу, але ..

VSS ефективно ставить вас на допінг, настільки, що ви не можете примирити будь-яку реальність, необхідну для того, щоб зрозуміти, що ваше теперішнє репо не було вашою виною.

Будь ласка, не використовуйте його ніколи.

використовували його роками - це було рішення за замовчуванням, як воно вже було. Якби мене кусало досить багато разів, але інерцію важко подолати

тоді мені довелося використовувати його віддалено через VPN, і навіть незначні реєстрації були схожі на набивання цегли через щілину . Швидше було вручну знайти файли, що змінилися, зашпаркувати їх, надіслати їх електронною поштою, віддалено перейти до вихідної машини з сейфом, розпакувати їх і перевірити код у машині з сховищем джерела.

Переключився на Меркуріал. Я можу клонувати всю базу вихідного коду через VPN протягом менше хвилини. І я більше не боюся розгалуження.

Ніколи не повертаючись назад.

Це гидота Але все ж краще, ніж нічого.

Я використовував його тривалий час (майже 10 років), не відчуваючи жодних проблем (у тому числі в командах, над якими працював, хоча наш код, як правило, був досить добре розділений, щоб уникнути конфліктів тощо).

Але є занадто багато історій втрати даних, щоб продовжувати користуватися нею, коли є гідні, надійні альтернативи з відкритим кодом.

Редагувати: З коментарів повідомлення, схоже, уникає нічого складного (розгалуження, злиття, конфлікти), і ви, мабуть, добре. Все більше, і ви прямуєте на ризиковану територію.

Навіть МС знецінює це на користь TFS.

Для сольного чи справді невеликого магазину, що працює у Visual Studio 6 чи щось старше, він є прохідним та кращим, ніж нічого. Я думаю, що багато перебільшень у тому, наскільки це було погано, але тоді потрібен лише один випадок втрати цінної роботи, щоб киснути тебе на продукт (з поважних причин). VSS мав своє місце, і я вдячний за принаймні заохочення багатьох розробників, які взагалі не використовували жодного інструмента SCM, щоб увійти в звичку, але, як і багато технологій, він зараз досить застарілий.

Після 3-х років користування ним, скаржившись на свого менеджера через всі більш просунуті / раціональні альтернативи, я ніколи не мав жодних проблем з VSS, але у мене також жодного разу не було.

Мої погляди полягають у тому, що це і смокче, і удари.

Найбільш дратівливою частиною цього є не жахлива версія та заплутана здатність розгалуження, але поле списку в меню файлів не дозволяє натиснути клавішу зі стрілкою праворуч, щоб розгорнутись.

Воістину болісно.

Мій погляд на VSS? Я відмовився від декількох пропозицій про роботу (дуже добре оплачуваних), бо вони просили "знання VSS". І я впевнений, що є пара інших людей, які зробили те саме.

Ви не тільки страждаєте від проблеми потенційної корупції джерела (що має бути достатньо аргументом для управління, щоб замінити його), але і вам доведеться жити з незручним резервним копієм і нездатністю ефективно працювати в команді на різних потоках роботи.

Знайдіть інший SCM (будь-який інший) і подивіться, наскільки легко може бути розгалуження та злиття. Подумайте про ті часи, коли вам доводилося копіювати файли з рішення VSS і тримати їх десь в іншому місці, поки ви повернулися, щоб виправити помилку на «виробничому» коді.

Для ударів просто встановіть GIT - наведіть його на ваші файли VSS і подивіться, як легко програмістам GASP працювати над різними частинами одного файлу В ІДНЕ ВРЕМЯ, а потім програмне забезпечення інтелектуально об'єднати ваші зміни ... SCM Інструменти повинні бути не просто резервним джерелом.

Мої погляди на VSS? Використовували його тривалий час регулярно (як і раніше використовується для випадкових старих компонентів), але це занадто XX століття для нашої команди:

• Дуже ненадійний
• Непридатні гілки
• Дуже погана підтримка версій, у вас є мітки, але (як і гілки) не дуже корисні

Я маю на увазі все вищесказане: оберіть одну з кращих альтернатив з відкритим вихідним кодом (навіть старий CVS) або, якщо ваша компанія має якусь підписку на MSDN, TFS .

• його блокування за замовчуванням сповільнювало розробників, і ніхто не хотів возитися з його налаштуванням
• він не дуже добре інтегрується з іншими службами, наприклад веб-програмою управління проектами
• він не буде працювати добре з нашим запланованим сервером CI

Новий матеріал Team Foundation 2010 повинен був дуже допомогти та спробувати відійти від поганих частин VSS. Але по своїй суті він все ще покладається на VSS , саме тому ми перейшли до SVN.

редагувати - Я розумію, що TFS - все нове, але під час тестування його багато запитуваних розробників мали дуже схожі почуття з ним. Причиною, по якій я сказав «в основі», було те, що я пам'ятаю, як дивився на файли TFS, зроблені в моєму рішенні, які виглядали так само, як і VSS. Це з точки зору розробника, можливо, навіть не знаючи про технології, що стоять за VSS або TFS або будь-яким іншим SCM. Вибачте за будь-яку плутанину.

Ще в той день, коли я був осілий SCCS під XENIX. VSS у Visual Studio 6, оскільки всі його відмови та проблеми мали явні переваги. Я все ще використовую його для невеликих проектів і більше не використовую SCCS в будь-якій версії.

Я не можу зрозуміти, чому всі хочуть перемогти VSS. VSS не поширюється, а розподілений варіант управління є

1. краще
2. дозволяє на практиці нерозподілений контроль версій на практиці

Будь ласка, прочитайте це .