[Uladzimir 68]

Ну то есть одна - которая проверенная.

И куча временных которыми делятся другие.

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

[Krys 2]

Если все создают компоненты, выкладывают во временную библиотеку, потом это проверяют и перекладывают в основную - это опять же перечёркивает возможность таким как я (с таким же миропониманием) пользоваться библиотекой как основной, т.к. не выполняется пункт моих пожеланий, что я это нарисовал - и сразу должен иметь возможность пользоваться, а потом к этому больше не возвращаться. В случае с моей локальной библиотекой - я нарисовал компонент, влепил и забыл. Согласно предложению о 2х библиотеках - проверенной и основной - я должен нарисовать компонент, положить его во временную базу, вставить в схему. А потом спустя дни поправить ссылку в этом компоненте на основную базу. Я забуду сделать это спустя дни. Или что-нибудь прогляжу и сделаю это не для всех компонентов. И начнётся у меня путаница... Из-за немалой вероятности возникновения путаницы (по моей же собственной запарке) я лучше вообще откажусь от использования инет-библиотеки как основной и опять же просто "надёргаю" компоненты себе в локальную, потом дорисую недостающие, потом выложу эти новые компоненты в инет (и то, если по запарке не забуду), но пользоваться ими уже не буду. Выложу и забуду про них... И править возможно не буду уже (допустим, из-за занятости), т.к. у меня нет прямой заинтересованности, ведь это у меня не основная библиотека.

 

________________________________________________________________________________

___________

... Предлагаю (не знаю как точно это реализовать и можно ли вообще), что добавлять новые компоненты в базу может любой. Править или удалять уже имеющиеся - только библиотекарь. Править ещё дополнительно можно наделить правом самого автора компонента. Это разгрузит библиотекаря. Библиотекарь взглянет и лишь выскажет автору пожелания, сам ничего править не будет, чтобы не тратить своё время. А поправит сам автор.

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

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

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

... Остаётся ещё один невыясненный момент: допустим компонент поменялся в базе, а я на это не рассчитывал. Сделал апдейт, получил другой компонент, который я ещё лично для себя не проверял. Необходим какой-то механизм, который гарантирует, что я никогда не останусь без извещения, что такие-то компоненты были модифицированы после лично моей последней их ревизии (проверки на правильность лично для меня).

[uriy 5]

При использовании SVN и Access возникает еще одна проблема. Как сделать Merge бинарной БД? Допустим имеется два пользователя их локальные копии синхронизированы с репозиторием. Каждый из них решил добавить по одному элементу в свою локальную БД. Элементы разные. Первый сделал comit. Когда comit будет делать второй SVN не сможет добавить запись в БД, он предложит либо использовать вариант БД из репоизитория либо переписать его своим, таким образом в БД появится только один элемент. И чей это будет элемент решает последний кто делает comit.

На момент редактирования БД пользователь может залочить репозиторий чтобы никто не смог его редактировать. Но по-моему это не выход. Придется периодически проверять когда лок будет снят.

[Uladzimir 68]

я это нарисовал - и сразу должен иметь возможность пользоваться

Пользуйтесь сразу. Это тоже можно

я нарисовал компонент, влепил и забыл.

Нарисовать мало. Это не компонент а часть его. Нужно сделать запись в базе, пусть собственной, со всеми параметрами

как из основной библиотеки ссылка на компонент сразу будет указывать на нужное место

Если имеется ввиду ссылки на УГО и Footprint то и та и другая будут ссылаться на одно и тоже. Максимум придется только отсинхронизировать, да и то только в том случае, если изменения (добавления) коснулись именно УГО и Footprint

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

Вот и я выше писал, что для этого нужно иметь поля для автора, и ...

проверен, сырой, проверен, содержит такие то ошибки и т.д.

Ну это хватили. Или проверен и все. Если проверен-- ошибок нет, все остальное риск того, кто юзает

по добавлению любым пользователем новых компонентов в базу ... Поэтому бардака не будет

Будет. У семи нянек-- дитя без догляду

Зато будет оперативность применения вновь нарисованных компонентов. В частности, самими авторами этих компонентов.

Да остается она- берите. пользуйтесь сразу. Но как я писал-- на свой страх и риск.

Ну если собственную ставите-- сами себе пальцы кусаете, при случае чего. Если чужую-- при кусании матюки еще добавятся

Сделал апдейт, получил другой компонент, который я ещё лично для себя не проверял. Необходим какой-то механизм, который гарантирует, что я никогда не останусь без извещения, что такие-то компоненты были модифицированы после лично моей последней их ревизии (проверки на правильность лично для меня).

