Поради ред причини трябва да заменя PVCS-a със SVN, и реших, че сега е момента да заменя и KodeWrite с Eclipse.
Работя под Windows (за сега),като идеята е в близкото бъдеще да мигрирам изцяло към Linux.
Инсталирах Еклипс. Добавих му Subclipse. Отделно инсталирах и TrotolseSVN.

Проектите до момента са ми организирани по следния начин:
(виж картинката)

Идеята ми е всички файлове свързани с даден проект да са ми в една директория - проектната.
В нея е и локалното ми работно копие на SVN-a (Prj_Repo).
В SVN-a искам да държа сорсовете на софтуера, както и проектните файлове на Еклипс-а.

За бакъп = периодично копирам цялото дърво на проекта на сървъра и на външен носител.

Въпроса ми е как да сетна SWN-a и Eklips-a, за да получа желаната организация на проекта?
Възможна ли е въобще подобна организация с Еклипс+SVN?

(До момента работя по този начин с КодРайт и PVCS и нямам проблеми, но с Еклипс+SVN нещата май не стоят така.)

два пъти го прочетох и двата пъти не можах да ти схвана организациите и питанията...

Принципно имаш репозитори с проекти, имаш и локални проекти... Ако искаш всичките проекти ги слагай в една директория, ако искаш ги организирай някак, важното е да не се преплитат.
Като начало си вкарай сървърите в перспективата SVN repository exploring. Там може да разглеждаш всичко от сървъра. Ако си харесаш нещо, десния и чек оут... то те пита после къде локално да гонзапише.
В Ц/Ц++ перспективата пък са ти локалните проекти. Ако искаш нещо да качиш, десния и team- share... то те пита за репозитори и път в него.

Сега файловете на еклипса аз не ги слагам никога в репозиторито. Това му е недостатъка, че в тях слага локални пътища, опции на плъгини дето не всеки има, пък файловете зависят от версии... С две думи тия файлове директно в svn ignore.

Локално също не виждам смисъл да се правят бакъпи, версии, чудесии. Само актуалната версия на сорсовете и толкоз. Ако ти се счупи компа вземаш нов, слагаш еклипс, чекоут и си ти. Ако се страхуваш, че ще се чупи съръра svn-a може да експортира и евнтуално с крон или нещо друго си го автоматизираш. Ако сървърът е публичен и нямаш конзола, слагаш един линукс на твоя машина и с svn external му правиш копие.

И аз не схванах има ли проблем - опитай с тази структура и ще разбереш. Единственото, което съм виждал като ограничение, е че по идея еклипса иска проектните файлове в корена на проекта. Не е задължително обаче ("default project location"), но имаше оплаквания по-рано от хора, опитвали да сложат проектите навътре в дървото. Мисля че с по-новите версии на еклипса нещата са оправени, но ако не ти създава неудобства, спази им правилото.
При мен в workspace-а проектите са отделни папки. Самият workspace не се качва на SVN-а. Качват се отделните проекти като отделни папки, и отиват в отделни репозиторита.


Аз качвам целият проект горе, заедно с еклипс файловете (.project, .cproject). Не съм видял абсолютни пътища, всичко си е релативно спрямо "project_loc", има си променливи за място на workspace, project, eclipse и т.н. Но това зависи от плъгин-а ти за toolchain
Така че директно на следващия компютър правя импорт на проект от svn-а и всичко си работи.
При положение че проектите ми са managed (т.е. без мейкфайл, използва се вътрешния билдър на CDT-то) ще е голяма лудост да настройвам опции на проекта на всеки нов checkout. Ползвам managed защото предпочитам настройките на проекта да са ми в GUI-то на еклипса, а не да редактирам мейк файлове.
Мога да ти предложа следното:
1. Създаваш си SVN repository (не забравяш mainline/trunk или както там искаш за да имаш после възможност за branch/tag)
2. Правиш си локалната папка с проекта както те влече, и я качваш (import на костенурката) горе.
В примера по-горе на сървъра ще се получи (през Repository browser можеш да разгледаш):

