Можно ли сделать так, чтобы при изменения файлов в рабочей копии в одной из папок, они не воспринимались как измененные?
Если я помечу эту папку как svn:ignore, то исходники просто пропадут. Это не подходит.
Мне нужно что-то типа заморозки.

Здравствуйте, <Аноним>, Вы писали:

А>Можно ли сделать так, чтобы при изменения файлов в рабочей копии в одной из папок, они не воспринимались как измененные?
А>Если я помечу эту папку как svn:ignore, то исходники просто пропадут. Это не подходит.
А>Мне нужно что-то типа заморозки.
svn:externals на конкретную версию?

B>svn:externals на конкретную версию?
И что это даст? Вернее — как правильно это сделать?

Вообще есть вот такая структура:

Project1
   src
      com
         ...
   gen
      com
         ...

Все что подложено в каталог gen и закоммичено, допустим в ревизии 3, не должно больше изменяться.
Даже если оно изменилось в рабочей копии, то SVN не должен предлагать коммитить изменения.

Здравствуйте, Аноним, Вы писали:

А>Можно ли сделать так, чтобы при изменения файлов в рабочей копии в одной из папок, они не воспринимались как измененные?
А>Если я помечу эту папку как svn:ignore, то исходники просто пропадут. Это не подходит.
А>Мне нужно что-то типа заморозки.

А что svn должен сделать если эти файлы в репозитории поменялись? Обновлять или нет?
Вообще, я обычно в таких случаях кладу файлы в другое место, а в build-скриптах копирую в папку с svn:ignore (переводя с языка mercurial на язык svn ).

RT>А что svn должен сделать если эти файлы в репозитории поменялись? Обновлять или нет?
Все равно.
Главное чтобы он не предлагал их коммитить.

RT>Вообще, я обычно в таких случаях кладу файлы в другое место, а в build-скриптах копирую в папку с svn:ignore (переводя с языка mercurial на язык svn ).

К сожалению сгенеренные файлы лежат в куче с остальными.

Аноним 398 wrote:

> К сожалению сгенеренные файлы лежат в куче с остальными.
отмечай генерённые файлы svn:ignore и не коммить их в репо.

.>отмечай генерённые файлы svn:ignore и не коммить их в репо.
Та в том то и дело что они должны лежать в репозитории.
Но коммититься не должны.

Аноним 398 wrote:

> .>отмечай генерённые файлы svn:ignore и не коммить их в репо.
> Та в том то и дело что они должны лежать в репозитории.
> Но коммититься не должны.
Что-то у вас не так в консерватории. Можешь описать задачу, которую решаешь?

.>Что-то у вас не так в консерватории. Можешь описать задачу, которую решаешь?

Та задача простая.
Есть сгенеренные файлы.
И положенные под svn.
И программисты не хотят генерить эти файлы снова и снова.
Вернее для того чтобы они сгенерились, нужно выставить пару переменных.
А программистам этого делать не хочется.
Было принято решение сгенерить файлы один раз и засунуть их под svn.
И хотелось бы обезопасить себя от изменений в этих сгенеренных файлах.

Я понимаю что все это очень криво... Но на данный момент так есть.

Здравствуйте, <Аноним>, Вы писали:

А>Даже если оно изменилось в рабочей копии, то SVN не должен предлагать коммитить изменения.
С этим сложнее. svn:externals хорошо тем, что автоматически замораживает версию, скачиваемую с репозитария, но изменения всё же примет. Может быть, в сочетании с блокировкой что-то можно сделать.

