Управление зависимостью от.NET и метки/Ветвление
Вы, возможно, видели мой ответ на другой вопрос C, где я упомянул FSM! Вот то, как я делаю это:
FSM {
STATE(x) {
...
NEXTSTATE(y);
}
STATE(y) {
...
if (x == 0)
NEXTSTATE(y);
else
NEXTSTATE(x);
}
}
Со следующими макросами определил
#define FSM
#define STATE(x) s_##x :
#define NEXTSTATE(x) goto s_##x
, Это может быть изменено для удовлетворения конкретному случаю. Например, у Вас может быть файл FSMFILE, что Вы хотите управлять своим FSM, таким образом, Вы могли включить действие чтения следующего символа в сам макрос:
#define FSM
#define STATE(x) s_##x : FSMCHR = fgetc(FSMFILE); sn_##x :
#define NEXTSTATE(x) goto s_##x
#define NEXTSTATE_NR(x) goto sn_##x
теперь у Вас есть два типа переходов: каждый переходит к состоянию, и считайте новый символ, другие движения к состоянию, не используя входа.
можно также автоматизировать обработку EOF с чем-то как:
#define STATE(x) s_##x : if ((FSMCHR = fgetc(FSMFILE) == EOF)\
goto sx_endfsm;\
sn_##x :
#define ENDFSM sx_endfsm:
хорошая вещь этого подхода состоит в том, что можно непосредственно перевести диаграмму состояний, Вы вовлекаете рабочий код и, с другой стороны, можно легко нарисовать диаграмму состояний из кода.
В других методах для реализации FSM структура переходов прокладывается под землей в управляющих структурах (в то время как, если, переключатель...), и управлял значением переменных (обычно state переменная), и это может быть сложная задача связать хорошую схему с замысловатым кодом.
я узнал, что эта техника от статьи появилась на замечательном журнале "Computer Language", который, к сожалению, больше не публикуется.
5 ответов
Думаю, все зависит от того, насколько стабильны разделяемые библиотеки. Я бы предпочел, чтобы общие библиотеки рассматривались как их собственный проект, созданный в CruiseControl, как и другие. Тогда четыре основных приложения будут иметь двоичные ссылки на разделяемые библиотеки.
Основным преимуществом этого подхода является стабильность приложений теперь, когда разделяемые библиотеки статичны. Изменение библиотек не повлияет на приложения, пока они явно не обновят двоичные файлы до более новой версии. Ветвление приносит с собой двоичные ссылки. У вас не будет ситуации, когда кажущееся безобидным изменение нарушит работу трех других приложений.
I've tried solving this problem several ways over the years, and I can honestly say there is no best solution.
My team is currently in a huge development phase and everyone basically needs to be working off of the latest and greatest of the shared libs at any given time. This being the case we have a folder on everyone's C: drive called SharedLibs\Latest that is automatically synced up with the latest development release of each of our shared libraries. Every project that should be drinking from the firehose has absolute file references to this folder. As people push out new versions of the shared libs, the individual projects end up picking them up transparently.
In addition to the latest folder, we have a SharedLibs\Releases folder which has a hierarchy of folders named for each version of each shared lib. As projects mature and get towards release candidate phase, the shared lib references are pointed to these stable folders.
The biggest downside to this is that this structure needs to be in place for any project to build. If someone wants to build an app 10 years from now, they will need this structure. It is important to note that these folders need to exist on the build/CI server as well.
Previous to doing this, each solution had a lib folder that was under source control containing the binaries. Each project owner was tasked with propagating new shared dlls. Since most people owned several projects, things often fell through the cracks for the projects that were still in the non-stable phase. Additionally TFS didn't seem to track changes to binary files that well. If TFS was better at tracking dlls we probably would have used a shared libs solution / project instead of the file system approach we are taking now.
Can you clarify why you don't like branching all four applications at the same time?
This makes it very hard to branch/tag a single application because you are branching all 4 at the same time
I usually put all my projects directly under trunk as you are currently doing. Then when I create a release branch or a feature branch, I just ignore the other projects that get carried along. Remember, the copies are cheap, so they're not taking up space on your server.
To be specific, here's how I would lay out the source tree you've described:
- trunk
- WPF1
- WPF2
- ASP.NET 1
- ASP.NET 2
- lib1
- lib2
- branches
- WPF1 v 1.0
- WPF1
- WPF2
- ASP.NET 1
- ASP.NET 2
- lib1
- lib2
- WPF1 v 1.1
- WPF1
- WPF2
- ASP.NET 1
- ASP.NET 2
- lib1
- lib2
- lib1 тарифный план
- WPF1
- WPF2
- ASP.NET 1
- ASP.NET 2
- lib1
- lib2
- WPF1 v 1.0
Я согласен с @Brian Frantz. Нет причин не рассматривать совместно используемые библиотеки как собственный проект, который создается ежедневно, а ваши проекты бинарно зависят от ежедневных сборок.
Но даже если вы хотите сохранить их как исходные зависимости и строить их вместе с приложением, Почему бы вам не подойти внешний вид SVN? Когда вы разветвляете конкретное приложение, нет необходимости также разветвлять общую библиотеку, если вам не нужна ее отдельная копия для этой ветки. Но это значит, что это больше не разделяемая библиотека, верно?
Мы запускаем проект с открытым исходным кодом, чтобы попытаться решить эту проблему. Если кому-то интересно прокомментировать его или внести свой вклад, он находится по адресу: