Tom Lord said: > > You might want to think about adjusting your backup policies: if > developers are going to do a lot of day-to-day work in private > archives, perhaps you want to make sure those are backed up and > quickly recoverable. >
I totally agree. Since we're not geographically distributed, I expect that all the developer's archives will live on a centralized, backed-up server, and their project trees will be on their individual development servers. > > Should each developer have only one repository and keep all their > projects > > in there? > > It depends on your staff. Some hackers would hate that restriction and > it would inhibit them. Other hackers would just adopt it as a > convenient structure within which to work (and it would simply things > such as backups). My thought process has been that the process we start with should do all it can to preclude a developer from shooting themselves in the foot, and provide enough isolation that if they do blow their foot off, there won't be any "richochets" that cut down innocent bystanders. Thus the idea that each developer would have a totally separate archive for each project they are involved in. [snip] > Some CVS users never had > to [...] think very much about what CVS is doing so they > have a pretty vague idea --- the arch command set is different enough > that I think it can take such users by surprise unless you put it in > the context of learning what a revision control system really does. > Many CVS users, on the other hand, seem able to pick up arch quickly > just from the scattered docs and the wiki. (Hopefully I'll put out some > new documentation soon, too.) > Around here, it seems the more experienced somebody here is with cvs, the more ready they are for arch. I think I get more pushback from people who haven't had to deal with large projects and multiple branches in cvs. 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. Tim _______________________________________________ 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/
