Вот, собственно. Стоял раньше vss, и жил-поживал я, пока не добрался до текстов с кодировкой utf8. Поставил себе Eclipse с Subclips'ом, завел лепрозорий... хм... репрозиторий...

Пока проект один - commit-update - ничего нового 

А вот со вторым - проблема

Есть проект №1, и проект №2. Они оба содержат несколько пересекающихся файлов. У пересекающихся файлов разный статус. Одни - системные библиотеки, которым следует верить и брать новую версию "не глядя"... Другие - какие-то мои или еще чьи-то самоделки, которые могут меняться от проекта к проекту, но хочется их как-нибудь "синхронизировать".
В vss я мог сказать, что один файл является линком для другого и оба этих файла будут по "получить последнюю версию" или "посмотреть историю" мне доступны в любом из проектов
Как мне поступить для subversion?

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

До чего-то такого я уже практически дошел... Есть 3 проекта (3 каталога в репозитории).
Начитался про svn:externals, хотел было заюзать и не понимаю куда их вставлять... У меня из инструментов - TortoiseSVN м 1.4.5 и SubClipse и ни один из них мне явно про external не говорит... :(
 

Тортила сказала... Правда ее пришлось долго мучить...

--
Блин! externals можно установить только на папки, а не на файлы... То есть как это? Нельзя будет создать один огромный библиотечный репозиторий и набирать из него нужные мне вкусные кусочки?

Это сообщение отредактировал(а) ksnk - 9.12.2007, 18:05

Что есть экстерналз у свна - не в курсе.
Но предложенный вариант и без всяких экстерналз вполне неплохо реализуется.

Да, видимо externals несколько не в тему...

начнем с начала.
Есть проект из файлов {file1, file2, lib1}, который разрабатывает, к примеру, Stieve ;-) и есть проект, состоящий из {file3,file2-XXX, lib1}, который разрабатывает, Sally.
lib1 - сторонняя библиотека, версия которой меняется периодически и в "лучшую" сторону 
file2 - версия файла, которая в "конце-концов" будет одинакова у двух разработчиков. Остальные файлы личные и мало похожи.
Как организовать репозиторий?
Потребности:
Кто-то из разработчиков укачивает новую версию библиотеки lib1 и желает ее раздать всем.
Разработчики хотят иметь возможность "слить" свои изменения file2 в любой удобный момент...

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

{file1, file2, lib1} - первый каталог в репозитории
{file3, lib1} - второй.

В проект у Sally подключается file2.

