John Arbash Meinel wrote: >> Hello GNU ARCH users! >> Advice me please better ARCH usage schema for next situation: >> 1. One development server with one-per-developer account; >> 2. One live (production) server with running services; >> 3. Source files in project - are PERL files and binary build are not needed; >> 4. Each developer must have possibility to: >> 4a. Edit project files; >> 4b. Commit own changes (from self-owned archive?) to main arch archive; >> 4c. Do some actions for update project files on live server >> to latest version of project from main arch archive on development server;
>I actually think that you *don't* want this (4c). If you get rid of this >requirement, it simplifies the rest of your work. >Make it so the maintainer is the only person with login access to the >live server. Ok. >> 5. Developers (but maintainer) must NOT have direct access to project files >> on live server, >> for maintainer be sure what all project's changes are logged in changelog; >Again, look at my above comment. 4c conflicts with 5. Hence I recommend >removing 4c. Unless I just misunderstand what you were arguing for. Yes, we just remove 4c or 5, thanks. >> 6. After (before?) all changes (commits) to main arch archive system >> must run some test >> associated with particular project. If test fails - rollback or cancel >> commit. >This can be done with arch precommit hooks. The difficulty here, is that >arch is a client only process. So you have to setup *every* developer >with the precommit hooks. It is a simple fact of the arch design. >There is an alternative, though. Using a patch-queue-manager (pqm). >http://web.verbum.org/arch-pqm/ >I believe there is another one in use by the baz folks, but they'll have >to mention that one. >Basically, you have an automated script (the pqm), which handles >committing to the main archive. Developers commit to a different archive >(possibly just their personal one), and then inform the pqm that there >is pending work to be merged into the mainline. (This can probably be >done in a post-commit hook if you want to make it easier on the >developers.) And if commit produce conflict(s) on merging to mainline archive, then 1) commit on developer archive are success; 2) commit on mainline (pqm's) archive are fail; 3) developer receive e-mail from pqm about fail in point 2.; 4) developer do `tla star-merge ...' for sync up with mainline project tree; and manually handle all conflicts; 5) developer do commit again. I am understood right? >This pqm is then instructed to do a test merge, verify that the merge >passes the tests, before committing to the main archive. At this time, >the pqm can also handle all of the emails that you want to send. Or if >it fails, the pqm can email the developer letting them know what went >wrong. E-mails will be sending by pqm to addresses from `tla my-id' of developers, true? >> 7. After each commit to main arch archive system must send e-mail to >> maintainer; >> 8. Only maintainer must have rights for making new >> category/branch/version in main arch archive; >Again, the pqm provides a barrier between the developers and the main >archive, so if only the pqm and the maintainer have access, and the pqm >doesn't have any rules for creating a new category/branch/version, then >there shouldn't be any problems. And if maintainer want to create new version, his just 1) tell to developers for they commit changes; 1) make new version (tla tag) in mainline archive; 2) notify all developers about that; Developers need to `tla get mainline-archive/project--devo--new-version' and next changes they must do in new version tree. True? >> 9. After maintainer make new version of particular project system must >> send e-mail to all project developers; >> (and developers go to update own local copies of changed project?); >Some of this can most easily be done by self-discipline of the >maintainer. It can also be done with a post-commit hook. I'm not sure if >there is a post-tag or post-branch hook, but you could work something >like that out. We think what new version's make - not often operation, and manual creating email for notify developers - right choice for us. >> 10. Updating project files on live server process must have two cases: >> 10a. Update files in "TEST" location, for manual testing on LIVE server. >> 10b. Update files in "HOT" (production) location on LIVE server. >Is this being done by the maintainer or by developers? Because in 5 you >stated that devs can't touch the live server. We think maintainer in own schema will differ from developers only in next points: 1) Only maintainer will have access to pqm user account (and to mainline archive); 2) Only maintainer will have responsibility about making new versions ;) >It really only amounts to having 2 locations "checked out". The >maintainer runs "tla update" in the test location, tests the system on >the live server, then can cd over to the production location and do >another "tla update". Thank! >Good luck. Hopefully people who are actively using a pqm will speak up. >As I think it really fits what you are wanting to do. If you don't want >to go through that work, we have also worked out some other alternatives. Pqm is fine for us! >The first key is do you trust your developers to not try and subvert the >system. If so, that simplifies a lot of things. >One of the problems with having tests run automatically, is that you are >allowing the developers to cause arbitrary code to be run on some other >machine. You probably can trust your developers, I just want to bring up >the fact that if you are running automatic tests, there is nothing to >stop the developers from submitting the "test" which runs an arbitrary >command. Yes, you right. We will trust own developers. >If you don't want the pqm, you can read about hook scripts here: >http://wiki.gnuarch.org/Using_20hooks >You can use JohannesBerg's method (near the end) which lets you run a >per-package hook script. By tying into the precommit hook, you can have >tests run, etc. >If you want to prevent creation of new cat/branch/version, you can make >all directories non-group writable (chmod go-w), except for the final >directory where the new revisions are created. You'll also want to check >out >http://wiki.gnuarch.org/Centralized_20Development >To see how to have multiple people committing to the same archive. Thanks for links. So pqm method is more likely for us: 1) No need to dance with umask and access rights; 2) Centralized pre-commit and post-commit hooks, which called _every_time_ mainline archive changed; -------------------------------------------------------------------------- Robert Collins wrote about arch-pqm: >Its the same one, just a more recent version - adding support for acls >on a per branch basis, baz, various bugfixes, a replay command. >Http://people.ubuntu.com/~robertc/[EMAIL PROTECTED]/arch-pqm-->main--0 Right link: http://people.ubuntu.com/~robertc/[EMAIL PROTECTED]/arch-pqm/arch-pqm--main/arch-pqm--main--0/ Big thanks. Robert, is this you fork from official arch-pqm project? 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/
