repo.calcforge.org disponible pour Fedora 11 - Page 2

Après tests, je vois que Romain a eu raison de ne pas utiliser la gestion des symlinks par SVN, parce qu'elle ne fonctionnerait pas bien pour l'usage que je suggérais en ./15: elle ne fonctionnerait que pour les gens qui utilisent des working copies suffisamment larges.
Symlinker b/toto vers a/toto (les descendants de deux paths "frères", donc) ne donne pas un résultat convenable si on checkoute l'arbre b/ sans checkouter l'arbre a/, comme le montre le petit essai qui suit:

$ ls -Rl
.:
total 12
drwxr-xr-x 3 1000 100 4096 jun 15 15:46 branches
drwxr-xr-x 3 1000 100 4096 jun 15 15:19 tags
drwxr-xr-x 3 1000 100 4096 jun 15 15:44 trunk

./branches:
total 0
lrwxrwxrwx 1 1000 100 16 jun 15 15:38 toto2.c -> ../trunk/toto2.c [fait depuis branches, ne fonctionne que si ../trunk est checkouté en même temps que branches]
lrwxrwxrwx 1 1000 100 14 jun 15 15:46 toto3.c -> /trunk/toto3.c [pour tenter de référencer la racine de la working copy, et non pas la racine du FS sur lequel la working copy est sauvée...]
lrwxrwxrwx 1 1000 100 12 jun 15 15:19 toto.c -> trunk/toto.c [fait depuis la racine d'une working copy complète, ne fonctionne que si trunk est checkouté en même temps que branches]

./tags:
total 0

./trunk:
total 12
-rw-r--r-- 1 1000 100 11 jun 15 15:37 toto2.c
-rw-r--r-- 1 1000 100 11 jun 15 15:44 toto3.c
-rw-r--r-- 1 1000 100 10 jun 15 15:19 toto.c

Le symlink est apparemment interprété de manière littérale (verbatim).

Un autre problème est que les symlinks ne fonctionnent que sur les systèmes de fichiers et systèmes d'exploitation qui les gèrent.

On pourrait utiliser svn:external, mais c'est assez pourri aussi.

sur une plate forme qui les supporte pas, ça copie.

Un autre problème est que les symlinks ne fonctionnent que sur les systèmes de fichiers et systèmes d'exploitation qui les gèrent.

svn sait reconstituer (par copie) des symlinks sur les FS qui ne les gèrent pas

On pourrait utiliser svn:external, mais c'est assez pourri aussi.

Je pensais utiliser svn:external pour réduire la duplication de cleaner.c entre TILP et TIEmu. Mais bon, si ça se trouve, des tests vont me montrer que ça n'est pas utilisable pour ce qu'on veut en faire
J'ai déjà eu deux mauvaises surprises en peu de temps avec SVN (`svn rm` qui supprime l'historique, même si ça ne me touche pas parce que j'utilise Git; svn:special pour les symlinks dont l'implémentation ne va pas jusqu'au bout, ça doit être difficile à gérer pour certaines opérations...), peut-être y en aura-t-il une troisième...

Au fait: dans cleaner.c, le fichier temporaire n'est plus utile, car il est copié sans retraitement dans le fichier de sortie. Je compte le supprimer en même temps que je merge ton bugfix.

svn rm ne supprime pas l'historique, il faut juste savoir comment l'obtenir (il faut que tu donnes une révision à ViewVC et il te montrera les fichiers connus à cette révision). Et si tu veux réssusciter un fichier en conservant l'historique, il faut utiliser un svn cp pour copier l'ancienne révision supprimée, pas un svn add.

svn rm ne supprime pas l'historique, il faut juste savoir comment l'obtenir (il faut que tu donnes une révision à ViewVC et il te montrera les fichiers connus à cette révision).

Exact, mais ce n'est pas ce qui m'intéresse
Ce qui m'intéresse, c'est de pouvoir obtenir, en ligne de commande, le log d'un path donné, pendant un sous-ensemble (formé de révisions consécutives) de l'historique du projet. svn ne sait pas faire ça: j'ai effacé le repo de test et la working copy que j'avais créés pour tester, mais j'avais vu que:
<modifs dans le path toto>
$ svn ci
<modifs dans le path toto>
$ svn ci
$ svn log toto -> donne l'historique des modifs jusque là dans ce path
$ svn rm toto
$ svn ci
$ svn log toto -> ne veut pas le faire parce que le path n'existe pas.
$ svn mkdir toto
$ svn ci
$ svn log toto -> ne montre que la dernière révision, pas l'historique des modifs précédant svn rm.

Avec Git, je peux obtenir toutes les révisions qu'il y a eu au path toto, d'au moins trois manières (`git log` et `git whatchanged` en ligne de commande, commit -> touching paths: dans gitk).

Et si tu veux réssusciter un fichier en conservant l'historique, il faut utiliser un svn cp pour copier l'ancienne révision supprimée, pas un svn add.

En effet, de même que les branches et tags sont créés par `svn cp`.
(Git sait détecter les copies et renommages...)

Si tu donnes une révision à svn log, ça te donnera le log de ce qu'était le chemin à ce moment-là jusqu'à la révision en question. Mais évidemment, il faut savoir quelle est la bonne révision. (ViewVC te proposera au moins "Set to nnnnnn (This path does not exist anymore after revision nnnnnn+1.)")

35> tortoiseSVN peut , alors svn doit pouvoir aussi, si on lui donne les bonnes options

Soit
Le nombre de mes mauvaises surprises avec SVN descend à une mauvaise surprise et demi, alors
(avec Git, même par-dessus SVN, pas _besoin_ de mettre d'options spéciales).

chez moi non plus ^^

Fichier joint : (svnlog.PNG)

Hmm, est-ce que le fichier dont tu demandes à TortoiseSVN le log a été supprimé puis recréé, et est-ce que ce log te donne la partie antérieure de l'historique (avant la suppression) ?

squalyl ça va toi t'es pas trop fatigué?

Ah ouais, j'avais même pas remarqué

si, justement, ça fait 2 soirs que je me couche à des heures indues, c'est pas prévu pour continuer

(vous remarquerez que j'ai codé 80% de DES pour mon cpu 8 bits en 2h )