> Il y a un point sur lequel Subversion est mal adapté aux fichiers
> "lourds" : on ne peut pas vider l'historique. C'est sûr que du code ça
> pèse pas lourd, mais une équipe de créa qui archive des PSD à coups de
> 100Mo (oui monsieur), il faut pas longtemps pour faire exploser
> n'importe quel serveur de fichier.

oui je connais ;)

mais bon ca peut passer si on organise le svn de telle manière
qu'il y ait un repo par projet

et aussi a cause de ca
http://subversion.tigris.org/faq.html#binary-files
"Note that whether or not a file is binary does not affect the amount
of repository space used to store changes to that file, nor does it
affect the amount of traffic between client and server. For storage
and transmission purposes, Subversion uses a diffing method that works
equally well on binary and text files; this is completely unrelated to
the diffing method used by the 'svn diff' command."

perso j'avais des tests avec un serveur Apache + mod_svn + mod_webDAV
et basiquement les devs bossaient en utilisant un soft svn pour le
code et qlqs FLA
et les graphistes (tous sous Mac) montait un repertoire wedDAV sur
leur Mac
comme si c'etait un repertoire partagé (SMB ou autre)
et dès qu'ils modifiaient le fichier ca faisait un commit automatique
(voir http://svnbook.red-bean.com/en/1.2/svn.webdav.autoversioning.html)

et de ce que j'ai vu
un PSD de 100Mo avec 100 commits different
ca n'egal pas 100 x 100Mo (heureusement :))

mais oui ca prends qd meme de la place

d'un autre coté laisser les designer "versioner a la main"
monfichier_001.psd, monfichier_002.psd, monfichier_003.psd, etc.
(ou autre systeme de nommage)
c'est pas le pieds non-plus

mais oui bon point, perso en general je vire la plupart des binaires
pour les trunk/ branches/ tags/
et meme si c'est mis dans le SVN c'est dans des repertoires "à part"
ou c'est un peu comme les "downloads" dans google code,
je me voit pas versionner des fichiers zip

> Et pour les FLA c'est un peu le
> même problème, mais à une échelle un peu moins critique - le super
> format XML est pas pour demain.
>
> Donc les alternatives (qui on une GUI) ça m'intéresse. Mais Version
> Cue... est-ce que des gens l'utilisent, en réalité ?
>

un truc a regarder c'est du coté des logiciels qu'utilisent
les boites de jeux videos (eux aussi ils ont bcp de gfx a
versioner ;))
il y avait un outil nommé "alien qlqch" mais j'arrive pas a le
retrouver

ah j'ai trouvé :)
http://www.alienbrain.com/
euh par contre les prix ca fait tres mal
http://www.alienbrain.com/pricing.php

sinon dans le meme genre il y a Flow
http://www.gridironsoftware.com/Flow/
qui a l'air d'etre le versionage de luxe pour les fichiers binaires/
graphiques/videos/audios
(en beta, mais testable apparemment, et qui reste d'etre cher en
final)

la demo video est plutot impressionnante :p

et meme John Nack est impressioné
http://blogs.adobe.com/jnack/2008/01/gridiron_flow_r.html
(ce qui en soit veut dire que version cue ne fait pas tout ca
aussi :D)


enfin bon je reviendrais sur ce que je disais "d'abord discuter du
serveur"

meme un tout SVN, et un repo par projet
peut-etre avoir un repo "a part" pour les fichiers binaires lourd
(videos,PSD,sons, etc.)
et utiliser un svn:external pour le linker avec le repo où il y a le
code source et les FLA

mais bon tout ca, ca s'organize coté serveur,
et ca peut vite devenir une grosse prise de tete

zwetan




--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe Groupe "FCNG" de 
Google Groupes.
 Pour transmettre des messages à ce groupe, envoyez un e-mail à 
l'adresse [email protected]
 Pour résilier votre abonnement à ce groupe, envoyez un e-mail à 
l'adresse [email protected]
 Pour afficher d'autres options, visitez ce groupe à l'adresse 
http://groups.google.com/group/FCNG?hl=fr
-~----------~----~----~----~------~----~------~--~---

Répondre à