Comment migrer sa base VSS vers CVS ? Quelques questions sur CVS...

On Sat, 14 Feb 2004 11:37:14 +0100, "Jean-Marc Molina"
<goa_pasdepourriel_@ifrance.com> wrote:

(...)

- Avec VSS on peut parfaitement gérer une base de plusieurs gigas (codes
sources, images, vidéos...), qu'en est-il avec CVS ?

Cvs est légendaire pour ses limitations de gestion des fichiers
binaires. D'autres programmes visent à éliminer les restrictions de
Cvs, dont Subversion - dont le but est d'etre un remplacement
(c'est à dire d'offrir la plupart des capacités de manière similaire)
de Cvs, sans les limitations de Cvs
Subversion est passé en Beta il y a quelques semaines.

A mon avis, il vaut mieux se tourner vers Subversion
(http://subversion.tigris.org) pour un nouveau projet de ce genre.

Gérard Patel

"Jean-Marc Molina" <goa_pasdepourriel_@ifrance.com> writes:

(Un groupe Usenet plus approprié pour poster ? J'ai trouvé des références à
CSS/VSS sur ces groupes à partir de Google Groupes)

Bonjour,

Je cherche une solution pour migrer une base VSS (Microsoft Visual
SourceSafe) vers CVS (Concurrent Versions System). J'aimerai avant tout
conserver l'historique des modifications faites par les utilisateurs sur les
codes sources : noms des utilisateurs, différences, dates, commentaires,
labels des versions du projet (très importants : alpha, béta...)...

version := 1;
repeter tant qu'il reste des versions :
checkout de la version de VSS
checkin dans CVS

(C'est un peu plus compliqué: il faut faire des cvs add pour les
fichiers ajoutés (en particulier la première fois), et des cvs delete
pour les fichiers supprimés. Mais c'est le principe).

Quelques questions sur CVS :
- Avec VSS on peut parfaitement gérer une base de plusieurs gigas (codes
sources, images, vidéos...), qu'en est-il avec CVS ? Je ne le connais que
pour gérer des codes sources. Je cherche à passer outre la limite de VSS
(une vieille histoire de code 32 bits ou je ne sais quoi).

Les fichiers binaires doivent etre ajoutés dans CVS avec l'option -kb.

Je crois que dans ce cas là, CVS ne cherche pas à calculer la
différence: chaque version est stoquée intégralement dans le fichier
de CVS. Or, toutes les versions sont concaténées dans un seul
fichier. Selon les possibilités de CVS et du File System où ses
fichiers sont enregistrés, et de la taille du fichier on peut
facilement atteindre la limite de 2 Go.

Sinon, pour un fichier source de 100 KB (ce qui fait déjà un bon gros
source), on pourrait stocker au moins 20971 versions différentes avec
l'option -kb avant d'arriver à une archive CVS de 2Go. Si on a une
image de 1 Mo, on a le droit à 2047 versions...

- Quels clients « graphiques » sous Linux/Windows utilisez-vous ? Si
possible multi plate-formes. Je connais WinCVS que j'utilise sous Windows
avec CVSNT.

Aucun. Les vrais programmeurs travaillent en CLI.

- Connaissez-vous des solutions (APIs/Middlewares, articles, didacticiels,
livres...) pour intégrer CVS à un logiciel ?

Emacs sait travailler avec CVS sans aucun besoin de middleware.

Il existe par exemple des
plugins CVS pour Microsoft Visual Studio, un autre pour l'EDI Zend Studio
(développement PHP), etc... Je cherche de la documentation sur ce sujet,
même si la documentation CVS est déjà bien fournie, il y a toujours des
références qu'on ne connait pas.

Merci par avance pour votre aide,
JM

--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

On Sat, 14 Feb 2004 15:11:34 +0100, Pascal Bourguignon wrote:

Quelques questions sur CVS :
- Avec VSS on peut parfaitement gérer une base de plusieurs gigas (codes
sources, images, vidéos...), qu'en est-il avec CVS ? Je ne le connais que
pour gérer des codes sources. Je cherche à passer outre la limite de VSS
(une vieille histoire de code 32 bits ou je ne sais quoi).

Les fichiers binaires doivent etre ajoutés dans CVS avec l'option -kb.

Je crois que dans ce cas là, CVS ne cherche pas à calculer la
différence: chaque version est stoquée intégralement dans le fichier
de CVS. Or, toutes les versions sont concaténées dans un seul
fichier. Selon les possibilités de CVS et du File System où ses
fichiers sont enregistrés, et de la taille du fichier on peut
facilement atteindre la limite de 2 Go.

Sinon, pour un fichier source de 100 KB (ce qui fait déjà un bon gros
source), on pourrait stocker au moins 20971 versions différentes avec
l'option -kb avant d'arriver à une archive CVS de 2Go. Si on a une
image de 1 Mo, on a le droit à 2047 versions...

La limite des 2 Go n'est plus un problème dans les noyaux Linux
depuis longtemps (les premiers 2.4). Si il y a encore un problème,
c'est un bug de CVS, qui n'utiliserait pas l'option O_LARGEFILE
en ouvrant ses fichiers, mais ça me semble extrèmement peu
probable...

no_spam <l_indien_no_more_spams@magic.fr> writes:

On Sat, 14 Feb 2004 15:11:34 +0100, Pascal Bourguignon wrote:

>> Quelques questions sur CVS :
>> - Avec VSS on peut parfaitement gérer une base de plusieurs gigas (codes
>> sources, images, vidéos...), qu'en est-il avec CVS ? Je ne le connais que
>> pour gérer des codes sources. Je cherche à passer outre la limite de VSS
>> (une vieille histoire de code 32 bits ou je ne sais quoi).
>
> Les fichiers binaires doivent etre ajoutés dans CVS avec l'option -kb.
>
> Je crois que dans ce cas là, CVS ne cherche pas à calculer la
> différence: chaque version est stoquée intégralement dans le fichier
> de CVS. Or, toutes les versions sont concaténées dans un seul
> fichier. Selon les possibilités de CVS et du File System où ses
> fichiers sont enregistrés, et de la taille du fichier on peut
> facilement atteindre la limite de 2 Go.
>
> Sinon, pour un fichier source de 100 KB (ce qui fait déjà un bon gros
> source), on pourrait stocker au moins 20971 versions différentes avec
> l'option -kb avant d'arriver à une archive CVS de 2Go. Si on a une
> image de 1 Mo, on a le droit à 2047 versions...

La limite des 2 Go n'est plus un problème dans les noyaux Linux
depuis longtemps (les premiers 2.4). Si il y a encore un problème,
c'est un bug de CVS, qui n'utiliserait pas l'option O_LARGEFILE
en ouvrant ses fichiers, mais ça me semble extrèmement peu
probable...

Le bon gros source de 100 Ko a droit à 20971 versions (avec -kb !!!),
le bon gros jpeg de 1 Mo à droit à 2047 version. Donnez moi une
raison valide pour mettre O_LARGEFILE dans CVS?

--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

On Sat, 14 Feb 2004 18:49:56 +0100, Pascal Bourguignon wrote:

no_spam <l_indien_no_more_spams@magic.fr> writes:

On Sat, 14 Feb 2004 15:11:34 +0100, Pascal Bourguignon wrote:

>> Quelques questions sur CVS :
>> - Avec VSS on peut parfaitement gérer une base de plusieurs gigas (codes
>> sources, images, vidéos...), qu'en est-il avec CVS ? Je ne le connais que
>> pour gérer des codes sources. Je cherche à passer outre la limite de VSS
>> (une vieille histoire de code 32 bits ou je ne sais quoi).
>
> Les fichiers binaires doivent etre ajoutés dans CVS avec l'option -kb.
>
> Je crois que dans ce cas là, CVS ne cherche pas à calculer la
> différence: chaque version est stoquée intégralement dans le fichier
> de CVS. Or, toutes les versions sont concaténées dans un seul
> fichier. Selon les possibilités de CVS et du File System où ses
> fichiers sont enregistrés, et de la taille du fichier on peut
> facilement atteindre la limite de 2 Go.
>
> Sinon, pour un fichier source de 100 KB (ce qui fait déjà un bon gros
> source), on pourrait stocker au moins 20971 versions différentes avec
> l'option -kb avant d'arriver à une archive CVS de 2Go. Si on a une
> image de 1 Mo, on a le droit à 2047 versions...

La limite des 2 Go n'est plus un problème dans les noyaux Linux
depuis longtemps (les premiers 2.4). Si il y a encore un problème,
c'est un bug de CVS, qui n'utiliserait pas l'option O_LARGEFILE
en ouvrant ses fichiers, mais ça me semble extrèmement peu
probable...

Le bon gros source de 100 Ko a droit à 20971 versions (avec -kb !!!),
le bon gros jpeg de 1 Mo à droit à 2047 version. Donnez moi une
raison valide pour mettre O_LARGEFILE dans CVS?

Il arrive d'avoir besoin de fichiers binaires bien plus gros que 1 Mo.
Et un/quelques milliers de versions pour un projet proffessionnel
qui évolue sur une dizaine d'année, ce n'est pas beaucoup.
De plus, si cvs n'utilise pas le O_LARGEFILE, il rique d'avoir
des problèmes avec ses fichiers historiques (CVSROOT/commitlog
et CVSROOT/history), ce qui le rendrait inutilisable dans un
environnement pro.
En passant, j'ai vérifié au boulot, ou on est à peu près dans le
cas que je décrit. Il y a des fichiers de largement plus de 2 Go
dans le cvsroot.
Donc, cvs ne souffre d'aucun bug à ce sujet et gère bien les fichiers
en 64 bits, comme il est censé le faire...

> [...]
En passant, j'ai vérifié au boulot, ou on est à peu près dans le
cas que je décrit. Il y a des fichiers de largement plus de 2 Go
dans le cvsroot.
Donc, cvs ne souffre d'aucun bug à ce sujet et gère bien les fichiers
en 64 bits, comme il est censé le faire...

C'est pas 4go la limite de taille en 32 bits ?

Mike

"Mickael Pointier" <mpointier@eden-games.moc> writes:

> [...]
> En passant, j'ai vérifié au boulot, ou on est à peu près dans le
> cas que je décrit. Il y a des fichiers de largement plus de 2 Go
> dans le cvsroot.
> Donc, cvs ne souffre d'aucun bug à ce sujet et gère bien les fichiers
> en 64 bits, comme il est censé le faire...

C'est pas 4go la limite de taille en 32 bits ?

Cf definition de off_t!

--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

Pascal Bourguignon wrote:

"Mickael Pointier" <mpointier@eden-games.moc> writes:

[...]
En passant, j'ai vérifié au boulot, ou on est à peu près dans le
cas que je décrit. Il y a des fichiers de largement plus de 2 Go
dans le cvsroot.
Donc, cvs ne souffre d'aucun bug à ce sujet et gère bien les
fichiers en 64 bits, comme il est censé le faire...

C'est pas 4go la limite de taille en 32 bits ?

Cf definition de off_t!

Et ?

Je faisait juste référence au fait qu'il y avait un raccourcis un peu
rapide entre "Vu que les fichiers de plus de 2 Go passent, alors c'est
que la gestion se fait bien en 64 bits."

C'est manifestement inexact.

Après que l'implémentation utilise des signed char ou quoique ce soit du
même type ne change rien au fait que 2go n'est pas la limite d'une
architecture 32 bits.

Mike

"Mickael Pointier" <mpointier@eden-games.moc> writes:

Pascal Bourguignon wrote:
> "Mickael Pointier" <mpointier@eden-games.moc> writes:
>
>>> [...]
>>> En passant, j'ai vérifié au boulot, ou on est à peu près dans le
>>> cas que je décrit. Il y a des fichiers de largement plus de 2 Go
>>> dans le cvsroot.
>>> Donc, cvs ne souffre d'aucun bug à ce sujet et gère bien les
>>> fichiers en 64 bits, comme il est censé le faire...
>>
>> C'est pas 4go la limite de taille en 32 bits ?
>
> Cf definition de off_t!

Et ?

Et off_t est signed sur les systèmes que j'utilise, c'est pourquoi
gzip (qui n'utilise pas O_LARGEFILE) ne peut pas compresser des
fichiers de plus de 2 Go par exemple.

Je faisait juste référence au fait qu'il y avait un raccourcis un peu
rapide entre "Vu que les fichiers de plus de 2 Go passent, alors c'est
que la gestion se fait bien en 64 bits."

C'est manifestement inexact.

Après que l'implémentation utilise des signed char ou quoique ce soit du
même type ne change rien au fait que 2go n'est pas la limite d'une
architecture 32 bits.

Non, mais entre 2Go et 4Go, on est comme Alice, de l'autre côté du mirroir.


--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

On Mon, 16 Feb 2004 19:02:42 +0100, Pascal Bourguignon wrote:

"Mickael Pointier" <mpointier@eden-games.moc> writes:

Pascal Bourguignon wrote:
> "Mickael Pointier" <mpointier@eden-games.moc> writes:
>
>>> [...]
>>> En passant, j'ai vérifié au boulot, ou on est à peu près dans le
>>> cas que je décrit. Il y a des fichiers de largement plus de 2 Go
>>> dans le cvsroot.
>>> Donc, cvs ne souffre d'aucun bug à ce sujet et gère bien les
>>> fichiers en 64 bits, comme il est censé le faire...
>>
>> C'est pas 4go la limite de taille en 32 bits ?
>
> Cf definition de off_t!

Et ?

Et off_t est signed sur les systèmes que j'utilise,

C'est logique, un offset est une position relative qui peut être
avant ou après une position absolue, donc forcément signée...

c'est pourquoi
gzip (qui n'utilise pas O_LARGEFILE) ne peut pas compresser des
fichiers de plus de 2 Go par exemple.

Comme j'aime bien occuper mon CPU, j'ai fait le test:

dd if=/dev/urandom of=/tmp/cp bs48576 count@96

4096+0 records in
4096+0 records out

ls -lh /tmp/cp

-rw-r--r-- 1 xxx xxx 4.0G Feb 16 22:12 /tmp/cp

gzip -1 /tmp/cp
ls -lh /home/jocelyn/devel/Netgem/tmp/cp.gz

-rw-r--r-- 1 xxx xxx 4.1G Feb 16 22:12 /tmp/cp.gz

A priori, ça fait un bail que tous les programmes GNU utilisent
le O_LARGEFILE par defaut (c'est inclus dans _GNU_SOURCE),
mais je voulais quand même vérifier...

Je faisait juste référence au fait qu'il y avait un raccourcis un peu
rapide entre "Vu que les fichiers de plus de 2 Go passent, alors c'est
que la gestion se fait bien en 64 bits."

C'est manifestement inexact.

C'était sans doute un peu rapide, mais absolument pas inexact...

Après que l'implémentation utilise des signed char ou quoique ce soit du
même type ne change rien au fait que 2go n'est pas la limite d'une
architecture 32 bits.

Non, mais entre 2Go et 4Go, on est comme Alice, de l'autre côté du mirroir.

... car beaucoup d'API Posix ont besoin d'arguments et de valeurs
de retours signées.
Ce n'est donc pas la limite de l'espace d'addressage, en effet,
mais bien celle d'une grande partie des API.
En passant, d'ailleurs, sous Linux, l'espace d'addressage utilisable
par un programme est de bien moins de 4Go (à part en highmem64...).
Essayes de faire un mmap ne serait-ce que de 2Go (sur un fichier,
pour ne pas croire que le problème est du à un manque de RAM),
avec un kernel récent, dont le mmap est en 64 bits...