On Feb 6, 2011, at 2:47 PM, Alexander Hansen wrote: > On 2/6/11 2:41 PM, Daniel Johnson wrote: >> > >>> Would we have the ability easily to regulate commits access on a >>> more >>> fine-grained level than we're using right now? E.g. to give most >>> established maintainers the ability to commit and modify their >>> own .info >>> files but not to modify those of other maintainers? That'd be a >>> useful >>> additional feature in my opinion, because we could consider >>> broadening >>> our pool of committers and thereby reduce the backlog on the >>> tracker. >>
We should be able to accomplish this with hook scripts, but it might also be less burden on the maintainers to simply merge in changes from other users' Git/hg trees. > It sounds like we might want ultimately to consider using > Sourceforge's > svn repo for direct checkouts by our users, rsync mirror sites, and > the > website (at least for now), and use hg or git as the primary developer > interface, with e.g. a script to transfer the hg|git repo into svn. > (sort of like the present developer vs. anonymous cvs setup). The git-svn script works both ways: you can import SVN commits into Git, and you can forward Git commits into SVN. (Or there's that Git- based CVS pserver thing I mentioned in a previous email.) ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