Так программы синхронизации файлов и говорят какие файлы должны синхронизироваться, и вы вправе сделать или отказаться от этого.

В любом случае-- Вы хозяин собственного слепка из общей базы

[jkrieger 0]

Из проблем, на которые которые указали Krys и uriy, думаю возможны такие выходы (хотя опять же, пока что я не знаю как это реализовать).

 

Либо держать две БД (локальную, которой пользуются разработчики и основную, которая время от времени обновляется) и некоторым образом связать их, чтобы можно было в несколько кликов их синхронизировать, выявляя изменения (сегодня хочу поэкспериментировать с прогой Simple MDB Merge, авось поможет ). Либо как второй вариант попробовать использовать БД не бинарную, например SQLite (там вроде можно делать TextDiff), однако я не знаю можно ли в DBLib подключить SQLite. Кто пробовал подключить БД не MDB или XLS - отпишитесь пожалуйста.

[Krys 2]

Пользуйтесь сразу. Это тоже можно

Нарисовать мало. Это не компонент а часть его. Нужно сделать запись в базе, пусть собственной, со всеми параметрами

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

Касаемо конкретно этого вопроса: получается, что символы и футпринты будут браться из инета, а база компонентов, хранящая на них ссылки, будет у каждого своя локально? Я то думал, база со ссылками будет тоже в инете. Но я в этом механизме ничего не понимаю пока.

 

Будет. У семи нянек-- дитя без догляду

Нянька будет только одна - библиотекарь. Править может только он. А остальные - только добавлять свои собственные компоненты.

[Uladzimir 68]

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

Касаемо конкретно этого вопроса: получается, что символы и футпринты будут браться из инета, а база компонентов, хранящая на них ссылки, будет у каждого своя локально? Я то думал, база со ссылками будет тоже в инете. Но я в этом механизме ничего не понимаю пока.

 

Нянька будет только одна - библиотекарь. Править может только он. А остальные - только добавлять свои собственные компоненты.

 

1. Все в инете там много, и возможно все вам не нужно. У себя локальная версия (люба полная копия, либо только то, что Вам нужно). Всегда работа только с локальной версией. Извините интернет может пропасть, что и работу побоку?

Локальную версию периодически сами синхронизуете с основной. Таких программ хоть пруд пруди.

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

Периодически раз в месяц и ли за новым компонентов лезете и синхронизируетесь

2Нянька будет только одна - библиотекарь. ну может чуть больше, скажем по группам элементов :)

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

[Krys 2]

Владимир, по п. 1 - стало в целом понятно, как это будет устроено. Меня это устраивает (как представителя группы "упёртых" :)) ).

Единственный вопрос:

У себя локальная версия (люба полная копия, либо только то, что Вам нужно). Всегда работа только с локальной версией.

А чем это отличается от "просто надёргать себе компонентов"? Также вроде - надёргал и работаю локально :))

 

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

Вот это меня и смущает: когда я добавил себе компонент из временного хранилища, то у меня ссылка имеется локально только на временное хранилище, но не на постоянное. Соответственно, через полгода я захочу проапдейтиться (через ту же программу синхронизации), а она лезет по ссылке на временное хранилище. Там компонент либо уже удалён, либо так и лежит, но неисправленный. И получается, что чтобы у меня появилась ссылка на основное хранилище, я должен спустя дни убедиться, что библиотекарь перенёс мой новый компонент в постоянное хранилище, и исправить ссылки у себя локально. А это я могу забыть сделать. Или попутать чего-нибудь по запарке, сделать не для всех нужных мне компонентов. И т.д.

Или я тут тоже чего-то не до конца понимаю?

 

ЗЫ: Имеется опыт работы (в размере Comit - Update) с репозиторием TortoiseSVN, тут вроде объяснять не надо.

[Uladzimir 68]

Владимир, по п. 1 - стало в целом понятно, как это будет устроено. Меня это устраивает (как представителя группы "упёртых" :)) ).

Я сам такой :)

А чем это отличается от "просто надёргать себе компонентов"? Также вроде - надёргал и работаю локально :))

Ничем. Просто синхронизацией облегчаешь операции по "дерганье" компонентов

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

Не так. Откуда бы вы не сдернули-- вы положили к себе. Если ложите к себе сразу в основную (или единственную) -- накаких проблем. все сразу увидите.

Если есть боязнь левизны, и даже к себе сразу копируете во дополнительную--- Прописываете оба пути к основной и дополнительной. Только основную делаете первой.

