Синхронизирането по начина на Zdrav няма да стане понеже проектите са вече на SVN и ги импортвам оттам. Дори и да има начин това да стане (редактиране на .cproject на ръка или подобни) няма да го направя просто защото не е правилният начин - преди да съм разбрал както значат онези числа няма как да съм спокоен че няма да направя беля. Ако ще го правя трябва да стане по начин, проверен от тези дето знаят какво са цифрите.

miro, разбирам че това което ти правиш е да разпространяваш сорс код, предполагам на ОС-ти. За тези цели се съгласявам че трябва да се съобразиш с изискването на клиентите - да могат да интегрират твоя сорс в какъвто и да е проект, под каквато и да е IDE. Ти пишеш компонент, който реално не се използва самостоятелно, а става част от произволен друг проект. Само че оттук идва въпросът дали този компонент трябва да ограничава, или дори да подтиква, клиентите към избор на определен тип проект? Ако в моя екип сме 20 човека свикнали с еклипс ще искаме да си ползваме благинките на managed проекта, а не да минаваме на makefile за да сме съвместими с другия код.

Ще ти дам пример - това, на което му викам "старото IDE" не може да сканира обратно elf и да предложи добър дебъг обработвайки elf файла. Ако искам да използвам твоя код в мой проект, то значи твоите мейкфайлове няма да ми свършат никаква работа. Тук идва следващото, за което вече стана въпрос с цитирания от теб lwIP - ако сорсовете са структурирани правилно интегрирането им в което и да е IDE (или мейкфайл) е лесно. Ако ли не имаш два варианта - преструктурираш, или правиш "завъртулки" в мейкфайла. Защо ли си мисля че точно в случая с lwIP първото е по-лесно?

Самият SVN има чудесни средства да го направиш това нещо. Ще ти дам пример: ние също използваме сорс код и библиотеки от други фирми. Имаме подобен конфликт със структурата на сорсовете им, и то не защото е лоша, а защото не отговаря на нашата организация. Естествено, този код се обновява периодично и не върви да го копираме в нашия проект - на следващия ъпдейт пак ще трябва да го правим. Затова го слагаме на SVN-а, така, както е дошъл, и чрез external връзки вземаме файловете и папките, които ни трябва, и ги организираме според нашите правила. Когато дойде ъпдейт го качваме на SVN-a и променяме връзките да вземат новите SVN ревизии. Това за нас са външни ресурси, или зависими проекти. Ние ги интегрираме в нашия проект чрез svn:external. Отделно имаме и външни сорсове, които другата фирма ни дава като SVN URL. В този случай подходът е идентичен - svn:external само че към техния SVN URL.

Темата е обширна, и започнахме да намесваме (пак) хардуерна абстракция, описание на платформи и конфигуриране. Ако искате да сцепим темата на друго място и да се опитаме да обменим опит? Аз лично имам интерес да чуя мнения по въпроса. Харесвам начинът по който са организирани нещата в линукс, но по принцип проектите ни не са чак с такъв мащаб и алтернативни решения винаги са добре дошли!

А, между другото, едно от най-дразнещите неща в "старото IDE" е това, че настройките на проекта и тези на workspace-а са в един XML файл. Ужасно е за конфигуриране, и за обединяване! Някой си максимизирал прозореца на редактора и всички останали имат конфликт като ъпдейтнат....
Тъй де, искам да кажа че дефинирането на проект за мен е нещо, което е независимо от хоста на който ще се ползва, и използваемо без допълнителни настройки, при условие че имаш вече средата. И освен това съдържащо всичко необходимо да си build-неш проекта (без toolchain-а, но с указание за използвания toolchain). Т.е. в момента който го чекаутна на Linux еклипс да имам работоспособно нещо - а не да търся отделно подходящ workspace, без който да не мога да си билдна нещата.
За да направя това ми трябва да знам само URL-а на SVN за желания проект. Ако makefile-овете ви не са на SVN си мисля че имате проблем. Пак пример - правите ОС или библиотека, и към нея предлагат пример за използването и, който представлява завършен проект, например за VS под WIN32. Пак ли ще държите makefile-а и/или VS проекта отделно? Ясно е че отделните софтуерни компоненти които са библиотечни нямат нужда от този makefile. Само че проекти които билдват изпълними файлове имат нужда от такива, и те трябва да са част от проекта на примера. И трябва да са достатъчни за да мога аз като клиента да ги билдна на моя хост, с моето VS, което има меню "Open project", и иска project файл. Или моя make, който пък иска makefile, който ти не искаш да е в проекта? Правилно би било да си имаш репозитори за сорса на компонента, и репозитори за таргет специфичните makefile-ове. Само че като поиска някой да ползва примера за VS да му дадеш URL към място, което събира двете неща и му го дава на човека като готов проект. Защото ако му кажеш двата URL-а и да му обясниш как да си ги сложи заедно ще имаш повече проблеми от тези, които аз бих имал с любителя на IAR.

