shsa
Сергей Шилов

Описание решения проблемы переполнения стека при выполнении операции закрытия месяца "Распределение затрат и расчет себестоимости" в 1С:ERP Управление предприятием, редакция 2.4.13.123.

(16) Xershi,

Цитата
они и будут теряться дальше. Пока не восстановите правильный вариант. Если правильного уже нет, то чистим кэш и переподключаем хранилище.

Чистим именно cache репозитория?

(13) spacecraft,
Подтверждаю, что на чистой базе этот фокус не прошел (сделал более 5 круговых обновлений), поэтому соглашусь с утверждением (14) Xershi, что подобная проблема проявляется себя при определенном уровне "засранности" кэша. Что, тем не менее не умаляет ценность моего опыта, т.к. можно говорить о гарантированной потере кода через какое-то время, если коммит делать после динамического обновления, а не до него.
Лично сейчас практикую следующий подход, если приходится работать на живой базе: захватываю объект, отлаживаю его в динамике, когда готов закоммитить, вношу в него незначительное изменение (пробел, комментарий), после этого коммичу.
До того, как столкнулся с этой проблемой, очень долго пользовался хранилищем без единого нарекания, но мой коллега, который регулярно работал с живой базой, довольно часто терял код. Когда мне самому пришлось поработать с живой базой используя динамическое обновление - впервые столкнулся с этой проблемой лично. Описанный мной способ гарантированно повторяется на нашей базе, кэш не чистился очень давно.

P.S.: Почистил сейчас кэш %USERPROFILE%\Local Settings\Application Data\1C\1Cv82\ (%LOCALAPPDATA%\1C\1Cv82\ для ОС Windows Vista и выше) и папку cache репозитория, проверил - проблема повторилась, но с оговоркой: после чистки кэша, появились изменения, которые были потеряны до чистки, но новые изменения все так же "теряются".

(11) spacecraft,

Цитата
Прежде чем обновлять другую базу необходимо принудительно "Получить из хранилища". Пробуйте.

Теперь еще раз читаем:

Цитата
в хранилище создается новая ревизия, но она содержит старый код до изменения!

Разумеется, когда мне впервые пришлось столкнуться с подобной ситуацией, у меня были "идеальные" условия: я только что закоммитили изменения на рабочей базе и пытался получить их на тестовой, и ничего не мог сделать, т.к. их тупо небыло в хранилище. Я в этот период чистил кэш, переподключал хранилище, применял всевозможные попытки вытащить код, пока примитивным анализом ревизий не убедился, что нужного мне кода просто нет в хранилище.

----------

Дополнительно перепроверил предложение с принудительным "Получить из хранилища", на случай, если сам дурак. Система пишет, что такой-то объект получен из хранилища, как и случается всегда при наличии новых изменений, но изменений нет.

(5) sommid,

Цитата
только что попробовал - внес изменения в обработку, динамически обновился, сложил изменения в хранилище. Платформа 1С:Предприятие 8.3 (8.3.5.1146) Открыл обработку из хранилища - вижу свои изменения. Или я не правильно пытаюсь воспроизвести?

Только что перепроверил, платформа 8.3.7.1845, результат повторился. Думаю ваша ошибка, что вы пытаетесь проверить состояние коммита в той же самой базе. Прикол в том, что хранилище показывает что текущие изменения и версия в хранилище идентичны, сравнение объектов показывает, что они идентичны, но если загрузить изменения в другой базе, то изменений не будет, и хранилище снова будет показывать, что все актуально и версии идентичны.

Код
shsa, это попытка описать свои ощущения... Код пропадает где и когда?

Народ, вы вообще читали что я писал?
1) Захватываете объект
2) Вносите изменения
3) Производите динамическое обновление (важное условие)
4) И только после всего перечисленного делаете коммит
Результат: в хранилище создается новая ревизия, но она содержит старый код до изменения!
Всё! Это легко проверяемая последовательность действий.

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

Рекомендация простая: коммитить до динамического обновления.

(2) Xershi, да-да, обсуждалось и всегда встречаются примерно следующего содержания тексты:

Цитата
Как следует поступать в случае, когда после помещения объекта в хранилище пропадают внесенные изменения? Однозначного решения проблемы не обнаружено, однако существует набор действий, которые зачастую помогают в этом случае. ...

В данном посте я указываю конкретную последовательность действий, приводящую к потере кода, и указываю другую последовательность действий, которая позволяет избежать этой ошибки.

Хочу поделиться своим опытом работы с хранилищем конфигураций.
Некоторое время назад, мы с коллегой стали пользоваться хранилищем конфигураций, чтобы синхронизировать свои изменения, и столкнулись с тем, что иногда написанный код терялся, хотя гарантированно помещался в хранилищище.
Искал решение в интернете, но не нашел четкого ответа почему и как это происходит.

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

Народ и раньше предполагал, что это связанно с динамическим обновлением, но не был уверен в этом на 100%.

(83) Aleksey.Bochkov, Для решения проблемы с авторизацией под русскими никами использую следующий код:

Код
string username = "русский ник"; string password = "русский пароль"; byte[] bytes = Encoding.UTF8.GetBytes(username); username = Encoding.Default.GetString(bytes); bytes = Encoding.UTF8.GetBytes(password); password = Encoding.Default.GetString(bytes); webService.Credentials = new System.Net.NetworkCredential(username, password); webService.PreAuthenticate = true;