Вопрс о subversions/client

dot · Post by **dot** » 16 May 2004 18:20

Я что-то ничего не понимаю. Есть сервер(админ не я), установлены subversions, пытаюсь сделать initial checkout(чтобы получить личную копию в своей домашней директории), будучи залогиненой на сервер (т.е. использую протокол file://):

Code: Select all

svn checkout file:///path/to/working/directory/  /home/path/to/mycopy/

И получаю ошибку:

Code: Select all

Unable to open an ra_local session to URL
Unable to open repository 'file://path/to/working/directory/'

Меня интересует - это у меня руки кривые и для initial checkout команда неправильная или нужно админу письмо написать?

katit · Post by **katit** » 16 May 2004 18:43

Скорее всего путь неправилно указан.

Да и file:///path/ не уверен что такое.
может надо http:// или что другое?

dot · Post by **dot** » 16 May 2004 18:57

katit wrote:Скорее всего путь неправилно указан.

Да и file:///path/ не уверен что такое.
может надо http:// или что другое?

я путь через "табуляцию" набирала(ну знаете, в Юниксе такая фича - пишешь начало названия файла и "hit tab"), протокол "файл" нашла тут: http://svnbook.red-bean.com/svnbook/ch02s03.html

С http:// сложнее - я логинюсь к этому серверу через ssh + ssh2 keys(т.е. мне непонятно, как сказать svn использовать соотв. afqk c ssh2 key - не нашла такой опции

)

При попытке сделать http://server.com с моей машины получаю вот что:

Code: Select all

>svn checkout http://server.com/sub_directory