Както казах и аз преди, и Zdrav, в момента в който нещо излезе от възможностите на managed проекта, имат много пътища - разделяне на проектите на подпроекти (което явно е било пропуснато в началото), добавяне на стъпки, добавяне на make таргети, и накрая, когато няма накъде - изкарване на мейкфаиловете от еклипса (автоматизирано) и редактиране на проблемното място. Само че както miro каза, в повечето случаи в мейкфайла прави нещата както са в managed. Разликата е в удобството - ние ще работим удобно докато излезе завъртулка, и тогава ще минем на make, а вие ще работите с мейк още от началото, дублирайки функционалността на еклипса. Няма лошо, ако предпочитате да пишете текстовите файлове. Но не можете да ме убедите че това е по-удобно.

На практика целта ми е да стигна до момента в който проекта да няма грам собствен сорс код - т.е. цялото ми работно копие да е само външни връзки към ресурсни папки на SVN-а. Това включва и makefile/project файловете, и описателните файлове на платформата. Не съм го докарал още дотам, ама малко остана. И защо го мисля така - ми защото няма код който да не може да се преупотреби в бъдеще, main, драйвери, описание на задачи, софтуерни модули, абстракции, конфигурации на системи - всичко може да се наложи да се ползва на повече от едно място, т.е. да се комбинира свободно с всичко. Управлението на такава структура с мейкфайл е много по-трудно, поне за мен. Не споря че при познаване на инструментариума на sh можеш да направиш всичко, да структурираш в множество малки модулни мейкфайлчета. Само че това е преоткриване на топлата вода - има вече доста подобни инструменти. Например bitbake. Пак можеш да направиш всичко. Въпросът е често използваните неща да са лесни, а по-сложните - възможни.

Темата наистина е много обширна... Въпросът не е да се убеждаваме, а да обменяме идеи и решения. Нека първо всеки да се запознае с решението на другия пък после да казваме кое по-удобното... Ако ти ми предложиш по-удобен и по-добър начин на организация аз с удоволствие ще го "открадна"... И бирата ще е от мен


Значи организацията на един проект касае много аспекти. Не е само компилация или линкване или документиране. Има много неща. Някои от тях са въпрос на стил и предпочитания. Примерно на пръв поглед няма значение как си кръщаваш функциите в кода. Но е добре да имаш стил, за да е по-прегледно. А при големи проекти с хиляди сорс файлове вероятността да дублираш имена става прекалено голяма. Така че дори и на пръв поглед стила да изглежда само препоръчителен, в дадем момент си става задължителен...
Разбира се има много аспекти от организацията на проекта, които просто са задължителни и трябва да бъдат уточнени предварително. Примерно как се конфигурира дадена библеотека за едно или друго приложение. Дали е по време на компилация като използваш define, дали е по време на линкване с weak, дали е по време на run time с променливи/параметри....

Както и да е... да се върна на използването на мейк и по-специално на начина по който аз го ползвам.
Първо за всеки проект трябва мейкфайл, това е повече от ясно. Но доколкото писането на правила и т.н. не е много приятна и лесна работа аз съм се ограничил до един единствен мейкфайл. Така не пиша нов, само го копирам. Да, дублира се (един и същ мейкфайл) във всеки проект, но така или иначе във всеки проект трябва да има мейкфайл...
Естествено, за да е идентичен мейкфайла уникалните неща трябва да са изнесени от него. И те са изнесени в така наречените мк-файлове. В всяка сорс директория имам по един module.mk файл. В тоя файл изброявам сорс файловете от съответната директория.

За елементарни проекти това е всичко! Един мейкфайл в главната директория и по един module.mk файл във всяка под-директория. Като мейкфайла е универсален (не се пипа) а в мк файла просто се изброяват сорсовете... Не мисля, че това е "неудобно" или по-сложно от "заквасването" на Zdrav... Ествствено мейкфайловете си ходят заедно с проекта, така че като си свалиш от проект може да го компилираш директно без да се налага да му баеш.

Ето как изглежда на практика един прост мк-файл:



