Reprise du message précédent :

Les  applefan son désespérants

Pour la modification, dès que le fichier est ouvert sur un poste, il est accessible pour les autres en lecture seule.
Pour la suppression, c'est ballot !

chef , chef, j'ai fini de développer la ged , j'ai juste partagé un repertoire sur le réseau

et sinon la majorité de sprogrammes ont des perfs désastreuses dès qu'on parle de lecture via le réseau ( rien qu'un fichier excel un peu gros est problématique)

salut les gros.

http://online.wsj.com/article/SB12 [...] %3Darticle  

Ballmer peak in action

NO ONE

NO ONE IS GOING'S GONNA STOP ME NAO

Except the anti flood, naturalie.

Ouai mais faut faire le dev qui va avec !

L'intérêt il est que j'ai pas a m'occuper de faire une copie local, de faire éventuellement du gzip

La gestion des locks est indépendante du fonctionnement (copie locale volontaire par l'appli ou  windows comme un grand) vu que l'ouverture se fait par l'appli. A l'ouverture du fichier je lock !
 

Nous ici on fait tout comme ça mais on est  6
 
Mais ce que j'ai du mal a appréhender c'est que quand tu ouvres un fichier sur le serveur, windows en fait bien une copie locale, non ?
Elle se synchronise comment ? C'est cette synchronisation qui bouffe de la perf je suppose.
 
Donc faire de la copie locale via mon appli ça va faire gagner de la perf pour le serveur et le réseau ?

Mais de quelle synchro tu parles ?
 

 
Si c'est un partage Windows, la réponse est non.

Tu ouvre un .doc qui se trouve sur un lecteur réseau. :
a) Tu bosses direct dessus
b) Il fait une copie locale sur ton poste et sauvegarde le doc sur le réseau à chaque modification
 
?

reponse a

vos gueules

crève

 
J'aurais dit a) aussi mais est ce que c'est dépendant du type de fichier et de l'appli associée ou ça vient de windows ?
Parceque altherac a pas l'air d'accord !

 
Il fait pas de copie locale, tu bosses direct sur le fichier distant.
Word crée un fichier temporaire, mais en général dans le même répertoire que le fichier ouvert.

okay
 
D'où l'intérêt de faire une copie locale avec mon appli !

Le jour où je bouffe mon sandwich au bureau, faut que les deux seuls tocards qui restent dans le bureau soient le chef de projet senior relou et le mec qui fait un gros reniflement gras dégueulasse toutes les minutes
 
SUCH A WONDERFUL WORLD

tiens, mon patron bosse chez toi aussi ?

http://www.reddit.com/r/technology [...] pen_for_a/

Tient je suis votre boss ?  

j'espère vraiment ne jamais te rencontrer, là du coup

canyon.mid \o/

Moi je dirais ni l'un ni l'autre ; les données sont quand même mises en cache localement, et la synchro avec le fichier sur le serveur se gère à coup d'oplocks

hey mais c'est mon appli  

 
PQ

 
Tree

 
Les prix affiches sont hors services et hors taxes.
 
Quasiment tous les gens qui sont employés et en contact avec du public s'attendent a avoir des pourboires (et ils sont payes en tenant compte du fait qu'ils en auront). C'est au point où dans les papiers qu'on avait reçus lors d'un gros rassemblement de gens de ma boite il était indique qu'il ne fallait pas donner de pourboire sauf si on était exceptionnellement content, parce que le service avait déjà été payé.
 
Dans les restaurants qui reçoivent beaucoup d'étrangers, ils mettent parfois le pourboire d'office quand ils remarquent que tu en es un; tu peux le changer si tu veux faire passer un message.

Le problème de bosser directement sur un fichier partagé, c'est pas seulement un problème de perfs (à chaque save, je te le rappelle, donc potentiellement 15 fois par jour) qui va dépendre du réseau et de chaque reconfiguration de ce dernier, mais aussi et surtout un problème de fiabilité: les fichiers sont partagés, que se passe-t'il si un archi merde ou qu'il y a un plantage réseau en plein save ? Ben ton fichier est pourri, t'es obligé d'aller voir l'admin réseau de service pour récupérer la dernière sauvegarde et t'as perdu ta journée. Avec 150 personnes sur le repository, ce genre de situation a toute chance d'arriver une à plusieurs fois par semaine. De plus il n'y a pas moyen de revenir sur une version précédente de ton fichier, ce qui est pourtant qq chose de potentiellement intéressant.
Faire une copie locale, c'est long au moment du checkout (le matin), c'est long au moment du checkin (le soir), mais entre les deux, tu peux faire n'importe quoi, d'une part ça tournera vite sur ton poste, et d'autre part ça n'affectera le repository qui doit avoir pour objectif d'être tout le temps clean.

mais pourquoi les opérateurs de shift (<< et >> ) sont moins prioritaire que les opérateurs arithmétiques (+ - * /) en C

Si tu prends la voiture :
- fais gaffe aux pool lane
- tu peux griller un feu rouge pour tourner à droite (le feu faisant dans ce cas office de cédez-le-passage)

C'est de l'ordre de 10% le service, non ?

ça dépend des états !

a peu près, suivant la qualité de la prestation. Souvent tu donnes l'équivalent des taxes !

Et pour continuer sur ce sujet, une gestion par BD plus le système proposé auparavant permet de proposer une véritable gestion documentaire, avec versionnage, recherches par mots-clé, type de document, date, auteur, intervenants, client, autorisations d'accès, etc.

Effectivement pour la fiabilité il peut y avoir un gros impact.

le gestion de version se fait directement via l'application donc tu as toujours accès à l'ancienne version.

Le pb c'est que c'est pas 1 gros fichier sur lequel tu bosses toute la journée. Ca peut être aussi 1 centaine de petits fichiers créé ou manipulé sur une journée par un utilisateur !

C'est ce qu'on fait et plus encore