Как? Командой copy?
Что дeлать после того, как Sally поменяла что-то и решила, что это - хорошо? Commit куда - в свой проект или в первый проект. Или merge ?
Что делать если Stieve укачал свеженький lib1 и желает, чтобы Sally с минимальными телодвижениями (одним только update'ом) его получила?
У меня только Тортила и Subclipse. Правда в Subclips'е есть что-то напоминающее консоль...

ksnk, тебе явно стоит просветиться на тему совместной разработки кода. Особенно в плане моментов совместной одновременной правки одних и тех же файлов.


Никакой - подключаешь в проекте.

Репозиторий должен находиться на общем сервере. Салли, изменив файл и решив, что всё круто - коммитит файл на сервер. Туда, откуда и брала (файл на сервере для уменьшения энтропии и возможных ошибок разруливания различных версий должен находиться всего лишь в одном месте репозитория). В общем, закоммитила. Предварительно проверив, не произвёл ли ещё кто-нибудь изменения этого файла с прошлого стягивания. Если файл изменяли - мержит. Иначе просто коммитит.

Опять же - обычная процедура. В этом случае Стив считается ответственным за обновление библиотеки либ1. Скачал новую версию. Поигрался с нею в локали, проверил, всё ли работает с новой версией нормально (иногда бывают проблемы). Если ок - закоммитил и рассказал всем, какой он хороший. Салли в очередно раз стягивает с сервера уже обновлённую версию либ1 и пользуется ею. Если вдруг обнаруживается, что в каком-то проекте новая версия либ1 криво работает, то тут либо откатывают либ1 для всех проектов на пред.версию, либо организуют в репозитории место для старой версии (в цвсе была возможность делать ветки, в свн не видел, но и не искал).

Добавлено через 7 минут и 28 секунд
Лишний раз убеждаюсь, что объяснить суть работы с CVS/SVN тому, кто привык к VSS - проблема. VSS слишком уж аскетичный и работает как чугунный утюг на углях - медленно и глупо, но надёжно. И ежели им пользоваться в общирной подвижной команде, то можно поиметь кучу неприятностей. Пример: Вася (Стив, если так удобнее) работает над некоторыми исходниками. Они считаются "его" исходниками и больше туда никто не лезет. Подошло время Васе идти в отпуск, он и пошёл. Через пару дней после того, как Вася уехал в Магадан (или на гавайи, если так удобнее) потребовалось срочно внести изменения в его код - нашли ошибку. Но вот беда - Вася забыл счекинить файлы. И ещё беда - дозвониться до него не получается. Пришлось начальнику идти к админу, заведующему VSS и просить, чтобы он снял блокировку с Васиного файла. А время-то идёт.
Итог - приезжает Вася с отпуска и получает по шапке не только за ошибку но и за то, что забыл счекинить файлы. Да, Вася виноват, спору нет. Но если бы вместо всс был цвс/свн - легко можно было бы внести изменения и не тратить лишнее время и нервы.

Видимо, дело в используемых мной инструментах (надеюсь, голову менять не придется )... Давайте пройдем все по шагам.
На старте у меня есть два каталога с проектами, сидящими в Eclipse 

• TourtoiseSVN создает мне в папке z:\svn репозиторий
• С первым проектом я делаю Team-> share project -> file://z:/svn - initial import -> ... создается проект 1 в репозитории
• Со вторым проектом (содержащим пересекающиеся с первым файлы) я делаю то-же самое -> получаю проект 2

Видимо, последний пункт надо делать поумнее...
Как мне сказать SVN'у, что файлы в проектах пересекаются? 
 Мне бы лучше рукой показать  Кнопки "подключить" я не увидел ...

O!!! Достиг - таки какого-то просветления... подключать - это копировать!
Тортилой основную либу таки удалось обновить. Действительно, все оказалось очевидно, хотя, впрочем и не так волшебно... Никто кроме тебя не внесет новых изменений в твой собственный проект и каждый проект нужно "подтягивать" до новых версий системных библиотек вручную, самостоятельно merge'a каждую по отдельности... 

Это сообщение отредактировал(а) ksnk - 10.12.2007, 10:50

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

Хм... а что, должно быть как-то иначе? У вас в VSS'е Дед Мороз под новый год всем общие файлы обновлял в качестве подарка?

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

Добавлено через 4 минуты и 20 секунд
Вот тебе пример.
На винте:

Проект 1 в IDE - основан на папке /projects/prj1; папка /projects/libs подключена к проекту.
Проект 2 в IDE - основан на папке /projects/prj2; папка /projects/libs подключена к проекту.

Схема упрощена до предела, но достаточно наглядна.

O! Вот он человек, который мне все объяснит!  Итак, у меня проект. Svn умеет делать команды copy, move, update, commit, merge... Ничего не упустил? У меня есть еще один проект с нужными мне в первом проекте файлами. Нужно их ПОДКЛЮЧИТЬ!  ЧТО мне делать? Лучше, если объяснение будет  в терминах Sublipse, но и  в терминах самого subversion'а, возможно, пойму...

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

проект - это каталог. Он лежит у меня на компутере и имеет имя "project1". Вот ЭТО по моему - проект. Он самодостаточен, в определенном смысле... Есть столь-же самодостаточный проект в каталоге "project2". Раньше, в vss, все эти проекты лежали себе разными папками и имели ЛИНКИ на некотоые из файлов внутри проектов. Файлы похожи только содержанием и именем, но не относительным адресом внутри проекта. При изменении "общего" файла в проекте 2  я мог получить его изменения в проекте 1 просто выполнив 1-у команду - "сравнить с проектом" и 2-ю команду - chechout.
В принципе, при доверии к источнику изменений можно обойтись одной командой!
Я желал бы получить рецепт, как такое-же сделать, используя svn + Subclipce и/или Тортилу. пока я нашел способ сделать примерно такое-же, за несколько команд. если вы знаете способ сделать это быстрее - я с удовольсьтвием его выслушаю.

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

Не поймёшь. Потому что упорно пытаешься всё свести к свну. А тут дело НЕ в нём.

А вот это у тебя в джаве не прокатит. Если файлы равны по содержанию, то они обязаны иметь одинаковое имя файла, класса и пакета. Что приводит к тому, что эти файлы будут иметь одинаковый "относительный адрес" (из-за пакета в первую очередь). Если же ты раскладываешь файлы по разным пакетам в разных проектах (ладно свои-то файлы, но вот хз, как ты будешь это делать с чужими либами    - если только потрошить их и переписывать пакеты во всех файлах либы... ), то файлы будут различаться и по содержимому. И в этом случае их НАДО держать в свне в РАЗНЫХ местах и БЕЗ какой-либо явной связи.


Вот уж хз. Всё больше похоже на дефект в ДНК, не в обиду будет сказано парню. Ну или заработался настолько, что уже плохо соображать стал - все мы люди. Будем терпеливы и постараемся объяснить-таки человеку, чего же именно он пока не понимает.

 а кто сказал, что я о Java? Пусть это будет html страничка с подключенной к нему библиотекой jQuery... уверяю Вас, в таком случае содержимое совсем не определяет название и относительный путь файла  



Я пытаюсь сформулировать конкретный пример и получить на него конкретный проект решения. Итого - на компутере есть 2 каталога с файлами a.html, xxx.js в одном и b.html, xxx.js в другом. Это - Два разных проекта. Развивающихся своей жизнью. У них один файл xxx.js - библиотека, новую версию которой периодически выкачивают из интернета. В песпективе - появнение еще N или может быть даже M проектов, использующий этот самый xxx.js Для определенности, у нас есть локальный репозиторий, созданый Тортилой. Мне хочется узнать как НУЖНО подменять в двух разных проектах один файл на следующую версию используя минимут телодвижений

Вот, что я,  называю "решение в терминах svn":
создаем отдельный каталог с "общими библиотеками" и называем его lib. 
svn import <lib>
svn import <каталог 1>
svn import <каталог 2>
- итого - в базе 3 каталога. Из проектов 1 и 2 удаляем xxx.js (можно было бы почистить его до импорта...)
копируем файл в проект svn copy svn:lib/xxx.js в <svn:каталог1> и в <svn:каталог2>
- все - создали сстему репозиториев в которой будем жить...

Нормальный цикл разработки - разработчики делают update - commit до полного удовлетворения...

При появлении новой версии xxx.js "администратор", совсем даже не обязательно разработчик этих проектов, делает себе svn checkout <lib>, подменяет xxx и выполняет commit, после чего рассылает письмо разработчикам и с чистой совестью идет пить пиво.

Разработчики, получив письмо, начинают делать merge своего xxx.js с svn:lib\xxx.js, по получении удовлетворительного результата update'ят его и продолжают жить долго и счастливо...

Все так и есть? Если так и есть, то вот момент, который меня раздражает. В случае, если вместе с xxx в проекты вкючаются еще и файлы yyy.js и zzz.js, новые версии которых также появились, разработчикам потребуется вручную merge'нуть каждый из них. От разработчика требуется слишком много ненужных ему знаний и умений. Нельзя ли как нибудь автоматизировать это процесс. В идеальном случае, imho, после создания проекта разработчик вполне может забыть про существование lib'а...

Прошу прощения - слежу в основном за форумами по джава и не глянул, в каком тема. 

А зачем копировать? Оккама бы тебе своей бритвой по горлу бы уже съездил. 
Бери библиотеки прямо из папки библиотек в репозитории. И нефиг их по всем проектам ещё раскидывать дополнительно.

Если это библиотеки, то зачем их мержить. Если же это файлы конкретного проекта - опять же, зачем? что там мержить? Из-за чего эти файлы вдруг должны измениться если библиотека обновилась? Если из-за неких изменений в интерфейсе библиотеки, то да, пусть тот, кто отвечает за проект (каждый в отдельности) произведёт перевод файлов на работу с новой версией библиотеки. Я же уже писал об этом, блин.

Лишь в том случае, если:
а) либа работает прекрасно и без глюков
б) текущая версия либы полностью устраивает и обновления версии производятся нечасто
в) при обновлении либы всё старое остаётся полностью работоспособным и не требуется производить изменений в коде
Но я никак не возьму в толк, каким боком этому способствует система контроля версий и уровень знаний разработчика. Пусть хоть дворник за компом сидит - если либа стабильная и никакой идиотразработчик её не изменяет вручную, то проблем с нею быть не должно.
И уж сделать один апдейт после обновления либы - куда уж проще?

