John Arbash Meinel wrote: > So, the problem with this scheme, is that you are saying "Everybody gets > Their own archive", but then you turn around and say, "But everyone has > to stay perfectly synchronized." > At that point, you really should do a centralized model, since everyone > is staying up-to-date all the time anyway. I know that as a developer, I > wouldn't really be happy having my sources update behind my back. > If we are all sharing the same repository, at least there is the > expectation that we should do an update before a commit.
We having centralizing model based on arch-pqm, which maintain main archives. So, users, as I said - have local self owned archives. We don't want to dance with access rights and make one centralized archive with r/w access from all developers, because: - we have a lot of projects (about 30) - we have a lot of developers (about 50) - we need a place, which always contain _stable_ releases (just having two branch for each project: devel and stable) - we need to distinguish access rights to stable branches, only this particular project maintainer(s) must can do merge from devel to stable branch. (using precommit hook from arch-pqm to check this) - we need for simple operations "edit maintainers list", "edit project list", etc. (store 'project -> maintainers' info in database, write small and simple web interface for edit info in this database) I can be mistaken, but think this not very easy if out of arch-pqm based model? > Maybe I'm wrong. I can see that there might be some advantage to always > being up-to-date with the mainline tree, even if you have local changes > for your branch. But I also know that if someone merges a change that > breaks my branch into mainline, (say they rename a function that I am > using). When I update, everything will be broken, even though the merge > was successful. And *then* I have to track down what changed, rather > than being aware of it at the time I merged it in. For handle this situation we just do testing devel branches before maintainer merge changes to stable. I am adding postcommit hook's to arch-pqm, which updates changed projects in its "test locations". > My personal feeling is that you should advise your developers to keep 2 > working trees. 1 that is the latest committed patch, and the other is > where they actually do development. > Then every morning, they "tla update" the latest dir (because they > committed from the other one). And then they run "tla star-merge > $mainline". They can review what changed, and see if they want to add it > in to their work, or if they need to wait. > And then they can "tla commit"/"tla undo". > If they undo, they should at least be thinking about how to work with > the latest changes to mainline. > Does this make sense? Yes, this sounds good, but major portion of our developers haven't any RCS using experience, and I have an small idea: - write commit wrapper, which do a) 'tla star-merge $mainline' b) stop if any conflicts appears c) 'tla commit ...' It seems to me that this wrapper be fine for arch (and others RCS in whole) beginners. Of course I am will describe these wrapper actions in corporative technical documentation, for don't mislead our developers. What do you think about this idea? Sorry for my bad English. Thanks for discussion! --- WBR, Alexander Popkov. _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
