Возможность выгрузки конфигурации в xml файлы объявленная в 8.3. Что это даст и будем ли мы использовать связку 8.3 + github.

что такое "github"?

Да, мы тоже читали статью на хабре.

Если это будет удобно и/или необходимо.

только для контроля изменений на большом периоде, например в конце дня выгружать конфу и потом за месяц смотреть че менялось. Для оперативной работы и всяких слияний не катит, особенно для больших баз. Вот если бы конфа 1С была ИЗНАЧАЛЬНО в виде папки с этими файликами, тогда другое дело

(2) Я не читал.
(3) Народная отчетность какая нибудь может появится)

нене, чтобы Хомяков потом все поломал ...

Выгружать каждый раз в файлики при каждом сохранении? Нафик

(7) зачем при каждом?

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

(0) а вот скажи мне, тс, причем здесь гитхаб вообще?

+(4) лучше бы сделали чтоб по умолчанию конфа хранилась бы в виде файликов, а *по требованию* ее можно было бы упаковать в .CF

(0) мля, википедия закрыта, что такое GitHub ?

(12) ты с Луны что ли свалился?

http://ru.m.wikipedia.org/wiki/GitHub

(11) Возможно так и происходит, просто мы не видим процесса упаковки) все происходит в памяти)

(12) в гугле тоже забанен?

(16) мне только мисту разрешили читать

(4) Для этих целей проще использовать хранилище конфигурации

(4) для совместной разработки все равно лучше тратить время на это ...
а выгрузка загрузка разве не по фильтру?

ответа так и не получил

(18) Хранилище, для множества разработчиков не подходит.

(21) почему?

мне кажется, это не покатит. SnegHub надо запускать

1. Долго, УПП - 10 минут выгрузка, размер 1.2 гига только исходников.
2. Надо разбивать по подпапкам, весь список конфигурации в одной папке - фе.
3. Выгружаются даже несохраненные данные, очень удобно посмотреть список текущих изменений, но долго.
4. Нет возможности указать варианты загрузки - с ошибками загружать или игнорировать.
5. Как всегда про внешние обработки и отчеты забыли.

Итого:
пользоваться будем, но не github, а redmine +git.
1. Орефков обещал раскопать возможность выгрузки только изменений. (надеюсь получиться).
2. Скрипт написать по разбивке на папки и обратной сборки - плевой дело.
3. Ветки рулят.
4. Надеюсь можно будет использовать микро-commit.

(22) вы работали?) Я пробывал, у меня постоянно возникали проблеммы. Если не ошибаюсь зайти в конфигуратор все равно может только один человек, потом подключение отключение итп, это все меня бесило не раз.

(25) ну ты дибил!!!! у каждого должна быть своя база

а вы что вели разработку прямо на рабочей??????

(26) нет ты.

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

(28) причем здесь все это? Ты не осилил как нужно работать с хранилищем. Думашь осилишь гитхаб?

Ты прав я дебил, а ты дартаньян. Поздравляю.

(24) а redmine +git, локальный сервер, поднимать будете для этого?

(29) ты скажи вы действительно вели разработку на рабочей базе?

(32) нет разработку вели не в рабочей базе.

Обычно не советуют рабочую базу подключать к хранилищу - лучше поставку делать, но кто-же слушается.
(31) а зачем его поднимать, скачал образ виртуальной машинки, создал проект, подключил к нему путь с хранилищем и пользуйся. Только учти, что парочку скриптов необходимо будет написать, по пакетной выгрузке загрузке.
(29) а как в хранилище организовать ветки? Или даже так есть отдел разработки и отдает на тестирование готовый код, пока тестируют отдел разработки дальше пишет и тут нашли ошибки и необходимо поправить, как в этом случаи организовать работу с хранилищем?

да хранилище - это дико неудобно, сплошная головная боль

не надо.

не надо

вот как, 2 раза проголосовал.. сейчас еще раз попробую..

не надо..

не проверяется количество голосов от пользователя...

(34) сколько у вас разработчиков, что вы ветки хотите создавать? Кто потом мерджить жти ветки будет?

(24)
Обещал, только не изменений, а объектов метаданных выборочно.
А уж какие выгружать, сами определяйте.

Ну и тут еще надо посмотреть, даст ли xml пользу.
Суть то ведь не в том, чтобы выгружать в файлики (это еще v8unpuck умел), а в том, чтобы файлики были как можно более человеко-читаемы. Если, например, для обычных форм будет xml файл, в котором один большой блок cdata с base64-строкой, содержащей "старый" бинарный поток данных формы - то что толку от такого xml? Ни продиффать его толком, ни промержить.

(42) Это понятно

я спать хочу

(41)1, 2, 5, 10, 100 - какая разница? Реально, вот какая смысловая нагрузка в вопросе "Сколько разработчиков"?
Отвечу, что бы не придрался :
2 штуки.

(42) сейчас формы тоже не сильно то и помержишь. Главное тут, что обратно объекты метаданных может загружать.