В случая в local_c_src-y се натрупват всички локални С-сорсове. После локалните променливи се натрупват в глобални. Между другото това с ъпдейтването може да се изнесе от мк-файла и да се опрости още (просто не съм си го поставял като цел).
По-надуло в local_modules-y се изброяват пък модулите (поддиректориите на текущата).

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

Сега малко "по-сложни" неща, примерно:



Аз в предишните постове вече казах че във всеки проект си имам конфигурационна директория. И там се задава стойност с 'y' или 'n' на разни USE_XXX опции. Така в конфигурацията на практика си задаваш кои от сорсовете да се USE-ват и кои не.

Ето друг пример:


или пък


В случая фамилито е атмел/луминари а пък кура е арм7 или куртекс. Та когато имам платформно зависим код, за всяка фамилия или за всеки кур се прави поддиректория и се слагат там неговите неща.

С две думи така се прави условно компилиране. В случая става дума за ос може да го видиш тук Идеята е че в ОС-а може да има различни стекове, драйвери и прочие простотии. И всички синхронизират целия ОС, не само части от него. И съответно в общите части всичко трябва да е идентично, включая и мк-файловете, та затова се налага условното компилиране...

По принцип може да стане и както го описваш то с svn:external но това не е за препоръчване. Хайде моят ОС не е толкова голям.. но има ОС-ве с хиляди файлове и там ако почнеш така със "събиране" на сорсове ще направиш голяма боза.... Винаги се прави с опции. Евентуални трябва да има проверка (аз нямам) коя опция кои други изисква... Коя опция с коя се изключват взаимно и т.н.

Спирам дотук... надявам се да става ясно че "текстовите" файлове не са никак сложни за работа. Но в същото време са много по-мощни. Аз тук показах само някои неща за условно компилиране, но по принцип това си е скрипт и мога да извикам всичко, да правя логики, проверки и т.н.

Интересно ми беше да прочета споделеното от теб, и може би ще ми влезе в употреба.
Само ще ти препоръчам да прочетеш малко за svn:external. Ползваме го отскоро (няколко години) но е един много мощен инструмент в арсенала на SVN-а. Не знам дали ще го приемеш като истина но ползване на SVN само е първата стъпка. Големият преход става с тия външни репозиторита. Не съм добър в обясненията и ще оставя на това който иска да се запознае е тях.
Те решават много елегантно въпроса с недопускането на дублиране на код и капсулирането на отделни софтуерни модули. Както вече споменах те позволяват проекта ти (например example за ОС-a за STM32) да е изграден изцяло от външни връзки - към сорсовете на ядрото на OS-а, към използваните драйвери и подобни ресурси, към описанието на платформата (target папките ти). Без в него да има грам "локален" код - дори main() функцията е преизползваема и е безсмислено да я има отделно във всеки проект.
Когато ги ползваш налагат (или по-точно предразполагат) към добро и чисто структуриране на кода. Да, пак са нещо което е специфично за SVN, т.е. вързан си с инструмента SVN, но така или иначе е немислима работата без някаква система за версионализиране на кода.
Отделно, само ще загатна, всяка връзка може да се даде като връзка към най-актуалната (HEAD) версията на външния ресурс, или към точно определена версия на кода на този ресурс (например 22-ра версия). Т.е. SPI драйвера ти си стои на това външно репозитори, един клиент иска да добавиш нещо, и то бързо. Разработваш си промените и качваш версия 23. Никой друг проект не усеща промяна защото те са свързани с ревизия 22. Проектът за новия клиент обаче се свързва към ревизия 23 и има новите неща. Не тестваш нищо друго освен проекта в който има нужда от тези нововъведения. Обратната посока важи също - в твоя SPI драйвер ползваш чужд (външен) код. Понеже си задал че искаш в твоя проект да ползваш точно версия 44 на този външен ресурс си спокоен че каквото и да творят "колегите" няма как да ти счупят кода понеже сменили нещо и не се съобразили че ще ти направят беля.
Отделно си ползваш спокойно бранчове и тагове и си свободен да правиш единственото необходимо - да развиваш SPI драйвера, или ОС-а, или каквото там искаш.
Този проблем (с версиите) е решим и с makefile - няма спор, но е балкан работа да го направиш толкова удобно колкото external-ите.

Всъщност ми е интересно как решаваш тези проблеми? Това няма общо с managed/make проектите, но не разбирам как успяваш да поддържаш кода си.

