Version Control System

[Buddy Z]

Subj [trn]dlja malen'koj kontory - 5-6 razrabotchikov.
Posovetujte, pliz[/trn]

[Смайл]

Subj [trn]dlja malen'koj kontory - 5-6 razrabotchikov.
Posovetujte, pliz[/trn]

Я так понимаю такие конторы допускают работу на дому. Значит нужен доступ к нему через TCP/IP.

CVS. А больше как бы альтернатив нет.

[ajkj3em]

Subj [trn]dlja malen'koj kontory - 5-6 razrabotchikov.
Posovetujte, pliz[/trn]

cvs адназначна

[Boo]

Это зависит от требований, платформы и от того какими тулзами в основном пользуетесь. Если все на микрософте и тулзы микрософтовские, то VSS. Т.к. удобная интеграция в вижуал студию. Я в нескольких конторах с ним работал, есть конечно нарекания и глюки но удобство как правило перевешивает. Принципиальный недостаток - это невозможность работать удаленно. А вот дома у меня стоит CVS именно по этой причине.

В вопросе надо было бы указать еще и платформу, я то я тут распинался-распинался, а у вас в конторе все на соляре оказывается работают....

[Buddy Z]

В вопросе надо было бы указать еще и платформу, я то я тут распинался-распинался, а у вас в конторе все на соляре оказывается работают....

[trn]Dyk, blizko k tomu. U nas voobshe dinozavrovaja kontora.
Poslednie 20 let vse delalos' chistaa pod terminaly na JUnikse i Linukse.
V novom tysjacheletii reshili perejti na grafiku.
Otcy reshili labat' frontwnd na Del'fake/Kajlikse s bazoj na Interbwjse/Fajrberde.
U Borlanda est' kakoj-to tim-vare, kotoryj stykuetsja s raznymi sistemami kontrolja versij.
Vot mne i nuzhno uznat', kakaja sobsno luchshe.
Pohozhe vse edinodushno soshlis' na [/trn]CVS.

[Lepsik]

starteam. с 6-8 начинали

[Oleg]

Subj [trn]dlja malen'koj kontory - 5-6 razrabotchikov.
Posovetujte, pliz[/trn]

Я так понимаю такие конторы допускают работу на дому. Значит нужен доступ к нему через TCP/IP.

CVS. А больше как бы альтернатив нет.

к всс есть фронтенд, работающий как раз по тсп
в прошлой конторе пользовали
забыл название
вешается как сервис на одной из машин в сетке
надо так вспомню
оно почти не глючило
но потом перешли на perforce
и сразу стало совсем хорошо

[Boo]

фронт-энд для всс и перфорс - обе альтернативы платные. кроме того у товарищей *никс и им всс никак не подходит.

[Buddy Z]

фронт-энд для всс и перфорс - обе альтернативы платные. кроме того у товарищей *никс и им всс никак не подходит.

[trn]Dyk, ja zh govorju, u nas novye vejanija. Na shminukse ostavljaem tol'ko bazu a frontwndy budem na Del'fjah labat' pod vindu o ogljadkoj na Kajliks.
Dva voprosa:
- skoka wtot perfors stoit?
- "vss" wto chto - [/trn]Borland C++ ?

[ajkj3em]

фронт-энд для всс и перфорс - обе альтернативы платные. кроме того у товарищей *никс и им всс никак не подходит.

а vss по-прежнему не позвляет больше чем одному человеку работать над одним файлом ? несколько лет назад у него помнится был только exclusive checkout, что очень сильно раздражало

[dEBUGER]

а vss по-прежнему не позвляет больше чем одному человеку работать над одним файлом ? несколько лет назад у него помнится был только exclusive checkout, что очень сильно раздражало

Нет, теперь можно - если прописана соотв. опция при создании проекта (с какой версии не скажу, я пару лет уходил на ClearCase - BTW, вот что рулит!).

Кстати, а какая практическая польза от multiple check out? никогда не пользовался, может зря? ИМХО, делаешь приватную версию файла writable и вперед. Или ? huh как ты считаешь?

