so6 questions
http://dev.libresource.org/home/community/forum/ccdd9a4fc0a8001e00f2673753173b0d
RE : so6 questions
http://dev.libresource.org/home/community/forum/ccdd9a4fc0a8001e00f2673753173b0d/d98217fac0a8001e018ab963d0101d30
Sebastien Jourdain2006-01-11T12:22:58+01:00In 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 Souchu2006-01-11T12:22:58+01:00The 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.NicolasNicolas]]>RE : so6 questions
http://dev.libresource.org/home/community/forum/ccdd9a4fc0a8001e00f2673753173b0d/d68d9637c0a8001e002e89634c90622c
Sebastien Jourdain2006-01-11T12:22:58+01:00Yes 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 Souchu2006-01-11T12:22:58+01:00If 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 Jourdain2006-01-11T12:22:58+01:00up-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 dataflowRegardsArtenum Team]]>so6 questions
http://dev.libresource.org/home/community/forum/ccdd9a4fc0a8001e00f2673753173b0d/ccdd9b06c0a8001e00ff8c2d001cf221
Nicolas Souchu2006-01-11T12:22:58+01:00I'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]]>