Enhancement #264
open
Improve RCS organisation
0%
Description
Here are the IRC logs:
Duck : en fait j'aurais bien renommé rcs en vcs, et mis andesi/dc/hf dans un sous rep, mais bon ça pèterait toutes les URL, donc c'est relou
Duck : ben que les gens qui ont un clone vont plus pouvoir puller sans changer l'URL
arnau: ça prend environ 2s de changer l'URL
Duck : donc pour le moment y'a projects, poru les git pas liés à une asso
Duck : y'a people pour les users
Duck : et je mettrais bien un truc genre "entity" pour les asso et trucs assimilés, comme dans le LDAP
Duck : ouai mais ça va péter les couilles aux gens, donc j'attends un peu
arnau: plus on attend, pire ce sera ;)
Duck : néanmoins doit y avoir moyen de créer "entity" et mettre des symlinks pour les trucs génants, s'il y en a
Duck : et de faire des redirs web pour s/rcs/vcs/
Duck : idem pour le fs sur Toushirou s#/rcs#/vcs#
Duck : le premier point est juste, j'ai trop attendu :-)
arnau: car il y a 3 ou 4 projets avec de l'activité récente, donc changer tout n'est pas un problème IMO
Duck : y'a surtout bip, mais hormi pilou qui utilise surement le SSH, les autres seront pas trop affectés
Duck : faudra mettre à jour le redmine et les liens sur le site de bip
Duck : genre opur le viewer
arnau: les gens qui ont un problème lors du pull, vont aller sur http://rcs-git-viewer.duckcorp.org/ et être redirigé vers http://vcs.duckcorp.org/git/ et updater l'URL en conséquence
arnau: moi je vois bien un : vcs.duckcorp.org/<RCS> (un peu comme a fait Debian)
Duck : s'pas con
arnau: bon eux ils ont mis anonscm.debian.org
Duck : et <>-viewer ou du genre pour les truc genre gitweb
arnau: mais on a pas assez de projets pour avoir besoin de ça :p
Duck : ha bon ?
arnau: bah le anonscm est utile car c'est seulement pour le RO alors que le RW est sur un autre serveur
arnau: nous on a pas besoin de séparer RO de RW
Duck : ben on a déjà le ro en fait, via le protocole git
Duck : et en http aussi
arnau: ça utilise ça : http://progit.org/2010/03/04/smart-http.html pour le HTTP ?
Duck : c'est strange, git-http-backend ça me dit qqc
Duck : je susi sûr de l'avoir installé chez PF ou autre
Duck : mais nous on a du simple HTTP
Duck : la manpage montre des trucs que j'avais dékà vu et donc le gars ne parle pas
Duck : on peut aussi auth les gens et permettre un push
Duck : comme on ne pas pas mettre des valeurs de loginShell per-host dans le LDAP, on ne peut pas authoriser un shell sur Thorfinn et juste un git-shell sur TOushirou, par ex
Duck : du coup ça pourrait être pratique
Duck : ça doit expliquer le besoin d'un anon pour Debian
Duck : donc faudra y réfléchir
[...]
arnau: bon pour vcs*.duckcorp.org, il me semble (à confirmer d'après les logs) que ça aurait été mieux comme sur debian, genre :
arnau: vcs.duckcorp.org/git/
arnau: vcs.duckcorp.org/bzr
arnau: vcs.duckcorp.org/svn
arnau: ...
arnau: c'est ce qu'on avait dit non ?
arnau: (au lieu d'avoir vcs-git.duckcorp.org, vcs-svn.duckcorp.org et cie)
arnau: (euh pardon : s/vcs/rcs/g)
arnau: debian : http://anonscm.debian.org/
arnau: par contre, sur debian, ils font : anonscm.debian.org/git et anonscm.debian.org/gitweb
arnau: c'est un peu laid non ?
Duck : ha ?
Duck : pourquoi c'est mieux /<vcs-type> ?
Duck : c'est vrai que ça fait 42000 vhosts
Duck : oui c'est laid
Duck : p'tet que /<vcs-type>-anon serait mieux non ?
Duck : en fait j'aurais bien renommé rcs en vcs, et mis andesi/dc/hf dans un sous rep, mais bon ça pèterait toutes les URL, donc c'est relou
Duck : ça c'est pour l'arbo dans /rcs/git
Duck : j'avais dis ok pour les vcs.duckcorp.org/<vcs-type>
Duck : et <>-viewer ou du genre pour les truc genre gitweb
Duck : donc on pourrait normaliser une façon d'écrire, genre -anon et -viewer ou quelque chose du genre
Duck : et tu avais parlé de http://progit.org/2010/03/04/smart-http.html
Duck : bon je ne vois pas d'autres trucs
arnau: pour les URLs, 1/ ce n'est pas trop grave 2/ on peut faire des RewriteRule non ?
arnau: (par pas trop grave, je veux dire qu'il y a pas tant de users que ça actuellement donc c'est certainement préférable de le faire maintenant)
arnau: oui pourquoi pas renommé rcs en vcs
Duck : et <>-viewer ou du genre pour les truc genre gitweb => c'est vrai que ce serait super cool comme ça mais si on a plusieurs viewers ?
arnau: http://progit.org/2010/03/04/smart-http.html => c'est pour que ce soit plus rapide mais c'est seulement si on utilise pas le protocole git (e.g. derrière un proxy) mais bon...
arnau: (ou si on utilise pas le protocole SSH)
arnau: et on pourrait pas avoir : http://vcs.duckcorp.org/git/viewer et https://vcs.duckcorp.org/git (sans viewer) ?
arnau: ça serait encore plus simple non ?
Duck : rhaaaaaaaa, plusieurs viewers, comment va-t-on faire ???
Duck : il faut donc encore réfléchir
Duck : pas évident que ça ne pose pas de soucix que ça soit "en dessous"
arnau: sinon :
arnau: http://vcs.duckcorp.org/git/viewer (par défaut) et http://vcs.duckcorp.org/git/FOO-viewer (autres)
arnau: disons qu'avec ce schéma, on pourrat pas avoir de repository qui s'appellent viewer ou FOO-viewer mais vu notre organisation actuellement, ça ne sera pas le soucis je pense non ?
Updated by Marc Dequènes almost 13 years ago
- Status changed from New to In Progress
- Assignee set to Arnaud Fontaine
- Help Needed set to No
A bit a reflection, first pass…
VCS types: (git|svn|…)
FS path: /srv/vcs/<type>/(entities|people|projects)
Entities subpath: ./<entity>/<project>
People subpath: ./<uid>/<project>
Project subpath: ./<project>
Maybe projects should have another name. Every repository is some kind of project, so it looks more like unaffiliated projects (sounds a bit long).
URL: https://vcs.duckcorp.org/<type>((with HTTP redirecting to HTTPS, no more unsecured URL)
with:
- /<type> being for the native protocol
- /<type>-anon for anonymous access (could be mere HTTP)
- /<type>-viewer-<tag> for viewers if there are many
- /<type>-viewer redirection to the default viewer
We should rework the main presentation page on URL path /.
We should have a look to tools like git-http-backend.
We should also select a list of supported VCS and advertise it more clearly (in the main page and users' wiki). Currently only git seems to be really useful, but we could keep SVN and perhaps another. I suggest we keep a wider list of supported client tools available for shell accesses and document it too (like bzr, baz, hg…).
Let's review this a bit before acting. We can have a look to tools to avoid suprises.
Updated by Arnaud Fontaine almost 13 years ago
Concerning HTTPS, for VCS viewers and anon access, I think we should have HTTP as well. As it's read only, I don't see the point of using HTTPS for viewer or anon access.
For projects, I think it's fine because, in contrary to people repositories, several people work on a project. Another solution would be to have something similar to Freedesktop, e.g. with ~ for personal repositories.
Updated by Marc Dequènes almost 13 years ago
I totally disagree. I you are to download the code, then you're probably interested in building it. If you use an unsecure transport method, then you're unable to assert the code really comes from us and has not been tampered with. In fact i don't see any good in supporting HTTP when it is related to something which could harm your system. We may still keep it for a time, but i though it was a good occasion to remove it.
So, an alternate proposal could be:- FS path: /srv/vcs/<type>
- Entities subpath: ./<entity>/<project>
- People subpath: ./~<uid>/<project>
- Project subpath: ./<project>
I'm not opposed to it, as the namespace is clean and it results in shorter URLs. In fact we also could have <project>/(<subproject-1>|<subproject-2>|…) with entities and users' spaces just being a special cace of metaproject. To ensure unicity there is nothing to do for simple projects and entities, but we must ban "<uid>" without "~" as project name. I like the UNIX-ish "~" which make things clearer.
How do they get categories in their listing ?
Updated by Arnaud Fontaine almost 13 years ago
I meant that https is not needed for only viewing a git repository. Sure, we should have https when it comes to cloning a git repository.
The alternate proposal you submitted looks great. As of categories on Freedesktop, they seem to be using cgit which seems to implement such feature (you can have a look at the example of a cgit configuration file for further information). However, cgit does not see to be available in Debian (#515793).
Updated by Pierre-Louis Bonicoli over 9 years ago
cgit will be available on jessie.