Hi, This is a bit different than what is usually done, because currently repository permissions are based on Unix groups. These seperate branches would get permissions of a finer grain. Maybe they could be implemented using setfacl.
So this requires a bit of web interface to define the new repositories and the permissions, and a bit of backend job to create the repositories on the filesystem (in /srv/git/$project/$subrepo.git). Currently our backup system doesn't support ACLs, but if these ACLs can be recreated from the subrepositories definition that wouldn't be a problem. If you're interested in this feature, the more efficient is to submit a patch :) http://git.savannah.gnu.org/gitweb/?p=savane-cleanup.git Cheers, -- Sylvain On Tue, May 27, 2008 at 08:41:01PM +0200, John Mandereau wrote: > On 2008/05/27, Trevor Daniels wrote: > > Graham Percival wrote Tuesday, May 27, 2008 4:42 AM > > > Hmm. I guess I don't quite understand what you mean by a fork vs. > > > a branch. > > > > A fork is a clone of a repository which then runs > > independently, right? Unlike a branch a developer > > can be granted access to it without gaining access > > to the main repository. > > Yes, this is the idea as far as I understand. However, I wonder how to > update the forked repository: the most sensible way I can think of is > that somebody who has a forked repo pulls from the upstream repo and > pushes to his forked repo. If this works like this, it could work as > well as branches like lilypond/translation[*], which are regularly > merged from and into master, but a fork has the big advantage that we > don't have to give the important responsability implied by push access. > So, in brief, it would be very cool to have this on Savannah! > > [*] lilypond/translation is just an example that fits well, but this > doesn't mean we're going to change the current way of handling > translations with Till and Francisco: they use push access only for > lilypond/translation, which has worked well so far. > > > > > Since I don't really understand what you mean by "forks", I don't > > > know how this would improve things... unless you're suggesting > > > that we split the documentation away from the source code, and put > > > it in an entirely separate doc tree. > > Err, splitting the two trees would be a nightmare in terms of makefiles. > > > > It wouldn't be split; it would exist in parallel. So > > edits to the docs would be pushed there, the nightly doc > > compiles would be made there, and every so often someone > > with access to both repos would either cherry-pick all > > the commits into the main repo, or simply copy the latest > > tested and accepted versions of the .itelys and push them > > en bloc to the main repo. > > Yes, cherry-picking commits, or even merging the branch from the forked > repo if all commits are approved and there are two many commits, is the > way of doing things, if I understand it right. > > > > > Forking wouldn't change anything in the main > > repo- so little work would be needed. The > > doc fork could be updated from the main one > > nightly, so it would remain up to date. > > I'm not sure this can be automated: doc changes and core code changes > are not always independent, and conflicts that sometimes arise would > prevent an automatic merge from working. > > > > >> Also, you mention that you spend a lot of time on people that do not > > >> have push access. The interesting question is: where is that time > > >> going? If we can make all those contributors spend a few minutes more > > >> each day on preparing and verifying their changes, a lot of time can > > >> be saved. > > > > Someone would need to be identified to manage this. > > They would need to be able to compile the docs and > > fix any errors which breaks the build - much like > > Graham does now. Finding someone is the hard bit! > > I already do this for translations, I don't mind doing the same thing > with docs contributors. Another solution is using management tools like > http://transifex.org (but this would need to be adapted to our needs for > documentation editing), but that's certainly a lot of work to set up.