Что такое 
 и чем оно отличается от 
? Копируем - чтобы в истории файла в проекте осталось напоминание откуда исходный файл пришел... 

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

 Если просто скопировать файлы в окне Subclips'a из одного проекта (библиотечного) в другой, у меня получается, что файл удаляется, и новый файл, остающийся после этого нужно отдельным действием опять впихивать в репозиторий.
Если -же merge'нуть его - то на одно действие меньше, хотя сам мерже значительно мерзее ;)

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

ksnk, у тебя там в пределах локальной досягаемости нет никого опытного в разработке? В плане, чтобы прям "зубр" был. Если есть возможность обратиться к старшему товарищу - попробуй спросить у него. Можно просто показать эту тему и попросить объяснить, что да как.

Ну, если вам кажется, что это не филиал Беловежской пущи, а сосвем даже местный обезьянний питомник, то кто я такой, чтобы спорить с мнением модератора ;)

Добавлено через 53 секунды
Sorry, ничего личного, просто не удержался от провокации 

Дык, я и не модератор. И как говорилось в одном фильме: "если ты хотел меня обидеть, то... это у тебя не получилось". 
Просто, как тут уже неоднократно замечали, ты почему-то упорно не хочешь понять того, что тебе говорят. Вот я и рекомендовал то, что будет эффективнее, чем дальнейшие (по крайней мере мои) попытки объяснить на форуме. Если придёт в голову ещё идея, как объяснить - попробую.

