привет
есть ли в svn возможность не трекать историю бинарников (в perforce например для этого можно указать тип файла "binary+S")?

Здравствуйте, sadomovalex, Вы писали:

S>привет
S>есть ли в svn возможность не трекать историю бинарников (в perforce например для этого можно указать тип файла "binary+S")?

Что имеется в виду? Не хранить в репозитории бинарники? Так никто и не заставляет их туда добавлять.

Здравствуйте, Хитрик Денис, Вы писали:

ХД>Что имеется в виду? Не хранить в репозитории бинарники?

нет
в репозитории нужно хранить информацию только о HEAD revision бинарных файлов. При очередном коммите бинарника информация о его предыдущей ревизии должна полностью удаляться. Это позволит нехило обезжирить занимаемое репозиторием место

Здравствуйте, sadomovalex, Вы писали:

ХД>>Что имеется в виду? Не хранить в репозитории бинарники?
S>нет
S>в репозитории нужно хранить информацию только о HEAD revision бинарных файлов. При очередном коммите бинарника информация о его предыдущей ревизии должна полностью удаляться. Это позволит нехило обезжирить занимаемое репозиторием место

Нет, такого нет. Как хранятся бинарные данные в SVN можно узнать здесь.

P.S. Да и необходимость этой фичи вызывает некоторые вопросы, на самом деле.

Здравствуйте, sadomovalex, Вы писали:

S>в репозитории нужно хранить информацию только о HEAD revision бинарных файлов. При очередном коммите бинарника информация о его предыдущей ревизии должна полностью удаляться. Это позволит нехило обезжирить занимаемое репозиторием место
Такое можно сделать, но потребуется dump/load-цикл.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, sadomovalex, Вы писали:

C>Такое можно сделать, но потребуется dump/load-цикл.

если есть такая возможность, то скриптик на питоне будет не сложно наваять. Но вот только я сомневаюсь что в пределах _одного_ репозитория dump/load поможет

Здравствуйте, Хитрик Денис, Вы писали:

ХД>P.S. Да и необходимость этой фичи вызывает некоторые вопросы, на самом деле.

необходимость возникает когда с этим сталкнешься. К примеру в .net-ном солюшене есть проект, который редко правится и который занимает большую часть времени при билде. Что приходит на ум? Положить сгенеренную dll-ку в source control system (предварительно сделав ее strong name, чтобы проблемы быстрее обнаруживались). А вот зачем трекать историю ревизий этой dll-ки в source control — действительно вызывает некоторые вопросы

Здравствуйте, sadomovalex, Вы писали:

ХД>>P.S. Да и необходимость этой фичи вызывает некоторые вопросы, на самом деле.
S>необходимость возникает когда с этим сталкнешься. К примеру в .net-ном солюшене есть проект, который редко правится и который занимает большую часть времени при билде. Что приходит на ум? Положить сгенеренную dll-ку в source control system (предварительно сделав ее strong name, чтобы проблемы быстрее обнаруживались). А вот зачем трекать историю ревизий этой dll-ки в source control — действительно вызывает некоторые вопросы

Вообще, хранить скомпилированные бинарники вместе с исходниками — не очень хорошая практика.
Первое, что приходит на ум, это не хранить специальным образом ненужные DLL в репозитории, а из конфигурации солюшена исключить указанный проект и делать ему билд по запросу или регулярно, раз в неделю/месяц и т.д.

Здравствуйте, sadomovalex, Вы писали:

C>>Такое можно сделать, но потребуется dump/load-цикл.
S>если есть такая возможность, то скриптик на питоне будет не сложно наваять. Но вот только я сомневаюсь что в пределах _одного_ репозитория dump/load поможет
Поможет. Есть возможность отфильтровать определённые ревизии файлов.

Т.е. раз в неделю запускаете "garbage collector", который выкинет из репозитория мусор. Смотрите в направлении svndumpfilter.

Но вообще, я бы что-нибудь поменял в workflow. Например, не использовал бы SVN для бинарных файлов.

Здравствуйте, Cyberax, Вы писали:

C>Например, не использовал бы SVN для бинарных файлов.

а как быть в такой ситуации — проект на несколько разработчиков, несколько разных средств разработки. Каждый отдельный разработчик в принципе не может скомпилить все на своей машине из исходников. Проект активно развивается, каждому нужно постоянно иметь последние версии всех бинарников. Где их брать?

Здравствуйте, Хитрик Денис, Вы писали:

