
On 2006-10-12, Akim Demaille <akim@lrde.epita.fr> wrote:
"Tsuna" == Tsuna <tsuna@warszawa.lrde.epita.fr> writes:
share-ci: cd $(share_dir) && vcs-svn ci $(MAKE) share-up
je pense que "make share-ci" ne devrait pas être nécessaire avec vcs : c'est lui qui devrait faire des checkins récursifs dans les externals.
alias svn=...
svn ci $share_dir
Et voila. Ou alors j'ai pas compris. Mais en tout cas ca fait la meme chose que ton make share-ci.
Non y un share-up après.
alias svn=... < c'était pour dire que comme tu passes par un script il te fait [généralement] le svn up derrière.
De plus tu m'obliges à connaître le nom de la dépendance.
Certes.
Effectivement, j'ai pas été clair :)
Je reprends.
J'ai un projet HOTE et un projet EXTERNAL, bien entendu dans des dépôts différents.
Mon projet HOTE a un svn:external sur la -r 42 de EXTERNAL. Je fais des modifications dans HOTE et la copie locale de EXTERNAL/. Je dis que quand je fais un checkin dans HOTE alors :
1. faire la procédure de checkin dans EXTERNAL 2. faire la mise à jour de la révision des svn:externals sur EXTERNAL à -r 44 3. faire le checkin du répertoire hôte.
OK, tu trouves pas ça un peu dangereux ou au pire gênant qu'un script commit un external pour toi, dans ton dos? Je sais pas, j'utilise pas souvent les externals (contrairement a toi) et je les modifie encore moins (contrairement a toi) donc jme rends pas bien compte mais... est-ce qu'on veut vraiment commit'er a chaque modif faite dans un external en meme temps qu'on commit le reste? De plus, si on prends par exemple share ou build-aux, ils ont des ChangeLog a eux, tu attends quoi de ton outil? Qu'il te fasse remplir deux ChangeLog entries?
Dans ce cas, plus la peine de faire de petits auxiliaire genre share-ci.
Si ce n'est pas implémenté, *au moins* il faudrait que ci (sans --force) refuse de faire des checkins avec des copies locales d'externals qui sont modifiées, pareil que pour les fichiers inconnus.
Pourquoi? Parce que tu commit du code dans HOTE qui dépend de code dans EXTERNAL qui n'est pas encore commité? Dans ce cas pourquoi ne pas faire cd EXTERNAL/ && svn ci (avec svn aliasé sur ce qui va bien) puis svn ci ? A la rigueur on pourrait imaginer que le script detect les modifications effectuees dans un external et te propose de les commit'er avant de finir le commit que tu viens de commencer. $ svn st M src/somefile M EXTERNAL/somefile $ svn ci svn-foobar: Do you want to commit your changes in EXTERNAL/ first? [y/N] y svn-foobar: using EXTERNAL/ChangeLog [...] Are you sure you want to commit? [y/N] y M EXTERNAL/somefile Sending ... Committed revision X in EXTERNAL/ svn-foobar: using ./ChangeLog [...] Are you sure you want to commit? [y/N] y M src/somefile Sending ... Committed revision Y in . ? -- SIGOURE Benoit aka Tsuna (SUSv3 compliant) _____ "On a long enough timeline, the survival rate /EPITA\ Promo 2008.CSI/ACU for everyone drops to zero" -- Jack.