On 2006-05-09, Nicolas Pouillard <nicolas.pouillard(a)gmail.com> wrote:
> On 5/10/06, Tsuna <tsuna(a)warszawa.lrde.epita.fr> wrote:
>> On 2006-05-08, Nicolas Pouillard <nicolas.pouillard(a)gmail.com> wrote:
>> > On 5/9/06, Tsuna <tsuna(a)warszawa.lrde.epita.fr> wrote:
>> >> Hi,
>> >> vcs doesn't seem to support svn's option -N
>> >
>> > Vcs supports it!
>> >
>
> [...]
>
>> I know this is a "feature" of VCS. But I'm telling it not to recurse in this
>> directory so ... what the hell?
>
> The hell is this rule that is here to prevent you against incomplete
> patches due to missing files.
>
>> It's a bit borring to add all the files generated by the autotools in the
>> ignore list...
>
> Boring, perhaps but there is already many things to help you.
>
> - svn supports globbing inside svn:keyword so you can add Makefile.in
> recursively to all directories.
> - moreover svn support auto keywording: in your configuration file you
> can say that by default you ignore Makefile.in
>
>> maybe VCS should help by knowing that this particular file is
>> generated by auto* and thus ignore it (maybe also display a notice to let the
>> user know this file was ignored for such reasons)
>
> - Vcs can also *already* do that:
>
> --8<----------------------------------------
> # ~/.vcs configuration extract
> exclude:
> - Makefile.in
> --8<----------------------------------------
>
> Best regards,
>
Cool thanks for the reply :)
Is it possible to exclude ``.*.sw?'' in ~/.vcs ?
--
SIGOURE Benoit aka Tsuna
_____
/EPITA\ Promo 2008.CSI Rock & tRoll
On 2006-05-08, Nicolas Pouillard <nicolas.pouillard(a)gmail.com> wrote:
> On 5/9/06, Tsuna <tsuna(a)warszawa.lrde.epita.fr> wrote:
>> Hi,
>> vcs doesn't seem to support svn's option -N
>
> Vcs supports it!
>
>>
>> for examples say I have:
>> ? src/sig/Makefile.in
>> A src/sig
>> A src/sig/Makefile.am
>>
>> ATM, I can't commit unless I rm src/sig/Makefile.in
>
> You are not supposed to remove the Makefile.in!
>
>>
>> $ vcs-svn ci -N src/sig src/sig/Makefile.am
>> vcs: info: Updating your working copy...
>> At revision 7.
>> ? src/tools/Makefile.in
>> ? src/sig/Makefile.in
>> vcs: error: You have unrecognized files in your working copy!This meant that these files wo
>> n't be committed!
>>
>
> You are experiencing a feature of Vcs :) that impose a rule to you:
> you can't commit with '?' files. In new_user mode a more complete
> explanation is provided. Perhaps you should comment the "new_user:
> false" line in your config file :). The good answer for Makefile.in is
> to add it to the ignore list `vcs-svn ignore src/sig/Makefile.in' is
> your friend.
>
> Hope this helps, and thank you for using Vcs.
>
> --
> Nicolas Pouillard aka Ertai <ertai(a)feydakins.org>
> http://uttk.org Uttk -- Unified Test Tool Kit
(BTW, a space is missing in your signature, it's "-- " not "--")
I know this is a "feature" of VCS. But I'm telling it not to recurse in this
directory so ... what the hell?
It's a bit borring to add all the files generated by the autotools in the
ignore list... maybe VCS should help by knowing that this particular file is
generated by auto* and thus ignore it (maybe also display a notice to let the
user know this file was ignored for such reasons)
--
SIGOURE Benoit aka Tsuna
_____
/EPITA\ Promo 2008.CSI Rock & tRoll
Hi,
vcs doesn't seem to support svn's option -N
for examples say I have:
? src/sig/Makefile.in
A src/sig
A src/sig/Makefile.am
ATM, I can't commit unless I rm src/sig/Makefile.in
$ vcs-svn ci -N src/sig src/sig/Makefile.am
vcs: info: Updating your working copy...
At revision 7.
? src/tools/Makefile.in
? src/sig/Makefile.in
vcs: error: You have unrecognized files in your working copy!This meant that these files wo
n't be committed!
--
SIGOURE Benoit aka Tsuna
_____
/EPITA\ Promo 2008.CSI Rock & tRoll
Tsuna <tsuna(a)slug.lrde.epita.fr> writes:
> Yop
> je sais si c'est le bon newsgroup pour ce genre de post mais j'ai un probleme
> vraiment bizzare sur mon rack:
>
> $ svn st
> vcs: error: command: svn status --
> vcs: error: exit: 1
> vcs: error: stderr: svn: error: cannot set LC_ALL locale
> vcs: error: stderr: svn: error: environment variable LC_ALL is en_US
> vcs: error: stderr: svn: error: please check that your locale name is correct
> vcs: error: command failed
> merci d'avance
J'avais eu ce problème a while ago, on avait vu avec Nicolas.
Il semblerait que ce soit du a un fichier pas loin de là où tu fais
ta commande qui serait dans un encodage bizarre.
Quoiqu'il en soit, on avait fait un correctif Q&D ; modifier le
fichier vcs.rb pour qu'il mette la locale à C ; il ne se rappelait
plus des stranges behavior de C à priori sur le moment.
Le bon newsgroup est lrde.proj.
Crosspost & Followup-To: lrde.proj
--
| Pour les 35-40 ans, l'humour Michaël `Micha' Cadilhac |
| c'est une plus-value. cadilh_m - Epita 2007 - CSI |
| -- Guillaume L. JID: micha(a)amessage.be |
`-- - - - - --'
>>>>> "Tsuna" == Tsuna <tsuna(a)slug.lrde.epita.fr> writes:
Tsuna> Yop je sais si c'est le bon newsgroup pour ce genre de post
Tsuna> mais j'ai un probleme vraiment bizzare sur mon rack:
lrde.proj est plus adapté aux questions sur Vcs (et sur les projets
émanant du labo en général).
Tsuna> $ svn st
Tsuna> vcs: error: command: svn status --
Tsuna> vcs: error: exit: 1
Tsuna> vcs: error: stderr: svn: error: cannot set LC_ALL locale
Tsuna> vcs: error: stderr: svn: error: environment variable LC_ALL is en_US
Tsuna> vcs: error: stderr: svn: error: please check that your locale name is correct
Tsuna> vcs: error: command failed
Tsuna> $ echo $?
Tsuna> 1
Tsuna> $ type svn
Tsuna> svn is an alias for vcs-svn
Tsuna> $ vcs --version
Tsuna> Vcs version: 0.5 (Beta Release 4)
Tsuna> $ \svn st
Tsuna> [la sortie de svn normal]
Tsuna> $ echo $?
Tsuna> 0
Tsuna> $ env | egrep '(LANG|LC_|en_)'
Tsuna> $ echo $?
Tsuna> 1
Tsuna> alors que sur ma machine au labo (meme versions de svn et vcs)
Tsuna> $ env | egrep '(LANG|LC_|en_)'
Tsuna> LANG=en_US
Tsuna> LANGUAGE=en_US:en_GB:en
Tsuna> une idee?
Oui : Vcs utilise d'autorité la locale en_US ; si elle n'est pas
installé sur l'hôte, il crie. C'est un comportement embêtant, qui a
déjà été soulevée dans un message intitulé « Vcs and locales » dans
lrde.proj. Nicolas nous avait dit qu'il avait rencontré des problèmes
avec la locale C, et c'est pour ça qu'il était passé à en_US.
Mais ce serait bien qu'on puisse réparer Vcs pour utiliser la locale
C, et non imposer l'installation d'une autre locale (ce qu'un
utilisateur lambda ne peut pas toujours faire, faute de droits sur le
système sur lequel il travaille).
D'après https://build.lrde.org/, plusieurs builds ne tournent plus sur
certaines machines depuis début avril. Est-ce que l'activité de la
build farm a été suspendue pour ces machines, ou bien s'agit-il d'une
panne ?
En fait, j'aimerai bien pouvoir compiler TC de façon exhaustive, càd :
- le projet complet depuis le dépôt SVN en utilisant les bibliothèques
statiques ;
- le projet complet depuis le dépôt SVN en utilisant les bibliothèques
dynamiques (avec TCSH) ;
- les tranches TC-1 à TC-9 en mode professeur (sans suppression de
code caché aux étudiants), en mode dynamique ;
sur plusieurs hôtes :
- Linux / i386 : une machine Debian du labo +
une machine Debian du PIE/Villejuif
- NetBSD / i386 : une machine du PIE/KB
- Mac OS X / PowerPC : antalya.lrde.epita.fr
(Ce sont les architecture sur lesquelles bossent la plupart des étudiants.)
et éventuellement :
- Cygwgin / i386 : pau.lrde.epita.fr
Et si possible avec plusieurs compilateurs (GCC 3.3, GCC 4.0, GCC 4.1,
ICC 9.1).
Et idem pour Olena.
Quelles sont les personnes qui s'occupent de la build farm
actuellement ?
Index: ChangeLog
from Benoit Perrot <benoit(a)lrde.epita.fr>
Make extraction of option's value more conventional.
* src/task/task_register.cc: Split argv[] on `=' for long options'
values only. Split argv[] in place for short options' value. Use
the next argv[] when no value is provided.
Index: src/task/task_register.cc
--- src/task/task_register.cc (revision 216)
+++ src/task/task_register.cc (working copy)
@@ -151,50 +151,91 @@
if ((1 < arg.size ()) && (arg[0] == '-'))
{
- std::string value;
+ std::string *value = 0;
+
+ // Identify option
+ TaskRegister::const_task_iterator it(tasks_.end());
+ if (arg[1] == '-') // Long option
+ {
+ // Split on `=' for value
unsigned eq = arg.find('=');
if (eq < arg.size())
{
- value = std::string(arg, eq +1);
+ // +1: do not include `=' in value
+ value = new std::string(arg, eq + 1);
arg.resize(eq);
}
- // Identify option
- TaskRegister::const_task_iterator it(tasks_.end());
- if (arg[1] == '-') // Long option
+ // Search for long option
it = find_task(arg);
- else // Short option
- for (unsigned l = 1; l < arg.size(); ++l)
+ }
+ else // Short option(s)
+ {
+ for (unsigned l = 1; l < arg.size() && !value; ++l)
{
std::string short_option("-");
short_option += arg[l];
+ // Search for short option
it = find_task(short_option);
- if (it != tasks_.end() && (l < arg.size() -1))
+
+ // Let last task fall through the remaining of the
+ // routine
+ if (l + 1 < arg.size())
+ if (it != tasks_.end())
+ {
+ if (it->second->needs_value())
+ // Split here for value
+ value = new std::string(arg, l + 1);
+ else
+ // Enable task
enable_task(*(it->second));
}
+ }
+ }
- // Consider value
+ // Enable (long or last short) task and set value if needed
if (it != tasks_.end())
{
const Task *task = it->second;
- if (!task->needs_value() && !value.empty())
+
+ if (task->needs_value())
+ {
+ if (!value)
+ {
+ ++i;
+ if (i < argc)
+ value = new std::string(argv[i]);
+ }
+
+ if (!value)
std::cerr
<< program_name
<< ": option `" << task->long_opt()
- << "' does not take a value" << std::endl;
- else if (task->needs_value() && value.empty())
+ << "' takes a value" << std::endl;
+ else
+ {
+ task->set_value(*value);
+ enable_task(*task);
+ }
+ }
+ else
+ {
+ if (value)
std::cerr
<< program_name
<< ": option `" << task->long_opt()
- << "' takes a value" << std::endl;
- else if (value.empty() || task->set_value(value))
+ << "' does not take a value" << std::endl;
+ else
enable_task(*task);
}
- else if (!value.empty())
+ }
+ else if (value)
std::cerr
<< program_name
- << ": `"<< value << "': unexpected value" << std::endl;
+ << ": `"<< *value << "': unexpected value" << std::endl;
+
+ delete value;
}
else
res = argv[i];
Faut-il insérer les en-têtes de licence/droit d'auteur dans les
fichiers de tests des projets du labo ? Est-ce que ça dépend de la
taille du test (en lignes de codes), le cas échéant ?
Merci d'avance pour vos réponses !
