On Wednesday, June 29, 2011 4:07:23 AM UTC-4, VladimirB wrote: > > After using gitorious on several weeks , we see number of the > limitations: > > 1.No private repositories, meaning no read access control. >
I agree this is something I would love to have, but I don't have the ruby chops to implement it. There have been some attempts at adding this, but it ends up being non-trival and the patches were only partial functionality and only apply cleanly against pretty old versions of Gitorious. > 2.No merge request on same repository different branch. Only merge > requests from cloned repositories within gitorious. > you can do this with the standard git tools on the client side, other than having a record of who did what in the web gui, I don't see this as a Gitorious problem. > 3.Download time is not so good, we must use mirror and update mirror > manually after push. > •Once a developer pushed a change it does not reflected > in the mirror right away. > •The developer must update the mirror manually in order > for other to see his change. > I asked about this when I first started using Gitorious here for my team, the answer I was given was to set up the mainline repository as a read only remote origin and manually pull from it, the reasoning was you have more control and ALL the git local client tools to deal with conflicts during a merge, a server side solution would require manual hand intervention on conflicts anyway. After 8 months of my team using Gitorious this hasn't been missed at all. We just do a "git mainline master pull" when we want to see others changes. I don't disagree with the reasoning now, it would just make more code to maintain in Gitorious that didn't have great value. I would rather see more robust administrative GUI solutions for managing users, projects and repos than this. > Is gitorious able to support these the limitations (via command line > or other way)? > -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected]
