On Thu, 2005-03-24 at 13:04 -0600, [EMAIL PROTECTED] wrote: > At the beginning, I expect to just give most developers a one-page cheat > sheet that tells them how to commit in their own archive and how to > star-merge from the project archive. Project leads will get trained on > how to star-merge from the developer's archives. Myself and another > person will handle pulling projects into a "next release" repository.
Also, the initial setup can be quite tedious and confusing depending on
the amount of infrastructure you need:
* registering archives
* policy on naming and location of new archives
* revision libraries on workstations (pretty much obligatory)
* remote and local archive mirrors (may or may not be needed,
depending on individual needs)
* signing rules (probably not needed if you are not distributed
geographically)
* pqm user tools and mail system setup (if you decide to use pqm)
You should probably get a clear ideas of what are your precise needs in
terms of initial setup and provide at least a "getting started" cheat
sheet, and at best a set of scripts, so your users won't start by
getting frustrated.
One important thing: emphasise that users should never "remove an
existing archive or branch and start from scratch". That's a very common
mistake made by new users and it leads to hell because it breaks the
model and causes cache coherence problems that can lead to corrupted
data.
--
-- ddaa
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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/
