Reprise du message précédent :
git lfs pour les binaires ?

Sauf que quand tu rajoutes des bricolages autour, tu perds effectivement la distributivité du système, tu te retrouves avec plusieurs pièces qui bougent indépendamment et peuvent désync, faire des conneries est d'autant plus facile et t'as souvent pas les trucs basiques utilises genre des fichiers lockables.
 
Au final tu réinventes un CVCS en moins bien sur ton DVCS

Mais ouais, au lieu d'utiliser un CVCS tu remontes un CVCS sur ton DVCS, c'est tellement plus simple, comme ca t'as tous les inconvénients des deux, aucun des avantages, et encore plus de bordel à maintenir

Puis l'avantage avec git lfs c'est que t'as toujours jean-jean qui oublie de configurer ses filtres et te fuck ton repo.

Combien de temps que tu es dans ta boite actuelle ?
Est ce que tu arrives facilement à avoir une seconde offre qui soit similaire à celle qui t'es faite ou juste en dessous ?
 

 
certes

mais du coup ça ne donne pas de solution, ça veut dire que des qu'on a quelques binaires non mergeables dans un projet on est obligé de passer par du CVCS ?  
utiliser un hybride hypothétiquement bien conçu c'est forcement merdique ?

 
mouais.. Enfin on a beau avoir du distribué, il y a quand même un repo "centralisé" à un moment (sauf si tu reverses jamais tes modifs)
 
Et même comme ça, ajouter un timestamp au cul du hash (ou en tête, genre YYYYMMDD-HHMMSS.ms-HashGit), ça conserve la (pseudo ) unicité des hash, et ça permet d'ordonner les trucs.
 
Ca donne pas une info fiable à 100%, mais suffisament fiable dans un environnement classique (ie, avec une équipe de quelques dévs qui se parent de temps en temps)
 
Tu peux même imaginer de modifier ce timestamp au moment où tu publies, pour y mettre le timestamp de la date du merge.
 
bref.
 

 
* 2 ans 1/2, 3 ans début décembre,
* pas vraiment, non. En province pour un poste technique, ça commence à faire beaucoup.
 
 
 

C'est plus une question de degrés, si t'as peu de binaires et/ou aucune collaboration dessus tu utilises un DVCS, si t'as beaucoup de binaires et de la collaboration dessus tu seras beaucoup mieux sur un CVCS, c'est complètement con de rajouter des couches de merde sur un outil pas adapté juste parce que t'es obstiné

Les timestamps, ça n'est fiable que si tous les postes sont exactement à la même heure. Or toutes les horloges ont un drift différent, et n'importe qui peut changer une horloge et foutre le boxon. Pour ça qu'on ne se base pas dessus pour déterminer l'ordre.

 
Enfin dans la pratique, ca serait suffisant pour donner une idée juste la plupart du temps. C'est toujours le SHA qui servirait en interne donc ca foutrait pas de boxon.

Mais git show donne déja les dates, je comprends pas le pb. Si on est en ligne de commande on peut se faire un alias, perso j'utilise git extensions qui fait déjà ça pour moi.

Tu peux avoir le numéro de révision SVN sans avoir SVN...
 
Exemple : dans notre webapp, il y a le numéro de révision dans la page about (il y a aussi la version Maven, evidement).
 
