LINUX.ORG.RU
решено ФорумTalks

Персональный svn


0

1

Можете подсказать какой-нибудь надежный сервис, предоставляющий svn-репозиторий, который можно закрыть на чтение для посторонних?

Разрабатываю одну софтинку для внутреннего пользования. Своих серверов нет. Хочу держать где-то исходники в svn'е, но чтобы никто кроме меня не смог их слить =)

Ответ на: комментарий от schizoid

Держи в хомяке, даже сервер не нужен. Какие проблемы?

Работаю в разных непредвиденных местах. Хочется иметь возможность откатиться до любой ревизии.

Fredrik ()
Ответ на: комментарий от O02eg

Почему именно svn?

На работе используется именно он. Можно сказать любовь с первого взгляда. Меня эта vcs полностью устраивает.

Fredrik ()
Ответ на: комментарий от Fredrik

Чем не устраивает такой вариант? И - на всякий случай - с svn легко перейти на mercurial почти не переучиваясь (естественно, это верно только для простейших commit/update)

unC0Rr ★★★★★ ()

Плюсую за hg на bitbucket.org

Ну и распределённые VCS рулят. Централизованные использовать — себя не любить.

KRoN73 ★★★★★ ()

Своих серверов нет. Хочу держать где-то исходники в svn'е, но чтобы никто кроме меня не смог их слить =)

Своей двери нет. Хочу засунуть яйца под дверь, но чтобы их никто не прищемил.

Облачные рабы.

Manhunt ★★★★★ ()
Ответ на: комментарий от urxvt

assembla уже довольно давно не предоставляет бесплатных приватных репов. Могу посоветовать http://projectlocker.com/ - но очень тормозное.

CFA ()
Ответ на: комментарий от flareguner

Кстати, что это значит? Т.е. децентрализованность VCS.

Все репозитории (локальный, удалённый, третьих сторон) равноценны. Можно делать push/pop с любого на любой. То есть работа идёт в SVN так:
— Правим код
— Коммитим в удалённый репозиторий
— Правим код
— Коммитим в удалённый репозиторий


В DVCS:
— Правим код
— Коммитим его (в локальный репозиторий, лежит в подкаталоге .hg)
— Правим код
— Коммитим его

— Отсылаем набор коммитов в один из удалённых репозиториев

В результате нет привязки к удалённому репозиторию, можно делать иерархию репозиториев (репозиторий разработчика → тестовый репозиторий → основной репозиторий) и т.д.

Очень гибко и удобно выходит.

KRoN73 ★★★★★ ()
Ответ на: комментарий от r_asian

Могу пустить к себе. Доступ через webDav(mod_dav_svn на апаче).

Спасибо, но я уже зарегистрировался тут: http://www.assembla.com
За участие и желание помочь тебе уважуха.

Fredrik ()
Ответ на: комментарий от KRoN73

Т.е. я могу сначала сливать изменения в сво локальный, а когда они будут готовы мержить его с общим? А как там с конфликтами? Если например я изменю те же файлы, что и другой разработчик. А вообще спасибо за пояснение, не нагуглил инфы сам.

flareguner ()
Ответ на: комментарий от flareguner

Т.е. я могу сначала сливать изменения в сво локальный, а когда они будут готовы мержить его с общим?

Да. При чём общих может быть более одного. Скажем, можно пихнуть изменения прямо в репозиторий коллеги, не трогая до поры общий.

А как там с конфликтами?

Как и в SVN. Конфликты ловятся. Простые изменения мержатся автоматически, сложные — ручками. В случае hg при конфликте все изменения в файле будут отражены в нём с пометками. Понятно также, что в любой момент доступны и новые версии, вызвавшие конфликт, и старая, оригинальная.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

unC0Rr ★★★★★ ()
Ответ на: комментарий от boogerhaze

Wuala полущ будет. Как раз для параноиков. Хотя лучше localhost спрятаный на 25метровой глубине ничего не придумали. :)

no-steam ★★ ()
Ответ на: комментарий от KRoN73

Нет, сейчас уж и не упомню, какие именно команды я выполнял, но суть в том, что hg сделал бэкап незакоммиченных изменений, и при втором запуске сделал бекап в тот же файл, затерев все изменения подчистую

unC0Rr ★★★★★ ()
Ответ на: комментарий от JFreeM

интересно, а как он вернет локальные изменения которые не были закоммичены и были затерты мержем?

Так он не позволит обновить файлы, пока изменения не закоммичены же.

KRoN73 ★★★★★ ()
Ответ на: комментарий от unC0Rr

суть в том, что hg сделал бэкап незакоммиченных изменений

Понял. Значит, это revert был. Я так сам пару раз терял изменения. Но это совсем даже и близко не то, что конфликт изменений :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от splinter

Именно, что DVCS для одного — очень удобно. Скажем, с bors-core я один работаю, но у меня его локальных репозиториев штук 10 :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от JFreeM

оно не даст (можно c -force) сделать мердж, пока имеются незакомиченные данные

ZuBB ★★★★★ ()
Ответ на: комментарий от KRoN73

Не, в том-то и прикол, что я не ревертил, а что-то другое делал. На 90% уверен, что мержил. И я пока ещё с своём уме, чтобы ревертить незакоммиченное :)

unC0Rr ★★★★★ ()
Ответ на: комментарий от unC0Rr

И я пока ещё с своём уме, чтобы ревертить незакоммиченное :)

Ну, со мной пару раз было :D В разном состоянии случается работать… Но при merge не помню, чтобы была ситуация, когда можно терять. Ведь коммит порождает новую версию, которую всегда можно взять снова.

KRoN73 ★★★★★ ()

github в помощь, можно для внутреннего купить акк

sendel ()
Ответ на: комментарий от KRoN73

Наверно, это был апдейт поверх изменённых сурцов, сейчас не упомнить уже.

Как-то раз я тоже ревертнул изменения. В tortoisesvn в окошке просмотра сделанных изменений нажал автоматом кнопку revert вместо ok ;) Впоследствии оттуда эту кнопку убрали

unC0Rr ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.