3. На еклипса му казваш да импортира проект от SVN, добавяш си репозиторите в wizard-а ( в примера svn://YourServer/Project1/MainLine/) , и дърпаш. Казваш му да дърпа като "проект който ще се настройва с wizard-а за нов проект"
4. Настройваш си проекта - тук зависи от toolchain-а и дали ползваш makefile или ще се довериш на еклипса за тази работа (managed проект)
5. Гласиш префикси на компилатори, пътища, .... докато го докараш да се билдва. Не ползваш абсолютни локации, разчиташ на системните пътища или на релативни пътища спрямо проекта или еклипс "инсталацията"
6. Като го билднеш успешно качваш промените горе, като добавяш еклипските файлове - .project, .cproject и папка .settings. По подразбиране стоят в най-горната папка на проекта
За проба отваряш нов workspace, импортваш проекта, тук вече ще се усети че има налични проектни файлове. Проверяваш защо не се билдва , оправяш и пак качваш.

Ако имаш файлове или папки, които се ползват в повече от един проект, или дори просто са самостоятелно смислени, погледни възможностите за svn-а за "external repository" ("svn:external"). Представлява характеристика на папка, в която се указва линк към друго репозитори, от което да се теглят файловете. Това друго репозитори ти съдържа споделените файлове, а в проектите си указал линк-ове към тях. Реално стоят на едно място. Имаш възможност да указваш линк-а да е към точно определена ревизия на външното репозитори, или да взимаш винаги най-актуалното.
Хипотетично един проект може да е изграден изцяло от компоненти от множество външни репозиторита, като само проектният файл е уникален.

Колкото до бекъп, пак хипотетично, от локален няма нужда. Стига да си организираш нещата така, че да не стигаш да моменти в които се въздържаш да качваш за да не попречиш на друг колега, качвайки нетествани неща. Това става лесно ако си пускаш навреме бранчове/тагове и спокойни си работиш там. Тогава можеш и на всеки час да качваш горе, с коментари какво качваш и защо.
Той самият еклипс си има приличен локален бекъп (Local History), аз го ползвам често. Не знам на какви събития пише версия, дали на време, на билд или на нещо друго, но върши работа.
Бекъп на сървъра със сигурност ще ти трябва, няма начин. Там не мога да помогна, нямам опит.

А пък като финал, макар че ползвам основно SVN все още, бих ти препоръчал да хвърлиш едно око и на по-съвременните алтернативи - Git го развиват, както и Mercurial. За последното има TortoiseHg, което е подобно на SVN-ското. Има един сайт - BitBucket, където можеш да хостваш и частни (скрити) проекти без ограничение на място или трафик. Там се поддържат и Git, и Mercurial. За SVN имаше Assembla, ама се изциганиха и махнаха безплатните.

Що не ползваш git?

вероятно, защото още не го е пипнала склерозата...

смисълът на git е да няма централизирано репозитори, което е удобно за проекти с хиляди участници.

git си става за всякакви проекти - включително и солови ... само трябва да му свикне човек

Едно от предимствата на SVN-а е че се поддържа от доста "среди", не само за софтуерен развой, но и за хардуер - визирам Altium. Не че KiCAD проектите не живеят чудесно на github-а, но за алтиум е друго.
Между SVN и GIT аз бих избрал Hg.
Сериозно, според мен това са инструменти, имащи за цел да улеснят работата на разработчика, и да гарантират сигурно следене на кода. Т.е. не е приемливо да те лишават от удобство за сметка на сигурност, или обратното.
До скоро по Windows ползването на Git беше shit , нямаше удобният вариант на tortoiseSVN/Hg. Сега май има подобен Git, но не съм го разцъквал, стои си инсталиран само. Под еклипс нещата са по-директни, там си го има EGit.

щом иска да ползва SVN значи има нужда от нещо такова. а git-а не виждам защо да е за хиляди, а не за 5 участника или 1? това, че може да се ползва с хиляди е нещо, което другите не могат.

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

Не схванах идеята за шизофренията и наличието на организация. Като работиш сам имаш нужда от 2 неща като второто не е задължително: 1) история на версиите; 2) 2 и повече работни места снабдени с актуален набор от проекти, по които работиш. И за двете неща git ти върши работа. Ако държиш да имаш централизирано репозитори, може да приемеш едното работно място за "сървър" или ако трябва да копираш проектите на трета система, където не работиш директно, а само се синхронизира (нещо като централен архив). Третото копие може дори да не е PC, а само носител (външен hdd, флаш).

Пример - имаш две версии. Ако си психично здрав би трябвало да знаеш коя ти е първа и коя втора. А за да не се налага да разчиташ на мозъчна дейност SVN предлага номерация.
Но ако сте хиляди и всеки бълва версии и вече няма никакво значение кое е първи кой е втори и кой 567-ми. Съотвено номерациите нямат полза, а са важни разликите.

Когато работиш сам, имаш 1 проект с 2 версии нещата може да изглеждат елементарни. Но като станат проектите ти 5-10, с по 5 подверсии и най-важното - като минат 1-2 години от последните ти промени - може да не си шизофреник, но ще усетиш загуба на спомени кое какво е точно и каква е била разликата с другото. При липса на добра (само)организация и няколко копия възниква един много неприятен ефект "кое/къде беше най-актуалната версия". Въпроса "кое" може да решиш със сравняване, но "къде" е по-сложен случай.

така е, затова се ползват репозиторита

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

Благодаря Ви за помощта.

Проекта който сега трябва да боря е доста стар и е SVN базиран, така че ГИТ-а не е вариант за момента.

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