Здравствуйте, 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, Вы писали:
OE>а как быть в такой ситуации — проект на несколько разработчиков, несколько разных средств разработки. Каждый отдельный разработчик в принципе не может скомпилить все на своей машине из исходников. Проект активно развивается, каждому нужно постоянно иметь последние версии всех бинарников. Где их брать?
Здравствуйте, 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, но из названия должно быть ясно, что имеется в виду)? Если не хранится история, то это может быть невозможно.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, 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")?
А чем не подходит способ "выложить это всё добро на общую шару"?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, sadomovalex, Вы писали:
S>>есть ли в svn возможность не трекать историю бинарников (в perforce например для этого можно указать тип файла "binary+S")?
_FR>А чем не подходит способ "выложить это всё добро на общую шару"?
задампать для архива не выйдет — охота чтобы все было в одном месте