Да ладно! просто подходящий повод подвернулся... Извиняюсь 

однако я так и не понял что-же вызывает в описываемой мной ситуации истерический смех? Проект состоящий из набора файлов в одном каталоге - реальность не только для меня, а, imho, для многих других web-разработчиков. Весьт каталог тупо грузится на сервер, где и работает...
Ситуацию описанную мной (2 проекта по 2 файла, один - общий) может воспроизвести любой обладатель Тортилы минут за пять. набросать производимые при этом действия - еще минут пять. Я потратил несколькобольше, но я при этом еще  и документацию читал... Зубрам - легче   Неужели это так трудно? Я буду просто искренне счастлив услышать хоть сколько -нибудь содержательный ответ на мой достаточно, imho, четко сформулированный вопрос. Как это НАДО БЫЛО сделать?

не правильность подхода к потроению проекта

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

сочувствую. может ещё и структура этого каталога проецируется на структуру сайта?

Daevaorn,  ваш ответ звучит для меня как "у меня есть конфетка, но я ее не дам!" ;-)

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

Хотя тот факт, что "проект для SVN", а не "SVN для проекта" меня несколько напрягает... с vss таких проблем просто не возникало...

Дык, рассказывали уже.
Делаешь в свне три папки - проект1, проект2 и либз. (это ты уже сделал, так что ты уже полузюбр   )
Делаешь на винте три папки - проект1, проект2 и либз. (это ты почему-то упорно не хочешь делать, так что ты пока недозюбр)
Создаёшь в эклипсе проект1 и указываешь ему в качестве папок с исходниками - проект1 и либз. (это ты почему-то пока не понял - видимо, ещё особо не игрался с настройками проектов)
Создаёшь в эклипсе проект2 и указываешь ему в качестве папок с исходниками - проект2 и либз. (это ты почему-то пока не понял - видимо, ещё особо не игрался с настройками проектов)

Всё, дальше всё просто. Обновился проект1 - апдейтишь проект1. Обновился либз - апдейтишь либз. И тебе не трудно, и Оккаму бояться не надо.

Добавлено через 1 минуту и 33 секунды

Потому что VSS - это как... как бревно, в то время как цвс/свн - лодка. Да, плыть можно и на бревне, но удобнее, приятнее и быстрее - на лодке. 

Ооо! Открой для себя темплейт "New Java project"... Спасибо добрый человек ;-) 
Всю жизнь создавал проекты в темплейтах 'web project' и 'PHP project', ан, оказывается ушлые java девелоперы себе  отстслюнили этакую пользу и молчат, как рыба об лед ! ;)

Будем становиться зюбрее!

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

Для читающих топик ради решения аналогичной проблемы: параметр svn:externals для папки с библиотеками в папках проектов спас бы автора топика.

Подробности по-русски нынче описаны здесь:  http://habrahabr.ru/blogs/development_tools/15823/

Раз уж тема поднялась (4 года уже  ), то вот мой теперешний взгляд на web-конструирование.

Проект состоит из личных файлов проекта, расположенных в отдельном каталоге. К проекту подключаются с помощью svn:external дополнительные общие проекты, участвующие в нем. Получается развесистая система каталогов с исходниками. Тут ничего особо оригинального, все как описал Nashev

А вот потом начинается самое интересное.
Вводится нетипичный, с какой-то точки зрения, для web-программирования этап строительства образа. Напоминаю, что речь у меня идет PHP проекте. Написана на php некая make-подобная утилита, которая по измененным датам исходников копирует их в build каталог. Build-каталог является тем самым образом, который уже и грузится на сайт.
Некоторые файлы при этом добиваются характерными шапками с номеров ревизии svn и т.д. Некоторые собираются более сложным образом. Подход не используется в PHP программировании постольку, поскольку в PHP нет привязки к исходным файлам. Нельзя компилятору сказать, чтобы он ругался в этом месте не на строчку XX файла YY, а совсем даже на строчку ZZ, как во многих системах программирования. Однако жить как-то надо  Остается только обеспечить небольшое количество таких "скомпилированных" файлов и их прозрачность для понимания и отладки.

В принципе, функциональность утилиты перекрывается make'ом. Одно время до нее я использовать встроенные в ant возможности для сборки проекта, хотя их стало не хватать на каком-то этапе.