svn: PROPFIND request failed on '/sub_directory'
svn: PROPFIND of '/sub_directory': 500 Internal Server Error (http://server.com)

Code: Select all

>svn checkout http://server.com/sub_directory/child_dir

svn: PROPFIND request failed on '/sub_directory/child_dir'
svn: PROPFIND of '/sub_directory/child_dir': 301 Moved Permanently

https - вообще говорит - unrecognized URL scheme.

katit · Post by **katit** » 16 May 2004 19:25

Так чего гадать? Пускай админ скажет что там за сервер.

Я сервр держу по Win, так что с Unix не скажу.
Вначале было через svnserve, подключались как "svn co svn://.... "
Сейчас поставил под Apache и подключаемся как "svn co http://..."

dot · Post by **dot** » 16 May 2004 19:52

katit wrote:Так чего гадать? Пускай админ скажет что там за сервер.

Я сервр держу по Win, так что с Unix не скажу.
Вначале было через svnserve, подключались как "svn co svn://.... "
Сейчас поставил под Apache и подключаемся как "svn co http://..."

да я его побаиваюсь, если честно. :mrgreen:

dot · Post by **dot** » 17 May 2004 21:43

Да, действительно, путь был к working directory а нужно было путь к repository указывать.

Но эта зараза теперь commit не делает.
Может быть, кто-нить обяснит мне, плиз,(ну очень срочно нужно):
1. вот я получила эту "свою" копию
2. Сделала изменения в нужных файлах
3. сделала svn diff file/name > difference_file
4 сделала svn commit file/name
Что в этой последовательности неправильно? Я серьезно не понимаю.

katit · Post by **katit** » 17 May 2004 21:46

Так какую ошибку выдает?

dot · Post by **dot** » 17 May 2004 22:06

katit wrote:Так какую ошибку выдает?

Никакой. Сказал "Transfering" и выдал новый номер версии. В моей "воркинг директори" - файл номальный, в директории, где д.б. обновится - все по-старому.

я тут команды напишу, как они есть, с путями, а потом сотру:
www-dev/ - рабочая директория, моя, типа личная.

Code: Select all

 svn update www-dev/cgi/clnt/clnt/clntlogin.cgi
At revision 13.
---
svn status www-dev/cgi/clnt/clnt/clntlogin.cgi
M      www-dev/cgi/clnt/clnt/clntlogin.cgi

теперь мне нужно мерже сделать или сразу можно коммит?

katit · Post by **katit** » 17 May 2004 22:13

Насколько я понимаю merge делать вообще очень редко приходится (если все нормальн организовано)

Так что co-<do your stuff>-update(just in case)-commit
есть обычнаюа рабочая последовательность. Если долго работаете перед commit то можно периодически упдате делать

dot · Post by **dot** » 17 May 2004 22:16

katit wrote:Насколько я понимаю merge делать вообще очень редко приходится (если все нормальн организовано)

Так что co-<do your stuff>-update(just in case)-commit
есть обычнаюа рабочая последовательность. Если долго работаете перед commit то можно периодически упдате делать

Вы только не уходите, я сейчас коммит сделаю, и сюда скопирую, что он ответил, ок?

Code: Select all

 svn commit www-dev/cgi/clnt/clnt/clntlogin.cgi  --message "Cross server login, clntlogin.cgi, attpmt 2"
Sending        www-dev/cgi/clnt/clnt/clntlogin.cgi
Transmitting file data .
Committed revision 14.

а рабочий файл так и не изменился. Т.е. изменения куда-то ушли, а куда - непонятно.

dot · Post by **dot** » 19 May 2004 04:38

Если интересно, то там проблема была в том, что "директории не были добавлены в makefile" - админ сказал(мне это ни о чем не говорит, я еще svn-admin секцию не прочитала).
Теперь у меня не работает "svn propset svn:executable 0755"(вернее, работает, но ничего не происходит, впрочем, как обычно) но я вроде админа перестала боятся, так что... :mrgreen:

uncle_Pasha · Post by **uncle_Pasha** » 20 May 2004 04:05

katit wrote:Насколько я понимаю merge делать вообще очень редко приходится (если все нормальн организовано)

Мне кажется, что не совсем правильно понимаете.
В достаточно убогих по функциональности системах котроля кода - CVS, PVCS, VSS, etc процесс стараются организовать так, чтобы всеми правдами и неправдами избегать merge. Это да. Потому как геморрой.
Но с нормальной организацией это мало что имеет общего.

Удачи!

katit · Post by **katit** » 20 May 2004 04:28

uncle_Pasha wrote:Мне кажется, что не совсем правильно понимаете.

А мне кажется что правильно. SVN делает merge автоматически если измененные куски не пересекаются. А ручной merge (то что я имел ввиду) навязывается только когда возникают "конфликты"
А они при правильной организации процесса разработки не должны быть.
Так что вы меня не так поняли...

Strannik223 · Post by **Strannik223** » 20 May 2004 04:59

uncle_Pasha wrote:В достаточно убогих по функциональности системах котроля кода - CVS, PVCS, VSS, etc процесс стараются организовать так, чтобы всеми правдами и неправдами избегать merge. Это да. Потому как геморрой.
Удачи!

Что то вы все в кучу смешали. Есть 2 концепции: блокировка файлов и автоматический мерж. VSS - блокировщик, CVS мержит сам если считает что нет конфликтов. Почему вы все под одну гребенку чешете непонятно.

uncle_Pasha · Post by **uncle_Pasha** » 20 May 2004 21:08

Strannik223 wrote:Есть 2 концепции: блокировка файлов и автоматический мерж. VSS - блокировщик, CVS мержит сам если считает что нет конфликтов. Почему вы все под одну гребенку чешете непонятно.

Вы не правы. Только 2 концепции - это в рамках только одного бранча.
Про что и была речь - средства контроля кода, скажем так, поколения 1 - SCCS, RCS, CVS, PVCS, VSS, etc - т.е. убогие, вынуждают вести разработку в пределах одного бранча. Не потому что возможности, к примеру, бранчеваться, не существует, а потому что применяя эту фичу огребаешь больше геморроя, чем решаешь проблем. И уж ни в коей мере не упрощаешь работу девелопера.
Именно потому частота мерджей - показатель, скорее, ограниченности функциональности средства контроля кода, чем правильности организации процесса.

Удачи!

uncle_Pasha · Post by **uncle_Pasha** » 20 May 2004 21:17

katit wrote:А ручной merge (то что я имел ввиду) навязывается только когда возникают "конфликты"
А они при правильной организации процесса разработки не должны быть.
Так что вы меня не так поняли...

Я вас понял.
Расскажите мне, например, как вы "правильно" организуете процесс в простейшем случае, когда надо обслуживать релиз 1.0 (своевременно выпускать патчи) и заниматься разработкой релиза 2.0.
(Разумеется, баги пофиксенные для релиза 1 не должны появляться опять в релизе 2, а количество патчей исчисляется десятками).

Удачи!

katit · Post by **katit** » 20 May 2004 21:28

uncle_Pasha wrote:Расскажите мне, например, как вы "правильно" организуете процесс в простейшем случае, когда надо обслуживать релиз 1.0 (своевременно выпускать патчи) и заниматься разработкой релиза 2.0.
(Разумеется, баги пофиксенные для релиза 1 не должны появляться опять в релизе 2, а количество патчей исчисляется десятками).

Ручками. Тот кто пофиксил в 1 пофиксит и в 2.
А как другие системы это делают? (Уменя только опыт с VSS и SVN)

Hamster · Post by **Hamster** » 20 May 2004 21:33

uncle_Pasha wrote:Я вас понял.
Расскажите мне, например, как вы "правильно" организуете процесс в простейшем случае, когда надо обслуживать релиз 1.0 (своевременно выпускать патчи) и заниматься разработкой релиза 2.0.
(Разумеется, баги пофиксенные для релиза 1 не должны появляться опять в релизе 2, а количество патчей исчисляется десятками).

В CVS:
В момент выхода релиза 1.0 создается новый бранч RELEASE_1_0. Основная разработка ведется в HEAD. Обслуживание 1.0 ведется в бранче.
Периодически выполняется команда типа:
cvs update -jRELEASE_1_0:2004/05/01 -jRELEASE_1_0:2004/04/01 modulename

Затем руками исправляются все конфликты.
Работает, если в HEAD не делается таких радикальных изменений, что код в RELEASE_1_0 и HEAD становится не похож друг на друга ( в таком случае, баг придется фиксить два раза, и никакой source control system не поможет ).

uncle_Pasha · Post by **uncle_Pasha** » 20 May 2004 23:19

Hamster wrote:В CVS:
В момент выхода релиза 1.0 создается новый бранч RELEASE_1_0. Основная разработка ведется в HEAD. Обслуживание 1.0 ведется в бранче.
Периодически выполняется команда типа:
cvs update -jRELEASE_1_0:2004/05/01 -jRELEASE_1_0:2004/04/01 modulename

Затем руками исправляются все конфликты.

И я вам легко нарисую пример, когда один и тот же конфликт надо будет разрешать "ручками" для патча 1, потом 2, потом3, ... N, N+1, ...
В реальной жизни таких точек будут десятки-сотни, что делает работу по мерджеванию в CVS весьма "приятной и интеллектуальной". О которой девелоперы только и мечтать могли...

Удачи!

uncle_Pasha · Post by **uncle_Pasha** » 20 May 2004 23:31

[quote="katitРучками. Тот кто пофиксил в 1 пофиксит и в 2.
А как другие системы это делают? (Уменя только опыт с VSS и SVN)[/quote]
Автоматическое создание бранчей для модифицируемых элементов.
Периодический мердж с запоминанием точки мерджа и контрибьюторов (единожды разрешенный конфликт не будет вам предложен еще раз при мердже последующего патча)
Мердж краток и прост, девелопер получает удовольствие и тратит освободившееся время на что-либо более полезное

Удачи!

Hamster · Post by **Hamster** » 20 May 2004 23:56

uncle_Pasha wrote:И я вам легко нарисую пример, когда один и тот же конфликт надо будет разрешать "ручками" для патча 1, потом 2, потом3, ... N, N+1, ...

Рисуйте.

Автоматическое создание бранчей для модифицируемых элементов

Не понял, что такое модифицируемый элемент? Полномасштабный бранч в момент выпуска версии 1.0 есть или его нет? Если есть, зачем еще что-то автоматически создавать?

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

В CVS тоже не будет. Недостаток только в том, что нужно помнить ( или записывать ), что патчи вплоть до такой-то даты уже были merged. Автоматически branch merge делать невозможно, потому что в любом merge бывают конфликты, и эти конфликты нельзя разрешать без участия developer'а.

Strannik223 · Post by **Strannik223** » 20 May 2004 23:59

uncle_Pasha wrote:[quote="katitРучками. Тот кто пофиксил в 1 пофиксит и в 2.
А как другие системы это делают? (Уменя только опыт с VSS и SVN)

Автоматическое создание бранчей для модифицируемых элементов.
Периодический мердж с запоминанием точки мерджа и контрибьюторов (единожды разрешенный конфликт не будет вам предложен еще раз при мердже последующего патча)
Мердж краток и прост, девелопер получает удовольствие и тратит освободившееся время на что-либо более полезное :)

Удачи![/quote]

Что то я не понимаю. Создание бранчей, сколько будет изменений столько и бранчей? И как такой лес поможет?

Что такое периодический мерж? Это когда я меньше всего этого ожидаю и хочу, вдруг система мне версию сама похачит, решив что все, пора!?

Как единожды разрешенный конфликт может возникнуть опять?

uncle_Pasha · Post by **uncle_Pasha** » 21 May 2004 03:11

Strannik223 wrote:Что то я не понимаю. Создание бранчей, сколько будет изменений столько и бранчей? И как такой лес поможет?

Наример, у вас есть 2 бранча - для фикса релиза 1 и для релиза 2. Они растут из одного места - оригинальный релиз 1.
Если элемент (файл) необходимо модифицировать для фикса - создается бранч этого елемента. Если элемент не модифицировался, используется оригинальная версия без создания бранча. Никакого леса.

Strannik223 wrote:Что такое периодический мерж? Это когда я меньше всего этого ожидаю и хочу, вдруг система мне версию сама похачит, решив что все, пора!?

То, о чем вы говорите, возможно, но в данном случае имелось ввиду другое - сформирован рел 1 патч 22 - мердж в рел 2
сформирован рел 1 патч 23 - мердж в рел 2
сформирован рел 1 патч 24 - мердж в рел 2

Strannik223 wrote:Как единожды разрешенный конфликт может возникнуть опять?

допустим, некая переменная не была инициализирована и это пофиксено в патче 22:
i = 0;
в релизе 2 кто-то по какой-то несвязанной причине сделал что-то аналогичное:
i = NULL;
Во время мерджа патча 22 в релиз происходит конфликт, который девелопер разрешает в пользу версии из релиза 2 (нравится она ему больше).

Проблема в том, что в случае мерджа следующего патча 23 в релиз 2 тот же конфликт будет предложен для разрешения снова. потом, при патче 24 снова и т.д.

Удачи!

Hamster · Post by **Hamster** » 21 May 2004 21:39

uncle_Pasha wrote:допустим, некая переменная не была инициализирована и это пофиксено в патче 22:
i = 0;
в релизе 2 кто-то по какой-то несвязанной причине сделал что-то аналогичное:
i = NULL;
Во время мерджа патча 22 в релиз происходит конфликт, который девелопер разрешает в пользу версии из релиза 2 (нравится она ему больше).

Проблема в том, что в случае мерджа следующего патча 23 в релиз 2 тот же конфликт будет предложен для разрешения снова. потом, при патче 24 снова и т.д.

При merge патча 22 в HEAD будет merge'иться diff между версией 1.0 patch 21 и версией 1.0 patch 22. В diff'е будет что-то такое:

+ i = 0;

CVS увидит конфликт и вставит в локальную версию кода:

<<< something.c:1.100
i = NULL;
===
i = 0;
>>> something.c:1.90.2.10

При merge патча 23, соответственно, используется diff между patch 22 и patch 23. В patch 23 эта строчка не меняется. Конфликта не будет.

uncle_Pasha · Post by **uncle_Pasha** » 22 May 2004 01:58

Hamster wrote:При merge патча 23, соответственно, используется diff между patch 22 и patch 23.

Вот с этого момента поподробнее, пожалуйста...
Каким это волшебным образом CVS начнет использовать diff между вв 22 и 23?
Удачи!