Увидит все. Если имена совпадают-- возьмет из основной.

 

Заметьте-- у вас ссылки на директорию дерева в ВАШЕМ локальном компе. и обзывайте этот путь как хочется.

Я не прописывают поиск хранилишь в интернете. Во первых долго и не надежно.

Во вторых с НАШИМ интерентом-- это дорого

 

 

[jkrieger 0]

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

 

1. Так как SVN клиент (TortoiseSVN) не может делать сравнение и слияние БД, то это придется делать вручную при помощи запросов или стороннего ПО.

2. Пользователи скорее всего сами не захотят безоглядно добавлять все обновления в свою рабочую БД.

 

Потому Altium Common Library будет не рабочей базой, а просто как сборник компонентов, из которой пользователи будут импортировать записи к себе в рабочую базу.

 

В идеале я вижу седующую картину. Есть общая БД, которая регулярно обновляется с SVN, есть локальная временная БД, в которую пользователи добавляют свои компоненты. И есть база с запросом, который объединяет компоненты из общей и из временной базы, отдавая приоритет при этом общей. И уже эту БД подключаем к Альтиуму.

 

Таким образом пользователи работают с компонентами из общей базы. Как только какого-то нехватает, компонент добавляется во временную базу и в Альтиуме появляется новый компонент. Эта временная база отправляется Библиотекарям (любыми путями). После проверки и добавления компонента в общую базу, пользователи обновляют локальную копию общей БД. И запрос, подключенный к Альтиуму уже берет данные из общей БД. Дублирующиеся компоненты из временной базы можно удалить.

 

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

 

Для облегчения всех операций нужно насоздавать форм и запросов. Но вот тут у меня и получилась загвоздка. Моих знаний явно нехватает. Если есть желающие помочь, то свяжитесь со мной, пожалуйста =)

[Uladzimir 68]

1. я давно это понял

2. 100% именно так

Потому Altium Common Library будет не рабочей базой, а просто как сборник компонентов, из которой пользователи будут импортировать записи к себе в рабочую базу.

Скажем так, могут, если захотят

Есть общая БД, которая регулярно обновляется с SVN

так и работает с Altium Common Library

есть локальная временная БД, в которую пользователи добавляют свои компоненты.

И именно с ней они работают

И есть база с запросом, который объединяет компоненты из общей и из временной базы, отдавая приоритет при этом общей. И уже эту БД подключаем к Альтиуму.

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

Можно на своем компе держать свою локальную директорию со своей базой и компонентами. И копию Altium Common Library. При этом приоритет при взятии компонетов должен быть за локальной библиотекой.

Но все это каждый пользователь делает сам, и не касается Altium Common Library ( той которая в инете)

Да дубли каждый у себя почистит.

 

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

 

.

 

 

[uriy 5]

1. Так как SVN клиент (TortoiseSVN) не может делать сравнение и слияние БД, то это придется делать вручную при помощи запросов или стороннего ПО.

Может быть существует система контроля версий которая может работать с БД?

[jkrieger 0]

Может быть существует система контроля версий которая может работать с БД?

Есть - VSS от MS или ее преемник, названия не помню. Но тогда нужен свой сервер, чтоб поставить пиратскую версию этой дорогущей системы. Мне неохота =)

 

Есть и другой вариант. Устроить репликацию БД. Благо инструменты для этого уже есть у каждого из нас - Портфель. Тогда работа будет выглядеть таким образом.

Есть копия общей БД (ACL), есть рабочая копия, с которой работает Altium. Компоненты добавляются в рабочую БД, производится Update с SVN (чтобы избежать конфликтов из-за одновременного добавления компонентов разными пользовыателями), изменения Портфелем реплицируются в ACL и уже потом производится Commit на SVN.

 

Можно конечно попробовать и так. Так даже легче реализовать. Но при репликации вы по идее не увидите что изменилось и это может отпугнуть ползователей. Вобщем, пока что Владимир меня переубедил =)

[Uladzimir 68]

Вобщем, пока что Владимир меня переубедил =)

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

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

 

Теперь нужно согласовать назначение слоев, толщины, фонты, ...

[Krys 2]

(чтобы избежать конфликтов из-за одновременного добавления компонентов разными пользовыателями)

Я думаю, об этом не стОит беспокоиться. Договорились же, что редактировать компоненты будет библиотекарь. А добавлять будут все. Но вероятность того, что одновременно люди добавят один и тот же компонент - крайне низка.

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