ХД>Вообще, хранить скомпилированные бинарники вместе с исходниками — не очень хорошая практика.
ХД>Первое, что приходит на ум, это не хранить специальным образом ненужные DLL в репозитории, а из конфигурации солюшена исключить указанный проект и делать ему билд по запросу или регулярно, раз в неделю/месяц и т.д.

в некоторых ситуациях вообще необходимо избежать билда проекта — ситуация примерно такая, какая описана здесь

Автор: Odi$$ey
Дата: 02.08.08

. В этом случае хранение dll-к вместе с исходниками кажется вполне подходящим решением

Здравствуйте, Odi$$ey, Вы писали:

OE>а как быть в такой ситуации — проект на несколько разработчиков, несколько разных средств разработки. Каждый отдельный разработчик в принципе не может скомпилить все на своей машине из исходников. Проект активно развивается, каждому нужно постоянно иметь последние версии всех бинарников. Где их брать?

Использовать Dependency Manager, например Ivy? http://ant.apache.org/ivy/

Здравствуйте, sadomovalex, Вы писали:

S>А вот зачем трекать историю ревизий этой dll-ки в source control — действительно вызывает некоторые вопросы

Захотелось своего маленького dll hell в проекте? Стоит перестать трекать dll и ревизии которые работают со старой версией этой библиотеки с большой долей вероятности "поломаются".

Здравствуйте, sadomovalex, Вы писали:

S>привет
S>есть ли в svn возможность не трекать историю бинарников (в perforce например для этого можно указать тип файла "binary+S")?

Я такой возможности не нашел. Вместо этого храню сторонние библиотеки в отдельном репозитории и пользуюсь svn:external. Эффект тот же, но без побочных эффектов вроде поломки старых версий программы с новой версией бинарника.

Здравствуйте, SE, Вы писали:

SE>Захотелось своего маленького dll hell в проекте? Стоит перестать трекать dll и ревизии которые работают со старой версией этой библиотеки с большой долей вероятности "поломаются".

(предварительно сделав ее strong name, чтобы проблемы быстрее обнаруживались)

Здравствуйте, Odi$$ey, Вы писали:

C>>Например, не использовал бы SVN для бинарных файлов.
OE>а как быть в такой ситуации — проект на несколько разработчиков, несколько разных средств разработки. Каждый отдельный разработчик в принципе не может скомпилить все на своей машине из исходников. Проект активно развивается, каждому нужно постоянно иметь последние версии всех бинарников. Где их брать?

Из сурсконтрола. А вот что делать, например, когда в описанной ситуации разработчику потребуется собрать у себя локально не текущуюю версию, не какой-нибудь бранч, а конкретный changeset (не помню, как называется в SVN, но из названия должно быть ясно, что имеется в виду)? Если не хранится история, то это может быть невозможно.

Здравствуйте, sadomovalex, Вы писали:

SE>>Захотелось своего маленького dll hell в проекте? Стоит перестать трекать dll и ревизии которые работают со старой версией этой библиотеки с большой долей вероятности "поломаются".

S>(предварительно сделав ее strong name, чтобы проблемы быстрее обнаруживались)

В этом случае версия тем более "поломается" — она просто не соберется, это конечно лучше чем dll hell, но нужной версии подписанной dll может уже и не оказаться, не трекаем ведь.
И что тогда делать, если понадобится срочно рабочий билд за номером XYZ? А ведь это не такая уж и редкость.

Здравствуйте, SE, Вы писали:

SE>В этом случае версия тем более "поломается" — она просто не соберется, это конечно лучше чем dll hell, но нужной версии подписанной dll может уже и не оказаться, не трекаем ведь.
SE>И что тогда делать, если понадобится срочно рабочий билд за номером XYZ? А ведь это не такая уж и редкость.

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

Здравствуйте, sadomovalex, Вы писали:

S>есть ли в svn возможность не трекать историю бинарников (в perforce например для этого можно указать тип файла "binary+S")?

А чем не подходит способ "выложить это всё добро на общую шару"?

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, sadomovalex, Вы писали:

S>>есть ли в svn возможность не трекать историю бинарников (в perforce например для этого можно указать тип файла "binary+S")?

_FR>А чем не подходит способ "выложить это всё добро на общую шару"?

задампать для архива не выйдет — охота чтобы все было в одном месте

Здравствуйте, sadomovalex, Вы писали:

S>в репозитории нужно хранить информацию только о HEAD revision бинарных файлов. При очередном коммите бинарника информация о его предыдущей ревизии должна полностью удаляться. Это позволит нехило обезжирить занимаемое репозиторием место

А действительно есть проблема места? Svn очень компактно хранит историю бинарников.

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