Mais on a plusieurs environnements de recette que lesquels le Jenkins peut déployer (certains automatiquement, d'autres à la demande)
 
Du coup, sur 2 environnements différents qui ont des comportements différents, tu peux avoir le même snapshot Maven, mais pas la même révision.. Donc tu peux savoir quel environnement est le plus "frais" des deux sans utiliser git.
 
Je dis pas que c'est une killer feature, je dis que ça donne une indication qui a du sens, et que c'est dommage de passer de ça à 0 indication en passant de SVN à git.

Rien ne t'empêches de tagguer tes releases/build en incrémental.

sinon pour déployer en prod il y a un truc génial que s'appelle le numéro de version via un tag

grillé  

oui, je pense que le problème central c'est que tout le monde utilise des DVCS alors qu'on en a pas besoin. A la base le principe c'était que chacun ait son repo git exposé sur le réseau local et que tout le monde puisse aller merger des trucs pris chez tout le monde, l'absence d'autorité centrale faisait qu'on pouvait pas numéroter globalement. Aujourd'hui on est tous chez github, et github pourrait très bien donner des numéros en étant la seule autorité pour le faire. Sauf qu'évidemment le protocole n'a pas été prévu pour qu'une autorité centrale donne des numéros de commit.

 
En dehors des tags qui sont la solution évidente, je te conseillerais de commencer par arrêter de bosser comme ça.
 

rien n'empêche le serveur central de tagger automatiquement et incrémentalement chaque commit (ou au moins le dernier commit de chaque push)
 
après tous les outils ne vont pas forcement bien aimer un trop grand nombre de tag, mais ça c'est un autre problème...

oui voilà, le nombre de tags et l'UI pour les représenter.

ou via git notes alors
 
c'est déjà très utilisé d'ailleurs pour backannoter les résultats des tests (jenkins, etc ...)

Perso je trouve que la décision de numéroter une version est typiquement humaine. Donc les tag c'est très bien Sinon un hash de commit quand c'est nécessaire (de quel commit on parle par exemple)

 
Pourquoi? Les environnements de recette dont il est question, c'est des recettes internes, pas pour le client.
 
On a une équipe de ~20 dévs, et des fonctionnels à côté qui peuvent dire "oui, John m'a dit que le dév de la nouvelle feature MachinTruc est fini, j'ai bien envie de tester, donc je deploy le trunk sur la recette 3 (ou 4, ou OSEF), et je regarde.
 
.. et remarque, j'ai dit une connerie, quand il fait ça, ça taggue
 
(après, les recettes sont jetables à l'exception des données, donc on s'en fout de ce qui est déployé dessus, au final : pendant la phase de recette pré-livraison, on y déploie ce qu'on a prévu de livrer, pas un snappshot pourri)

Si c'est pas encore testé, c'est pas fini.
Ton trunk devrait être continuellement intégré, déployé, et accessible.
À la rigueur tu fais occasionnellement une branche pour une fonctionnalité un peu risquée et tu la déploies à la main.

Mais utiliser des révisions SVN pour ça, nope.

Non mais le trunk EST continuellement déployé et accessible. Et la branche de maintenance de prod aussi.

Il les donne mais il ne se base jamais dessus. Enfin je pense. Les dates de commit n'ont pas plus de valeur que celle d'un mail. Rappelons que les devs du kernel Linux sont répartis sur les 24 fuseaux horaires. Mais pour ça c'est pareil avec tous les gestionnaires de version, je doute qu'il y en ait un qui se base sur les timestamps (sauf Sourcesafe, on sait jamais ).

Tu peux faire des git log —date-order, c'est pas très utile vu que ça peut être n'importe quoi (on a eu des devs qui committaient 2 mois dans le futur, ou 4 ans dans le passé) mais bon ymmv.

c'est marrant, je m'attendrai à ce que tout le monde attrape son heure sur internet et ne pas être trop à la rue.

Vous avez des techniques pour gérer le stress de votre boulot ?
Genre, quand une décision qui ne vous incombe pas remet en cause votre capacité à accomplir votre projet, ou que simplement les choses semblent partir en vrille et que vous vous retrouvez plutôt à jouer le pompier plutôt que vraiment pouvoir anticiper ?

Edit : l'alcool n'est pas une réponse acceptable

perso je me suis mis au sport. Aucune différence visible sur mon niveau de stress.

yaourt RAB
https://www.youtube.com/watch?v=-24UH4KRjgY

 
C'est un peu l'alcool, ca, non ?  

Cela dit, c'est une contribution intéressante, parce que je ne fais pas de sport et me demandais justement si ca pourrait avoir une influence  

il y a besoin d'alcool pour en avoir rien à foutre ? il n'y a pas que le boulot dans la vie

je crois qu'il est de bon ton de dire aux gens que le sport est bon pour le stress, donc je pense que tu devrais faire du sport.

J'ai du virer mon post de Janvier trop vite.

 
Nan mais c'est un point valide, j'ai déjà entendu ca plusieurs fois sans vraiment y croire

A haute dose le sport libère des endorphines. Mais il faut compter au moins 40 mn d'effort prolongé. De ma petite expérience (je ne suis pas un gros sportif), ça permet surtout d'oublier le stress une fois qu'on est sorti du boulot (et améliorer son état de santé général). Le stress au boulot, c'est assez personnel. Peut-être une manière de l'éviter ou le réduire est de se prémunir activement contre les futurs reproches qui vont t'être faits: ouvertement (par écrit) faire comprendre que tu ne pourras pas mener ta tâche à bien du fait des changements de conditions et donc négocier un changement de celle-ci à la baisse (après tout c'est ce que fait un chef de projet), quitte à quantifier tout ça pour faciliter le travail de ton chef, et ensuite consigner tout ce que tu fais, jour par jour, pour le moment où tu devras rendre des comptes.
Et après, yaourt RAB.

Moi j'ai fait des gosses. Après les 3 mois tu es complètement immunisé contre le stress.

 
J'en suis qu'à un mois mais je dis "bullshit".

Le sport ça marche oui, mais faut un bon effort : minimum 40 min d'activité en effet, moi où j'ai trouvé mon exutoire c'est 2x20km de vélo tous les week end (pour me déplacer mais ça me fait du sport aussi ).
 
Quand je roule en mode un peu fort, j'ai pas le temps de penser à trop de trucs, j'essaie déjà de pas mourir asphyxié par l'effort Bref, ça me fait beaucoup de bien et j'attaque la semaine plus reposé mentalement