[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: VCSs on Alioth and personal repositories


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

> - {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

> 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
>    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.

Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :

Reply to: