On 10/4/05, Nicolas Pouillard <nicolas.pouillard(a)gmail.com> wrote:
On 10/4/05, Nicolas Desprès
<nicolas.despres(a)gmail.com> wrote:
On 10/3/05, Nicolas Pouillard
<nicolas.pouillard(a)gmail.com> wrote:
Hi, you can now update your vcs (as root):
gem update --system
gem install vcs -y --no-rdoc
New in 0.4:
Pourquoir est-ce que je ne suis plus en mode ChangeLog dans mon emacs
quand je dois remplir le dit ChangeLog ?
Puisque ce n'est plus directement un ChangeLog mais une version simplifier,
en effet le ChangeLog est genere a partir de cette entree. (astuce tu
peux confer ton
emacs de maniere a avoir une autre coloration soit celle du diff, soit du yaml)
C'est donc du travail supplémentaire qui m'incombe alors que j'ai
téléchargé la dernière version pour avoir moins de bugs et me rendre
la vie plus simple... Mais passons, c'est pas comme si la limite des
80 colonnes correspondait désormais à avant la frontière de mon emacs.
Pourquoi
suis-je obligé de me faire un .vcs pour pouvoir commiter
alors que j'ai juste trois pauvre fichiers de log généré par mon
programme à chaque exécution qui m'en empeche ? Depuis quand est-il
dangereux d'avoir des fichiers non versionné dans sa working copy ?
Les autotools en génère pourtant à la pelle !
Cf discussion avec akim les fichiers non versionné sont la cause de la plus part
des patches foireux. Donc si ya des fichiers generes tu les excludes
ou les unmask
et pour ta TODO tu la met en precieux
En effet, ils en sont souvent la cause, mais ils y a également d'autre
méthodes. Par exemple émettre un warning la première fois. Et puis la
deuxième fois ca passe si le mec insiste. Avoir une option qui force.
Le coup de precious ca va finir chez beaucoup de gens en:
precious:
- !re: .*
* Status & User Configuration File:
All .vcs files between your current path and root will be honored.
Example of configuration file.
>>> ~/.vcs <<<<
---
exclude: # Excluded Files:
- !re ,messages # not displayed (default ^-.*$)
unmask: # Unmasked Files:
- !re \bdoc # displayed with a `\' (default ^\\.*$)
precious: # Precious Files:
- !re .*\.(diff|patch)$ # displayed with a `+' (default ^\+.*$)
# .vcs files are also treat as precious
junk: # Junk Files:
- !re ... # displayed with a `,' (default ^,.*$)
>>> ~/.vcsrc <<<<
C'est bien d'avoir un fichier de conf mais il ne devrait pas être
obligatoire d'avoir à en écrire un pour pouvoir commiter et là c'est
obligatoire dés qu'on a un pauvre fichier myTODO ou des fichiers de
logs ou des Makefile.in, etc...
Il n'est pas obligatoire si tu regarde bien.
tu peux aussi renomer tes fichiers
mv myTODO +myTODO
et voila il est precieux et plus ?
Moi je ne comprend pas pourquoi ce genre de comportements marginaux
sont activé par défaut (c'est comme l'option gnupg en son temps). Moi
j'aimais bien vcs car je pouvais rajouter des sous commande à svn.
Maintenant les commandes par défaut sont surchargé et je ne reconnais
plus mon svn. De plus maintenant je dois faire confiance à svn *et* à
vcs par rapport aux résultats recueillit. Si un bug arrive dans l'un
ou dans l'autre, je ne peux plus commiter et donc plus travailler.
Sinon, je dois désinstaller vcs et du coup c'est encore moi qui bosse
au profit d'une nouvelle version qui devait me rendre la vie plus
simple, plus belle, etc...
* Color:
- Status: the status output is now colored depending of the meaning of
the status. The color activation can be choose in your configuration
file (auto, never, always).
- Logger: messages displayed by the Vcs logger are new colored.
cyan (info), yellow (warnings), red (errors), blinking red (fatal).
C'est mignon.
D'ou le surnom donné a cette release Gui......
Enfin des fois ca part en couille (surtout après une exécution foreuse
de uttk en mode cache):
zugarramundi:..uby/ttk/trunk:127>svn st
, ,messages
+ vendor
? svn
+ .vcs
+ myTODO
+ +commited
M test/examples/cache/simple.yml
M lib/uttk/status.rb
+
bin/driver.rb
+ bin/getopts/options.rb
M bin/uttk
Il faut que je fasse un reset pour rétablir le tout...
Je pense que ce ne doit pas être une options par défaut. grep ou ls ne
font pas la couleur par défaut que je sache.
En conclusion: je dit oui à la kyrielle de fonctionnalités mais si
elles ne sont pas mise par défaut. Comme ça, si je veux les utilisé je
les actives moi même une à une en conséquence de cause et je reconnais
mon vcs d'une version sur l'autre. En plus, ça force la documentation
puisque si elle ne sont pas documenté, je ne les découvrirai pas
(puisqu'elles ne sont pas par défaut).
Néanmoins, cette release est pleine de bonnes idées et montre la
puissance de l'outil.
a+
--
Nicolas Desprès