Либо класть немодифицируемые каталоги в отдельный репозитарий или его часть и просто экспортировать их (svn export url@rev). Минус — ручной экспорт (можно положить соответствующий скрипт в репозитарий проекта и наказать всем запустить его после checkout'a рабочей копии).

<Аноним>,

.>>Что-то у вас не так в консерватории. Можешь описать задачу, которую решаешь?

А>Та задача простая.
А>Есть сгенеренные файлы.
А>И положенные под svn.
А>И программисты не хотят генерить эти файлы снова и снова.
А>Вернее для того чтобы они сгенерились, нужно выставить пару переменных.
А>А программистам этого делать не хочется.
А>Было принято решение сгенерить файлы один раз и засунуть их под svn.
А>И хотелось бы обезопасить себя от изменений в этих сгенеренных файлах.

А>Я понимаю что все это очень криво... Но на данный момент так есть.

Да, аналогичная задача возникает, когда нужно генерировать файлики AssemblyInfo.cs — без них не соберёшь, а генерировать их каждый раз неудобно (там хранится информация о версии и ещё всякая всячина, и напрягает не столько процесс генерации, сколько постоянная необходимость лицезреть их изменёнными и выключать их из коммита).

Я знаю 2 решения:

1. Нужно сбацать кастомный билд-скрипт или модифицировать существующий так, чтобы добавить таск "setup", готорый будет генерировать недостающие файлы. Генерируемые файлы не включаются в репозиторий и добавляются в .svnignore. Преимуществ куча, недостаток — необходимость явно вызывать "setup" при чекауте.

2. Чисто визуальный финт ушами. В одной из последних версий svn появилась фича changelist (в черепахе соответственно пункт меню "move to changelist") и предопределённый лист "ignore-on-commit". В один прекрасный момент добавляем все сгенерённые файлы в этот changelist, и они больше не мозолят глаза и не коммитятся даже если были изменены. Хотя их можно закоммитить явно.

LCR>1. Нужно сбацать кастомный билд-скрипт или модифицировать существующий так, чтобы добавить таск "setup", готорый будет генерировать недостающие файлы. Генерируемые файлы не включаются в репозиторий и добавляются в .svnignore. Преимуществ куча, недостаток — необходимость явно вызывать "setup" при чекауте.

Именно так у нас и сделано в одном из проектов.
Сделаем и в текущем, но потом.
А сейчас хочется странного


LCR>2. Чисто визуальный финт ушами. В одной из последних версий svn появилась фича changelist (в черепахе соответственно пункт меню "move to changelist") и предопределённый лист "ignore-on-commit". В один прекрасный момент добавляем все сгенерённые файлы в этот changelist, и они больше не мозолят глаза и не коммитятся даже если были изменены. Хотя их можно закоммитить явно.

Финт подходящий.

Excluding Items from the Commit List

Sometimes you have versioned files that change frequently but that you really don't want to commit. Sometimes this indicates a flaw in your build process — why are those files versioned? should you be using template files? But occasionally it is inevitable. A classic reason is that your IDE changes a timestamp in the project file every time you build. The project file has to be versioned as it includes all the build settings, but it doesn't need to be committed just because the timestamp changed.

To help out in awkward cases like this, we have reserved a changelist called ignore-on-commit. Any file added to this changelist will automatically be unchecked in the commit dialog. You can still commit changes, but you have to select it manually in the commit dialog.

Но проблема с выделенным.
Я хочу чтобы эти файлы вообще не предлагались для коммита.
Кроме того я не совсем понимаю, ignore-on-commit — это changelist для черепахи? Или для svn-а?
Что-то я не нашел ничего про ignore-on-commit в svnbook.red-bean.com

Аноним 398 wrote:

> И хотелось бы обезопасить себя от изменений в этих сгенеренных файлах.
Это можно сделать либо правами — сделать доступ только для чтения. Либо svn:need-lock.
Но это не спасает от того, что эти файлы будут болтаться изменёнными. Можно их тогда вынести в другой каталог.

<Аноним>,

А>Я хочу чтобы эти файлы вообще не предлагались для коммита.

Увы, так чтобы совсем "с глаз долой" — нет.

А>Кроме того я не совсем понимаю, ignore-on-commit — это changelist для черепахи? Или для svn-а?
А>Что-то я не нашел ничего про ignore-on-commit в svnbook.red-bean.com

Как я понимаю, ignore-on-commit — это changelist, который автоматически создаётся черепахой (видимо при установке) и без черепахи его нужно создавать явно. Наверное