Това за svn:external ми е интересно... ще трябва да го разуча по-подробно. Ако имаш по-читаво ръководство кое как става дай насам

При мен проблемът е че работя с два по-големи клиента и всеки от тях си има собствени сървъри и репозиторите. Но никой от тях не иска да си отваря сървъра за външни хора. Та затова се принудих аз пък да направя трети сървър на който да стоят общите/публични неща.
В крайна сметка софтуера на едно изделие се получава от 2-3 репозиторита. От гугъл се взема кърнела и някои публични неща. При единия клиент ОС има и малко по-специални драйвери и стекове и отделно са крайните проекти.

Донякъде е неудобно един проект да е нацепен на 2-3 части. Но не можах да измисля по-добър вариант. А пък в последствие се оказа не толкова лоша идея защото ОС-а и частните стекове станаха като библиотечки. И само се линкват в крайното приложение, така че компилацията значително се ускори като време. Иначе беше кошмар на всяко компилиране пушех по цигара

Относно проблемите с версиите... По принцип когато правим релийз таг-ваме проектите. Ако се наложи после можем да възстановим точно същия сорс като се чекоут-не нужната версия. Стига да не сме забравили да сложим таг при релийза

Но по-важното е че се стремим да няма проблеми с версиите и съвместимостта изобщо. И точно тук малко се различават подходите ни... При теб както го описваш свързваш напълно независими парчета код. Докато при мен аз се опитвам да го играя арбитър. Всъщност не само аз... самата организация е такава. Значи общите проекти като ОС-а представляват набор от опции.

Примерно някой колега ако реши да направи нова платка. Естествено той би могъл да си вземе само онези сорсове дето му трябват. Но ако постъпи по тоя начин аз ще му бия шута и ще го оставя да се спасява сам... Който иска съпорт, трябва да ползва целия проект. В смисъл трябва да чекоутне всичко, след което да си направи конфигурация в която да укаже какво ще ползва и ако не е супер секретен проекта трябва да качи обратно конфигурацията си.
Идеята е, че всеки трябва да има достъп до всички конфигурации. И ако се наложи да правиш промени в общите части не е достатъчно да тестваш само собствената си конфигурация. Желателно е преди да качиш промените да прекомпилираш и чуждите конфигурации. По принцип това не е гаранция че не си омазал нещо, но поне да се компилира....

То тоя подход се ползва при почти всички ОС-ве. Предполагам си виждал разните там board директории... Та те не са само за украса или само за тия дето ще ползват тоя борд. Те са там точно за да не ти "счупят кода"

Конкретен източник за svn:externals не мога да ти посоча, ползваме хелпа на SVN-а и всякакви сорсове от интернет.
И ние ползваме таг-ове за release-ите, само че практически стават ненужни - в този таг има набор от файлове и папки с определени номера на ревизиите. Т.е. връзките са дефинирани стриктно дори да не направиш таг (стига да използваш фиксиран номер на версия, а не "HEAD").

Да, виждал съм организацията на Linux кърнела например, и там всичкия код е накуп. Само че не знам дали това не е само "външния" облик на нещата - отдолу май ползват GIT и не знам там как са разпределени нещата.

С externals не е задължително да вземаш сорс код - можеш да теглиш хедър и библиотека, както казваш за някой клиент. Така си пазиш нещата от външен достъп и модификации и пак можеш да сменяш както ти хареса. След като казваш че имаш няколко репозиторита, от които дърпаш за да събереш проекта, значи си узрял за externals. При нас в някои проекти са 10-тина външните връзки, в някой стигат до 30-40, и то вложени - клиента иска да дръпне SPI драйвера и слага неговия URL в проекта като external, само че вътре в проекта на SPI драйвера ти си сложил external към папката на OС-а. В папката на ОС-a обаче пък ти трябва нещо от googlecode. Там пак имаш връзка навън... По този начин клиента слага само URL-а на SPI драйвера, а оттам насетне кода чрез external дефинициите решава сам за себе си своите dependencies. Дали сочат към сорсове, или към хедъри и библиотеки е въпрос на лично предпочитание.

Ако имаш конкретни въпроси по externals, ще помагам. Не съм гуру, но ги ползвам доста.

