Journal Accès à Microsoft Source Safe depuis Linux ...

• # SourceOffsite

  Posté par allcolor (site web personnel) le 31 octobre 2006 à 15:59. Évalué à 1.

  

  Y a sourceoffsite pour ça (ça demande un serveur sur la machine qui a accès à la db sourcesafe).
  
  Ça marche très bien...
  
  http://www.sourcegear.com/sos/index.html

  • [^] # Re: SourceOffsite

    Posté par Gamier Sébastien le 31 octobre 2006 à 16:05. Évalué à 1.

    

    "(ça demande un serveur sur la machine qui a accès à la db sourcesafe)"
    
    C'est bien cela mon souci.. tout les produits demande d'installer un serveur (de communication) pour communiquer ensuite avec le client de l'autre OS !!
    
    Donc inutilisable dans mon cas...

• # pour répondre a ta question

  Posté par fearan le 31 octobre 2006 à 16:05. Évalué à 5.

  

  >pourquoi faut-il un NT sur ma machine, et pourquoi installer sourceSafe sur ce NT ??
  
  Simple : Wine n'implémente pas encore toutes les fonctionalités des APIs de windows ( travail titanesque ), donc si tu as un windows installé, tu peux te servir des dll du windows existant.
  
  Avec wineconfig, tu peux même choisir quel priorité donner à tes dlls :P
  
  sinon j'ai aussi trouvé http://j-integra.intrinsyc.com/support/com/doc/other_example(...)
  pour acceder a Visual source safe depuis java...
  
  et sinon j'ai trouvé aussi ceci 'SourceSafe for Unix 0.7'
  ( http://linux.softpedia.com/get/Programming/Version-Control/S(...) )
  Alors tu peux tester celle la :P

  Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: pour répondre a ta question

    Posté par Gamier Sébastien le 31 octobre 2006 à 16:29. Évalué à 1.

    

    ok pour wine.. je comprends bien le souci maintenant...
    
    sinon pour SourceSafe for Unix 0.7
    
    "· SSU is divided into two components: a command-line Unix client and a windows-based server which runs on a machine with repository access."
    
    donc c'est cuit -> pas d'accès sur la machine serveur contenant la DB source safe
    
    et pour JIntegra :
    
    "Run J-Integra's com2java tool on the Windows machine, and select C:\Program Files\Microsoft Visual Studio\Common\VSS\win32\SSAPI.DLL..."
    
    donc c'est la même chose :-)

    • [^] # Re: pour répondre a ta question

      Posté par allcolor (site web personnel) le 31 octobre 2006 à 18:28. Évalué à 1.

      

      Le serveur ne doit pas nécessairement tourner sur la machine contenant la DB sourcesafe, uniquement sur une machine windows qui peut avoir un drive mappé ayant accès à la DB (en tout les cas sourceoffsite marche comme ça). Donc si tu peux installer le serveur SourceOffsite sur une autre windows qui peut avoir un drive mappé sur la db sourcesafe, c'est bon.

  • [^] # Re: pour répondre a ta question

    Posté par popopo333 le 31 octobre 2006 à 17:47. Évalué à 3.

    

    je pense que depuis 2002 (date indiquee sur la page), wine s'est ameliore et que donc ca meriterait d'essayer sans installer un windows.

• # Ouh la la?

  Posté par Fabimaru (site web personnel) le 31 octobre 2006 à 20:09. Évalué à 3.

  

  Ça ne t'aideras pas, mais... ça me rappelle de bien tristes souvenirs. Quelle bouse ce Source (un)Safe! C'est le super gestionnaire de version... qui ne travaille pas en client serveur. Des bons vieux fichiers sur un partage avec des verrous.
  Ça me rappelle d'ailleurs la fois où ça marchait tellement bien que le serveur de fichier NT4 n'arrivait pas à déverrouiller un fichier, et qu'il a fallu le redémarrer (bien sûr, avec un certain nombre de gens qui bossent dessus).
  Ou alors la fois où on s'est retrouvé avec un fichier avec une date de modification dans le futur, ce qui faisait qu'on ne pouvait plus lui mettre de nouvelles versions. Et comme le format de fichier est clair comme de la boue (avec des checksums quelque part pour t'empêcher de le dé-corrompre, youpi!), tu l'as dans le baba! Après on comprend la nécessité absolue d'utiliser des formats de fichiers ouverts.
  
  
  Alors, pour le bien de ta santé mentale, fais passer l'idée de migrer à ton boulot CVS ou Subversion (progressivement). En plus c'est gratos, et t'as des clients bien sympas. Nous on utilise actuellement le premier sous Windows (et aussi sous divers Unix), donc c'est possible :-)

  • [^] # Re: Ouh la la?

    Posté par CrEv (site web personnel) le 31 octobre 2006 à 20:26. Évalué à 1.

    

    Presque pareil à mon boulot, on utilise sourcesafe (y compris pour des logiciels devant tourner sous windows et mac, le tout sans avoir de client mac... cherchez pas ça marche pas bien du tout comme solution...)
    
    Le plus marrant c'est d'entendre les gens gueuler pour qu'un autre développeur libère un fichier... jusqu'au jour ou une machine est formatée sans avoir libéré les fichiers... efficace.
    
    Mais si ça intéresse quelques personnes, j'ai commencé un script de migration vss -> svn en ruby (utilise les commandes dos vss donc à faire tourner sur un windows). Je l'ai pas là mais je peux le ramener jeudi si ça intéresse quelqu'un (mais soyez indulgent, c'est mon premier programme ruby ;-) )
    La migration marche pas trop mal, mais c'est assez lent (environ 30 minutes pour 2000 révisions - je gère la migration de la même manière que vss, fichier par fichier, c'est pas le plus propre vis à vis de svn mais ça permet de garder une cohérence lors de la migration)

    • [^] # Re: Ouh la la?

      Posté par Fabimaru (site web personnel) le 31 octobre 2006 à 21:37. Évalué à 2.

      

      Le plus marrant c'est d'entendre les gens gueuler pour qu'un autre développeur libère un fichier...
      Tiens, j'avais oublié les "tu me rends le fichier X?" (et oui, chez nous aussi à l'époque) :-) Visual Source Safe, soude votre équipe!

      • [^] # Re: Ouh la la?

        Posté par David Sporn (site web personnel) le 02 novembre 2006 à 16:52. Évalué à 1.

        

        Autre joyeuseté avec les fichiers réservé : lorsque le compte utilisateur est supprimé alors que les fichiers ne sont pas tous libérés (genre quand on travaille sous un autre compte sur un autre poste le temps d'avoir le sien).
        
        Il y a aussi l'impossibilité de se connecter à très longue distance, (p.ex. se connecter depuis Bucarest -Roumanie- à un serveur situé à Paris) : le protocol de communication ne supporte pas le lag...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.