On Thu, 7 Nov 2002 [EMAIL PROTECTED] wrote: > Couldn't you use something like CVSup and automatically trigger its > execution after every check in? > Is there more to a multisite repository than meets the eye?
There is more. What happens in distributed development is that people work on their own local stream; the other sites get some kind of patches that they have to integrate. Support for changesets can help with this, but you can't get around the requirement that there will have to be merges. Moreover, since you want everyone to end up with the same code, there has to be sufficiently frequent backpropagation of the integrated material. A version control tool with good third party source tracking can be used to implement a half-decent distributed process. You can have one ``master'' repository where all of the inputs from all the development teams are integrated. The teams work with their own repositories. The master repository gets code snapshots, tracks them using individual third-party branches, and merges them into the main trunk. Every once in a while, the disconnected developers have to synchronize by getting a snapshot of the main trunk, which they can track on their own third-party branch. After such a synchronization, the master repository can start a new branch for each synchronized team. If you synchronize with ``release-1-3'' from the master repository, then your next piece of work will be a derivative of that baseline; the master repository acn start a new branch for capturing your input, shooting from release-1-3, rather than continuing with your old branch, which would then capture extraneous differences arising from the backpropagation. CVS has something called ``vendor branching'', but it can't handle these requirements. Using regular CVS branches in this way involves a whole lot of error-prone manual labor. <plug>Meta-CVS, on the other hand, has more advanced third-party tracking which can implement the above model using a few simple commands.</plug> The nice thing about this model is that the teams can implement whatever local process they want, using whatever tools they are comfortable with. All that the master repository keepers need from a team is a code snapshot. (Under Meta-CVS, that snapshot can, relative to the previous snapshot, contain adds, removes, renames, execute permission changes and reconfigurations of symbolic links; these changes are automatically figured out). The disadvantage of this process is that detailed commit history is lost, because the inputs to the master repository are just snapshots. This problem can be partially alleviated if people maintain a detailed ChangeLog type file. Version control tools that support changesets take care of propagating such change details. But on the downside, they require everyone to use them; the individual teams have to produce a changeset that the master repository understands. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