Ето един пример: Имаш проект в който ти трябва да дръпнеш сорсовете на tmos от googlecode. Проектът има само main.c примерно. За да дойде сорса на tmos правиш папка в твоя проект до main.c , или на вече съществуваща такава слагаш svn property - за TortoiseSVN даваш десен върху папката, TortoiseSVN, Properties. Отваря ти се прозорец "Properties", даваш "New...", отваря ти се нов прозорец "Add properties", горе вдясно избираш от падащия списък svn:externals, и за Property value задаваш нещо такова: "TmosOS http://tmos.googlecode.com/svn/trunk/". Като застанеш върху полето property value излиза tooltip който описва какво да напишеш. Има стар и нов формат, ще разбереш кое върви на твоята версия на SVN-а.
Като направиш ъпдейт ще се създаде нова папка "TmosOS" и вътре ще дойдат сорсовете.

От страна на клиента долу-горе го разбирам, но как става от страна на сървъра?

Примерно сглобил съм си някаква компилация от няколко сървъра... Искам тая компилация да я кача като проект на един сървър, за да може и други да я ползват абсолютно същата.

Предполагам че трябва да става, но малко ми е мъгляво какво ще се получи и как ще работи... Дали няма да създаде повече проблеми. Примерно в компилацията съм вкарал конкретна версия на някакъв драйвер. Да, обаче се открие бъг и се редактира. Къде и как се comit-ват промените? На сървъра с компилациите, на сървъра с оригиналните?

Притеснен съм малко защото SVN-а за разлика от CVS много лесно се омазва... Аз примерно имах навика да копирам цели папки вътре из проекта. Да обаче то копира и .svn директорията и после се омазва яко като синхронизирам. Дава различни глупости или влиза в някакъв цикъл - аз комитна един файл, то разхронизира друг...

Нещата стоят така - проектът в който описваш връзките (т.е. svn:externals пропъртитата) също си го качваш на SVN-а, тези пропъртита също са текстови файлове и се контролират версионно. Т.е. "компилацията" ти представлява текстова, версионно контролирана инфомация която си има свой URL на сървъра. Ние му викаме "интеграционен проект". Нищо от него не се качва по оригиналните репозиторита на отделните компоненти. Това си е отделен проект.
Тия пропъртита представляват дефиниции на връзки към определен URL и към версия на кода от този URL.

Един прост пример за такъв проект има само една папка примерно с няколко обявени пропъртита в нея, даващи няколкото връзки към външните ресурси, без собствени сорс файлове (не че пречат, но за простота).

Т.е. все едно имаш един проектен файл в който пише това:

" -r10 TmosOS http://tmos.googlecode.com/svn/trunk/"
" -r25 SpiDriver svn://yourserver/Drivers/SpiDriver"
" -r8 AdcChipDrv svn://yourserver/Drivers/Periph/ADC/Microchip/MCP3301"
" -r14 STM32DemoBoard svn://yourserver/Platforms/ARM/Cortex/S ... 3DemoBoard"

Когато този "файл" (реално това са пропъртита на папка в SVN-а, но те пак са си файл) се качи на URL: "svn://yourserver/demo/ClientXXXTest" той получава ревизия 1. Даваш на клиент/колегите този URL и те работят с него.

Само че клиента се обажда и казва че Microchip не го кефят и иска да сменя на SPI ADC чип от TI с модел ADC123456. За който чип ти по случайност имаш драйвер на URL "svn://yourserver/Drivers/Periph/ADC/TI/ADC123456". Какво правим?
Отиваме в нашият проект ClientXXXTest и променяме пропъртито да сочи към другия драйвер, след което проекта (SVN) става следното:

" -r10 OS http://tmos.googlecode.com/svn/trunk/"
" -r25 SpiDriver svn://yourserver/Drivers/SpiDriver"
" -r8 AdcChipDrv svn://yourserver/Drivers/Periph/ADC/TI/ADC123456"
" -r14 Target svn://yourserver/Platforms/ARM/Cortex/S ... 3DemoBoard"

След тази промяна даваш ъпдейт на проект ClientXXXTest и получаваш новия драйвер. Качваш проект ClientXXXTest на SVN на URL "svn://yourserver/demo/ClientXXXTest" и получаваш версия 2 на проекта ClientXXXTest.

Билдваш, клиента е доволен. Ама Фукушима изпуска пара и TI казват няма чипове до на зима. Клиентът казва - давай пак Microchip. Какво правим - ами чекаутваме ревизия 1 на проекта ClientXXXTest и работим с драйвера за микрочип (или правим ревизия 3 с драйвер за Atmel).

Примерът е ограничен, и не показва пълната сила на externals. Отделно не може да реши проблеми свързани с хаотичен код и липса на дефинирани софтуерни интерфейси и модули. Ако драйвера за TI има различен API интерфейс от този на Microchip нещата не тръгват от само себе си. Но това въобще не е и темата на разговора.