[Oleg]

Dva voprosa:
- skoka wtot perfors stoit?
- "vss" wto chto - [/trn]Borland C++ ?

http://www.perforce.com/perforce/price.html
вспомнил - sourceoffsite называется, работает быстрее нативной оболочки
http://www.sourcegear.com/sos/index.asp
vss- visual sourcesafe[/quote]

[ajkj3em]

Кстати, а какая практическая польза от multiple check out? никогда не пользовался, может зря? ИМХО, делаешь приватную версию файла writable и вперед. Или ? huh как ты считаешь?

я не в курсе, что такое приватная версия файла, но
в принципе рулит не столько multiple checkout, сколько
сама возможность одновременного изменения сорцов.
если не рассматривать теологическую сторону вопроса
(то есть что большие файлы - не кошерно), то на практике
такая возможность рулит.

checkout - это изъятие файла из writable доступа для
эксклюзивного локального использования. в большинстве
случаев это overkill, поскольку изменения, локально
вносимые в код, обычно не затрагивают других частей,
над которыми работают остальные. то есть лочить весь
файл - тормозить работу остальных.

а так, скажем, A и B работают над одним и тем же файлом:

A закончил часть
- commit'нул в cvs,

В закончил часть
- втянул в локальную версию изменения, сделанные A,
- проверил, что нет конфликтов,
- commit'нул в cvs

A закончил часть
- втянул в локальную версию изменения, сделанные B,
- проверил, что нет конфликтов,
- commit'нул в cvs

и т.д.

[dEBUGER]

я не в курсе, что такое приватная версия файла, но

Хе, сразу и не сообразил - терминология у разных систем контроля версий разная...

Практически все как ты описал , но в разных системах по разному решается.

У VSS файлы физически переносятся на локальный комп., в назначенный working folder, и метятся read only. Отменяем read-only - и далее по твоему тексту (diff перед взятием B версии A).

В ClearCase с "файлами" все сложнее, но порядок действий мы использовали примерно такой же.

В нынешнем RCS для этих целей - check in без lock-a.

[Циник]

я не в курсе, что такое приватная версия файла, но
в принципе рулит не столько multiple checkout, сколько
сама возможность .
если не рассматривать теологическую сторону вопроса
(то есть что большие файлы - не кошерно), то на практике
такая возможность рулит.

Мое глубокое убеждение, товарищи, что рулит она не туда, куда надо. И дело вовсе не в теологии, а как раз в практике.
Девелоперы начнут с "одновременного изменения сорцов", а там и до безобразий сode branching'а рукой подать. А в каком месте тогда будет у нас консистенси? Где будет отдыхать реюзабилити? Куда забьется испуганная до смерти майнтэйнабилити?

checkout - это изъятие файла из writable доступа для
эксклюзивного локального использования. в большинстве
случаев это overkill

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

поскольку изменения, локально
вносимые в код, обычно не затрагивают других частей,
над которыми работают остальные. то есть лочить весь
файл - тормозить работу остальных.

Опасное заблуждение, ИМХО.

а так, скажем, A и B работают над одним и тем же файлом:

A закончил часть
- commit'нул в cvs,

В закончил часть
- втянул в локальную версию изменения, сделанные A,
- проверил, что нет конфликтов,
- commit'нул в cvs

A закончил часть
- втянул в локальную версию изменения, сделанные B,
- проверил, что нет конфликтов,
- commit'нул в cvs

"Дьявол кроется в деталях" (Немирович-Данченко)
Что значит "проверил, что нет конфликтов"?. Разве это тривиальная задача? Опять, значит, все на человеческий фактор спихнем? Здесь непаханое потенциальное поле для конфликтов - не только чисто алгоритмически-кодировочных, но, самое главное, человеческих (в том числе с участием босса ).

Нет, товарищи, дизайн должен быть правильным. Чтобы желания (я уж не говорю о нужде) распараллелить код единого модуля у тим-плэеров не возникало. Называйте это теологией, если хотите, а я называю это прагматизмом.