Hi, On Tue, 23 Oct 2007, Luca Capello wrote: > soon after darcs.d.o became a reality [1], Zack asked me about > including the support for it in debcheckout and I did it as bug > #445714 [2], arising some discrepancies in how the personal > repositories are managed: > > - git.d.o uses $HOME/public_git, which is then visible at [3]
... visible as git://git.debian.org/~gismo/test.git > - darcs.d.o uses $HOME/public_darcs, but this is visible as [4] This started with git because git-server has this nice integrated feature. For darcs, I think you made specific changes to make it work. I hope they will be integrated upstream because I don't like to rely on non-mainstream change. > - {arch,bzr,svn}.d.o uses /$VCS/private, visible as {[5],[6],[7]} They are not the same. Those are backupped, whereas the previous ones are not. > Now some points, which are not really problems, but annoyances: > > 1) all the VCS servers but darcs store the repositories as > > VCS.d.o/VCS/... > > Is the subfolder VCS really needed? In that case we should have it > for darcs.d.o, too. It's not always technically needed. I agree that we should require it for darcs too for consistency. But since I didn't setup it, I haven't said anything... :) > 2) I think we should be consistent also about how to store personal > repositories, at least for web access. AFAIK the general structure > for project repositories is > > VCS.d.o/VCS/$GROUP/$REPO > > I'd suggest to choose one of "private" (already used by 3 VCSs) or > "users" (2) as $GROUP for personal repositories, being the latter > my preference. > > Moreover, I'd prefer also to have personal repositories as > public_$VCS folders, which as I already wrote is how git and darcs > manage them ATM. You mix up stuff. First of all, only distributed VCS have the $GROUP/$REPO thingie. Then "private" and "users" are different beasts concerning backup. > 3) the second point is more important WRT debcheckout authentication > mode: this because in order to fix bug #447791 [8] the check should > be as more general as possible. Anyone familiar with distributed repositories knows that he can't assume to have write access on them... :-) I don't really see your point. debcheckout can checkout a user repository and I don't see why it should only succeed if you can write to it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]