Ако примерно всичките ти библиотеки използват някаква форма на абстракция на интерфейса към OS-а (например POSIX), нямаш никакъв проблем на мястото на ОС да сложиш линк към коя да е POSIX операционна система (вместо tmos).

А относно бъгфиксването - като се открие проблем в драйвера за микрочип (текущата версия е 8 и в нея има бъг), ти го фиксираш и качва нова ревизия на svn://yourserver/Drivers/Periph/ADC/Microchip/MCP3301, която нова ревизия става номер 9. В проектите си сменяш реда на

" -r9 AdcChipDrv svn://yourserver/Drivers/Periph/ADC/Microchip/MCP3301"

Това изглежда ограничаващо на пръв поглед. Само че externals може да се ползва и по другия начин - ако пропуснеш частта с "-r8" винаги ще получаваш head версията. Така като бъгфикснеш ще получиш автоматично най-новата версия навсякъде (където ъпдейтнеш). Само че не се подлъгвай - така става неясно кой проект с коя версия на външните ресурси работи и след време не можем (поне не директно от проекта ClientXXXTest) да получиш точния сорс на проекта.
Отделно ти се налага постоянно да се бориш с обратна съвместимост. Хубаво е да се спазва, само че няма перфектни хора и не можеш да предвидиш всичко от самото начало. Ако проектите ти ползват фиксирана ревизия на драйвера си свободен да сменяш когато и каквото пожелаеш в драйвера, без да се ангажираш да преправяш всички проекти, които в момента си работят.

Аз какво правя - понякога, когато знам че има сериозно сменяне на код, включвам проекта да ползва head ревизиите докато постабилизираме нещата - не е удобно да сменяш по 10 пъти на ден ревизиите и няма смисъл. По-късно ревизията се фиксира на тестваната за дадения компонент и докато нещо изрично не наложи промяна си стои така.

Иска си известно време човек да посвикне и да си изгради система на работа.

Колкото до омазването - нямам такива впечатления, трябва да направиш нещо изрично неправилно през explorera вместо през tortoise - като например да копираш или изтриеш .svn данните. Но това си е логично. А през еклипс е доста по-лесно - там SVN-а ти е плъгин и нещата се случват "правилно" по подразбиране.

Има една особеност на external която е важна - ако например работиш в проекта ClientXXXTest и ти се наложи да направиш промяна в сорс, получен от такъв external - например в MCP3301 драйвера, и после дадеш Commit на главния си проект (ClientXXXTest), промените в MCP3301 няма да се качат.
Идеята е че след като си взел кода "отвън", то този код е споделен и не се знае на кого ще счупиш проекта (ако някой друг работи с head ревизията на MCP3301). В общия случай например аз ако дръпна tmos от googlecode, няма и да имам права да кача промените си горе. Затова решението е че качването на external нещата става само ако дадеш commit изрично от папката, която е създадена в резултат на външната връзка (т.е. папката OS в нашия пример). Според мен е много добро ограничение, понякога е дразнещо, но е правилният начин. Просто трябва да се има в предвид.

За съжаление не се случват правилно... даже е по-гадно, защото поне в Ц/Ц++ перспективата не се виждат .svn директориите. И може да направиш copy&paste без да се усетиш че ще копира и svn-информацията. После става мазало. Примерно направил съм копие на директория А и съм го кръстил В. Редактирам някой файл в В и комитвам. Но промените в локалната В директория отиват по файловете от А на сърсвъра. След което веднага ми казва че А трябва да се ъпдейтне и става един омагьосан кръг...

Иначе днес пробвах малко externals... но явно ще трябва малко да го осмисля и после ще видя как и дали ще го ползвам.

Виж, copy - paste никога не съм правил - не се сещам за какво ще ми трябва копиране на код два пъти в един проект - може би имаш предвид като template за следващата, но със сигурност не е нещо което да е проблем.
Имах предвид останалите неща - например rename.

А за екстърналите - да, иска се да видиш как ще ти пасне на организацията, но съм сигурен че и при теб ще е удобно. Ако има нещо неясно питай.

Ще питам разбира се... но за момента нямам много причини да го ползвам. Твърде малка ми е организацийката


Между другото колкото по-големи и сложни стават проектите, толкова по-удобни стават децентрализираните репо-та като Git. Не знам дали си ги разглеждал... Мисля че за вашите неща ще е по-добрo решение.