Справочный каталог Eclipse вне директории проекта eclipse, но внутри репозитория - PullRequest
1 голос
/ 16 августа 2011

[Обновление: см. Комментарии]

Итак, допустим, у меня есть такая структура:

/ trunk / src

/ trunk / platform / linux / [eclipseproject]

/ trunk / platform / windows / [eclipse project]

Я хочу, чтобы оба проекта могли видеть / trunk / src, открывать его файлы и использовать автоматическое выделение ошибок на этихфайлы.Я пытался создать связанные ресурсы для каталога.Это прекрасно работает с неприятными ограничениями.Он никогда не обновляется, если вы не импортируете повторно и не можете создавать / удалять файлы.Я попытался сохранить символическую ссылку в репозитории git, которая, по-видимому, с git 1.6.1 больше не работает.Я все равно попробовал, и после клонирования символическая связь становится нашей неработающей.

Это действительно просто для простоты доступа к основной базе кода для многоплатформенного проекта.Решение не обязательно должно быть элегантным, но оно важно.Так что я полагаю, что могу поручить каждому разработчику просто создать собственную ссылку sym на основную кодовую базу в рамках настройки среды разработки.Пробовал, и эти символические ссылки, созданные с помощью ln -s, похоже, не появляются в Eclipse и не могут быть импортированы.

Наконец я решил, что могу создать общий проект в / trunk / в Eclipse.Похоже, Eclipse достаточно «умен», чтобы предупредить меня, что это невозможно, поскольку он обнаруживает другие проекты глубже.

Любая помощь приветствуется.

1 Ответ

0 голосов
/ 16 августа 2011

Во-первых, комментарий:

'/trunk/xxx/yyy' - это подход SVN, в котором все ветви / теги «эмулируются» как каталог.
Они не нужны в Git.Достаточно двух ветвей (одна 'linux', одна 'windows');затем вы можете клонировать свое хранилище дважды, один раз в каталоге windows, один в каталоге linux.

Относительно возможного решения:
Если единственная разница между linux иПлатформа Windows, что касается Eclipse, это файлы .project и .classpath, я бы порекомендовал иметь только одно репо (для ваших источников) с двумя вышеупомянутыми ветками, каждая из которых включает в себя источники ифайлы затмений (специально для каждой платформы).

Таким образом, решение гораздо проще поддерживать: одно хранилище, одна структура.Две ветви.

...