You're welcome…

In fact synchronizer tickets are the timestamp of the operations that a synchronizer contains. Those operations are globaly ordered so you can't insert operations between the existing ones.

Artenum Team

If I understand correctly, a synchronizer is a view of a project.

Yes and no, a project in my point of view is much more than just a single versioning tool.

The elements (.c, .h, dirs, .o...) are stored in a database with some version for each and the synchronizer links them as coherent set.

Yes, but only the changeset are stored.

Then I guess that when two synchronizers use the same element version it is actually the same object in the database. Right ?

No they are totaly independant.

In fact a synchronizer keep track of the history of a part of your filesystem in order to share it or not with others. You can create as much as synchronizer you want depending the composition of your project specialy if you want to split into sub-projects with different working area. Moreover, you can pipe synchronizer to each other in order to propagate an evolution to a dedicate one for integration or release or what ever, in fact it's up to you… And they are not linked inside the database they work as independant system which take care at what they are good for, Synchronization.

People working on the same synchronizer are sharing the same project view (working sequentially), but people working on different synchronizers are working in parallel...

No, on a same synchronizer you can work in parallel like any configuration management system. You get a copy of the project localy so you can make concurrent change on it.

So, concerning the management of the dataflow, are tickets independant from synchronizers ?

Yes they are, they represent the amount of operation contains in the synchronizer history.

Are they applied to synchronizers or must they be moved or copied from a synchronizer to another ?

I don't get what you want to do ?

Is it this way to propagate changesets from a branch to another ?

No, a changeset is a set of operation, and each synchronizer has its own referential.

I hope you get a better understanding of the system, but if it's still unclear, feel free to ask question...

Regards,

Artenum Team

1) Concerning local WS, the fact that a commit cannot be done unless the localWS is up-to-date means to me that personal WS is not managed under configuration management.

Configuration management system are usually based on the copy-modify-merge paradigm which implies to be uptodate before publishing your change...

This is feature may be laking I think. It's very useful to be able to reproduce areas of developers and permit them to commit what they actually validated under their personal WS.

Ok, then just give them a synchronizer for them...

Under continous, developers are responsible for testing their changes under their local area with the environment they got at the sync. Then once commited, the manager is in charge of merges. That way, integration of SW parts is a process is clearly separated from coding/testing of local changes.

Yes this is done by a hierarchical dataflow structure where only a manager integrates the work of its developpers.

2) How are implemented releases? With tags?

A synchronizer can be dedicated to release so each evolution in the history of that synchronizer will be a release. For the tags is just a flag in some point of the history.

3) What about the management of objects under configuration?

I don't get your question ?

4) How branches are managed?

By the dataflow

Regards

Artenum Team