бывает нужно воплотить какую то безумную идею в рабочий отлаженный проект
но так как она может зафейлится нужно вернутся к старой рабочей версии
программы вопрос чем в VS 2008 для этого лучше пользоватся ? или может быть
можно как то создать копию проекта прямо в студии ? нужен совет пробовал
вручную создавать копию проекта но это гемор тот еще надо скопировать
папку проекта изменить гуиды вообщем брр.. легко что нить напутать да и
неудобно
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>Всем привет
J>бывает нужно воплотить какую то безумную идею в рабочий отлаженный проект J>но так как она может зафейлится нужно вернутся к старой рабочей версии J>программы вопрос чем в VS 2008 для этого лучше пользоватся ?
Если работаете один, то смотрите в сторону DVCS: hg, mercurial, git. Выбирайте по вкусу, строго говоря они одинаковые.
Если нет, то в дополнение к тому, что выше можно посмотреть классические варианты: SVN, Perforce, TFS.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Если работаете один, то смотрите в сторону DVCS: hg, mercurial, git. Выбирайте по вкусу, строго говоря они одинаковые. AS>Если нет, то в дополнение к тому, что выше можно посмотреть классические варианты: SVN, Perforce, TFS.
а вы странный. не разумней наоборот?
Здравствуйте, cvetkov, Вы писали:
C>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Если работаете один, то смотрите в сторону DVCS: hg, mercurial, git. Выбирайте по вкусу, строго говоря они одинаковые. AS>>Если нет, то в дополнение к тому, что выше можно посмотреть классические варианты: SVN, Perforce, TFS.
C>а вы странный. не разумней наоборот?
Как мне кажется, нет. У команды должен быть центральный репозиторий, который неважно как настраивать. Это делается один раз.
Для личной разработки надо, чтобы поставил клиент и всё работает в одной папке.
Ну, лично мне так удобнее. Говорят, svn тоже так может, но я не пробовал.
Здравствуйте, Aen Sidhe, Вы писали:
AS>>>Если работаете один, то смотрите в сторону DVCS: hg, mercurial, git. Выбирайте по вкусу, строго говоря они одинаковые. AS>>>Если нет, то в дополнение к тому, что выше можно посмотреть классические варианты: SVN, Perforce, TFS.
C>>а вы странный. не разумней наоборот?
AS>Как мне кажется, нет. У команды должен быть центральный репозиторий, который неважно как настраивать. Это делается один раз.
обычно да, но в некоторых условиях (например распределенная разработка) может потребоватся распределенный.
AS>Для личной разработки надо, чтобы поставил клиент и всё работает в одной папке.
и зачемдля этого распределенный репозиторий?
AS>Ну, лично мне так удобнее. Говорят, svn тоже так может, но я не пробовал.
похоже вы не умеете готовить кошек.
Здравствуйте, cvetkov, Вы писали:
C>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>>Если работаете один, то смотрите в сторону DVCS: hg, mercurial, git. Выбирайте по вкусу, строго говоря они одинаковые. AS>>>>Если нет, то в дополнение к тому, что выше можно посмотреть классические варианты: SVN, Perforce, TFS.
C>>>а вы странный. не разумней наоборот?
AS>>Как мне кажется, нет. У команды должен быть центральный репозиторий, который неважно как настраивать. Это делается один раз.
C>обычно да, но в некоторых условиях (например распределенная разработка) может потребоватся распределенный.
Центральный репозиторий — это репозиторий, вне рабочих мест разработчиков, который регулярно бэкапится и с которого собирают релизные билды, етс, етс, етс. Он есть всегда, по-моему опыту, даже если у нас распределённая разработка с несколькими командами и несколькими людьми в каждой.
AS>>Для личной разработки надо, чтобы поставил клиент и всё работает в одной папке.
C>и зачемдля этого распределенный репозиторий?
Затем, что они элементарно ставятся и работают, не требуя никаких серверов для этого. И выполняют свою функцию. А перфорс, к примеру, так не может. А ТФС ещё разверни на домашней машине, угу.
AS>>Ну, лично мне так удобнее. Говорят, svn тоже так может, но я не пробовал.
C>похоже вы не умеете готовить кошек.
SVN готовить не умею, да. У меня на него аллергия с версии 1.4.* и 1.5. С тех пор не юзал.
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, jyuyjiyuijyu, Вы писали:
U>я делаю параллельный checkout и там уже мудрствую U>неудобно, но изолированно
не с git, но с hg у меня был "дуальный репозиторий" hg+svn (делается спец утилиткой и управляется через нее же) -- т.е. централизованный VCS использовавшийся в команде был svn, а для себя у меня в рабочей копии svn была hg репа (там было кучка эксперементальных веток)...
Здравствуйте, zaufi, Вы писали:
Z>попробуй такой way: http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/ru/ch03.html#__28
спасибо, сейчас я сижу на свн
давно мечтаю изучить git, но никак не срастается =\
судя по ссылочке, работа с свн <-> гит довольно простая, но неясно насколько )
пойду-ка я в офтопик:
есть у меня выкачанный svn_repo
как мне реализовать след. сценарии:
1) конвертация svn_repo в git_repo (вроде в ссылочке это объяснено)
2) запихивание неких изменений из git_repo\folder1\folder2 в соответствующий svn_repo (working copy), затем commit в svn
3) обратная ситуация: svn_repo\f1\f2 обновления переслать в git_repo\f1\f2
пример:
cd git_repo\f1\f2
git up <--- качаем сразу из http: /svn\f1\f2
ну в таком духе) чем проще, тем лучше
в общем, хочется, чтобы прослойка git <-> svn была как можно тоньше
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, zaufi, Вы писали:
Z>>попробуй такой way: http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/ru/ch03.html#__28 U>спасибо, сейчас я сижу на свн U>давно мечтаю изучить git, но никак не срастается =\ U>судя по ссылочке, работа с свн <-> гит довольно простая, но неясно насколько ) U>пойду-ка я в офтопик: U>есть у меня выкачанный svn_repo U>как мне реализовать след. сценарии: U>1) конвертация svn_repo в git_repo (вроде в ссылочке это объяснено)
это не совсем "конвертация" просто создание дуальной репы svn/git из рабочей копии svn)
следующий шаг это оставить эту копию "в покое" сделав ее git клона, с которым и предполагается полноценная работа, а эту копию использовать как "точку обмена": для получения изменений с svn сервера, с последующим pull в клона, и наоборот, push из клона в дуальную репу и далее svn ci из дуальной репы...
U>2) запихивание неких изменений из git_repo\folder1\folder2 в соответствующий svn_repo (working copy), затем commit в svn U>3) обратная ситуация: svn_repo\f1\f2 обновления переслать в git_repo\f1\f2
не знаю насколько тяжело в такой схеме работать с новыми и удаленными файлами: с точки зрения git его add может все сделать сам: удалить все что не найдено и добавить все чего не было... а как там в svn я уже успел забыть
также нужно четко в голове себе представть что у тебя и где происходит, когда речь заходит о ветках -- можно башку свернуть от всех этих многомерных измерений %)
с git я вот так не работал, а с hgsvn прошло некоторе время прежде чем сложились "хорошие практики" использования и пришло понимание того, что тут можно, а что будет "больно"
надо отдать должное hgsvn сам заботится о синхронизации файловых операций между репами (т.е. типа в одной добавили, в другой сами добваятся...), а также он берет на себя заморочки с коммитами (т.е. все что я коммитил в hg, аналогичным образом появляется в svn, а не одним большим коммитом -- тупо "реплаит" историю короче, но руками можно упариться,... наверное)
есть еще один инструмент: hgsubversion -- еще одна интеграция hg и svn, он более клево работает с бранчами, но с мержами, после hgsvn мне он показался "странным"...
в общем удачи! -- тебя ждет забавный experience, anyway
мое знакомство с DVCS началось именно со связки hg+svn -- и это было очень полезно. в одном проекте почуствовать разницу, когда дело касается сложных мержей сразу чуствуешь насколько svn (1.6 тогда еще) "нервно курил в сторонке"... не знаю как сейчас.
AS>>Если работаете один, то смотрите в сторону DVCS: hg, mercurial, git. Выбирайте по вкусу, строго говоря они одинаковые. AS>>Если нет, то в дополнение к тому, что выше можно посмотреть классические варианты: SVN, Perforce, TFS. C>а вы странный. не разумней наоборот?
в его словах есть сенс. Если это продукт, то в любом случае будет какой-то централизованный репозиторий.
А тот же git оказывается удобен именно для самого себя -- удобно заводить бранчи для экспериментов и т.п.
Поэтому связки git-svn так популярны -- svn для централизованного хранилища, а git для собственно работы.
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, zaufi, Вы писали:
Z>>в общем удачи! -- тебя ждет забавный experience, anyway U>что-то я снова потерял интерес к этому делу
не отчаивайся! на hgsvn по любому лучше чем на svn
Здравствуйте, zaufi, Вы писали:
Z>есть еще один инструмент: hgsubversion -- еще одна интеграция hg и svn, он более клево работает с бранчами, но с мержами, после hgsvn мне он показался "странным"...
hgsubversion не умеет пушить коммиты, содержащие мерджи
поэтому если вы используете hgsubversion, перед пушем обратно в svn придется делать rebase
вопрос — почему нельзя указать ветку (допустим default) которую он и запушит в svn, а мердж-коммиты запушит в виде обычных коммитов ? нет, hgsubversion этого не позволяет
это еще полбеды
другая проблема в том, что при пуше своих изменений обратно в svn hgsubversion в процессе еще раз делает rebase коммитов, переписывая историю
и если вам эти изменения запушил другой разработчик (с которым вы договорились работать через hg), то сделав пулл, он очень удивится дубликатам ревизий
Вывод: hgsubversion можно использовать только в одиночку и при этом перед пушем придется делать rebase. Так что весь плюс от hgsubversion — в возможности поиграться перед тем, как пушить в svn. А потом все равно все ветки придется убрать.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, jyuyjiyuijyu, Вы писали:
J>>бывает нужно воплотить какую то безумную идею в рабочий отлаженный проект
BZ>перейти на git/hg. репу svn сконвертить один раз и забыть про него
Люто плюсую. Мостики туда-обратно — фигня. Жаль только руководство сложно уломать на переезд.
Если нам не помогут, то мы тоже никого не пощадим.
