On 2006-10-12, Akim Demaille <akim(a)lrde.epita.fr> wrote:
>>
"Tsuna" == Tsuna <tsuna(a)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.