so6 questions http://dev.libresource.org/home/community/forum/ccdd9a4fc0a8001e00f2673753173b0d RE : so6 questions http://dev.libresource.org/home/community/forum/ccdd9a4fc0a8001e00f2673753173b0d/d98217fac0a8001e018ab963d0101d30 Sebastien Jourdain 2006-01-11T12:22:58+01:00 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]]> RE : so6 questions http://dev.libresource.org/home/community/forum/ccdd9a4fc0a8001e00f2673753173b0d/d781484cc0a8001e01ccc08344aa7e99 Nicolas Souchu 2006-01-11T12:22:58+01:00 The purpose of synchronizers is more clear to me now. But I think I should practice a bit to tackle the last details. Basically, it is around the management of tickets, if it is possible to force the inclusion of tickets in a synchronizer history...

I hope to come with more practical questions after some trial of the beast :)

Thx.

Nicolas

Nicolas]]> RE : so6 questions http://dev.libresource.org/home/community/forum/ccdd9a4fc0a8001e00f2673753173b0d/d68d9637c0a8001e002e89634c90622c Sebastien Jourdain 2006-01-11T12:22:58+01:00 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]]> RE : so6 questions http://dev.libresource.org/home/community/forum/ccdd9a4fc0a8001e00f2673753173b0d/d474dec2c0a8001e009c051a156d3aa3 Nicolas Souchu 2006-01-11T12:22:58+01:00 If I understand correctly, a synchronizer is a view of a project. The elements (.c, .h, dirs, .o...) are stored in a database with some version for each and the synchronizer links them as coherent set.

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

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

So, concerning the management of the dataflow, are tickets independant from synchronizers ? Are they applied to synchronizers or must they be moved or copied from a synchronizer to another ? Is it this way to propagate changesets from a branch to another ?

Nicolas]]> RE : so6 questions http://dev.libresource.org/home/community/forum/ccdd9a4fc0a8001e00f2673753173b0d/cf0afc3cc0a8001e01b0d0f34726afe5 Sebastien Jourdain 2006-01-11T12:22:58+01:00 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]]> so6 questions http://dev.libresource.org/home/community/forum/ccdd9a4fc0a8001e00f2673753173b0d/ccdd9b06c0a8001e00ff8c2d001cf221 Nicolas Souchu 2006-01-11T12:22:58+01:00 I've been using Continuus tool and I'm trying to make some comparisons with so6. I don't want to start a flame about configuration management tools, I'm just wondering how to use so6.

1) Concerning local WS, the fact that a commit cannot be done unless the localWS is in sync means to me that personal WS is not managed under configuration management. 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.

Under continuus, 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.

2) How are implemented releases? With tags?

3) What about the management of objects under configuration?

4) How branches are managed?

Thx in advance for your replies.

Nicolas]]>