1) Git Credentials

On Developers's page, it is indicated:

Enable GIT configuration pointing to the repository ssh://git.tuxfamily.org/gitroot/ostorybook/code.git

However, nothing is said about the git ssh necessary credentials (user/passwd, or key).
I tried my tuxfamily credentials (bodiccea/my-passwd), with no luck. A better explaination on credentials would be welcomed on the page, and different protocols used (https/git/ssh).

2) Git usage (versioning)

After cloning (with no authentication), I had a look on versioning/tagging/branches/etc...

I believe we don't use branches/tags at all, only the "code" (main) branch, and that version numbers are only in source code (build.xml). Am I right ?

It would be nice to give some details on the way we need to work (notions of "stable", "dev", etc..., if any, or if everybody should work on one unique branch, the one offered for download, where fixes and improvement are mixed), or, if we prefer to branch somewhere due to time-consuming changes not suitable for main branch, some guidelines on naming/conventions).

Would it be an option to have branches and/or tags per version ? Like 5.00.02 ?

3) Versioning (more questions)

A few words on version numbers could help too: what mean X.Y.Z in 5.00.02 ?, as change from 5.00.02 to 03 are "minor fixes" (corrections marginales).

4) A stupid question.

When we name a new version (let say i will make 5.00.05), is there in only one place ? I have the feeling it is not. I mean in source, not in git.


Thx,

br.

1) Git accréditation
Ben là je suis sec, je ne m'y connais pas assez pour pouvaoir donner des indications. Jean pourrais peut-être le faire. Pour ma part, je n'ai eu aucun problème du fait que je suis l'initiateur de l'ensemble. J'utilise bien un paramétrage SSH dans Netbeans.

2) Git usage
Là aussi je n'en connais pas assez. Je développe dans master, et Jean fait pareil. Peter Keller, qui avait eu des velléités de participer, avait créé une branche. Mais très honnêtement je ne sais pas trop comment ça marche.

Si tu as une solution à proposer n'hésites pas.

3) Versions
Pour incrémenter la version il faut modifier plusieurs choses:
- dans SbContants.java : valeur de PRODUCT_VERSION
- dans build.xml : valeur de la property sb.version
- dans nbproject/project.properties : si on n'utilise pas Netbeans, valeur de application.title

Peut être que j'en ai oublié.

1) Auth Git

J'ai trouvé. Il faut un compte général sur tuxfamily. Celui de ostorybook ne suffit pas. Dans la page de devs, il faudrait ajouter:
- Qu'il faut d'abord un accès à tuxfamily:
   https://www.tuxfamily.org/en/subscribe
- Qu'il faut suivre les instructions sur (en utilisant le compte global tuxfamily pour le ftp):
   https://faq.tuxfamily.org/GIT/En

2) Branches/Tags

Les branches sont très simples, et utiles. Prends le cas suivant:

Tu as dit que tu travaillais sur le réécriture des exports. Ce sera peut-être long, des jours ou des semaines. Donc tu pourrais créer et travailler sur une branche:
   favdb-5.00.03-the-ultimate-export
Soudain, quelqu'un fait part d'un bug fix urgent. Tu bascules sur la branche de prod (master chez nous), tu fais une branche:
   favdb-master-fix-display
Tu testes ta branche, la merge sur la prod, et rebascules sur ta branche "ultimate-export" pour continuer tes devs.

En général, un tag est utilisé pour spécifier une étape dans une branche. Tous les fichiers seront taggés (ça ne changera jamais, contrairement à une branche, qui évolue en fonction des commits).

Par exemple, sur certains projets (par exemple la branche "linux-next" instable du kernel), ils mettent un tag tous les jours, automatiquement, sur tous les sources reçus, avec la date. C'est un snapshot).
Mais chaque projet/chaque personne utilise les tags comme il veut.
Par exemple, dans ton cas, imagines que tu refasses dans l'ordre l'export HTML puis l'export EPUB. Tu pourrais tagguer quand tu finis la première phase, par exemple.

Avec un tag, tu peux récupérer tous les fichiers dans l'état où ils étaient quand ils one été taggés.
Avec une branche, on peut toujours récupérer la version la plus récente, à moins d'aller tripatouiller dans l'historique.

Exemple: Imagines qu'on inclue dans les distributions un tag avec la version  et la date (comme "5.00.03-build20170120").
Quand quelqu'un trouve un bug, il pourrait indiquer:
  J'ai la version "5.00.01-build20170120".
Donc n'importe quel développeur peut faire un checkout sur "5.00.01-build20170120", pour pouvoir reproduire le bug.

En fait, ce que j'ai dit n'est pas tout à fait exact, les tags n'ont pas de lien direct avec les branches, mais sont souvent utilisés comme ça.
En fait, il faut éviter

3) Version dans le code

Je ne comprends pas bien, oublie. Je vais essayer de comprendre comment ça marche

Donc si j'ai bien tout compris:
a) lorsqu'on travail à la résolution d'un bug on travaille sur master.
b) lorsqu'on veut créer une nouvelle fonctionnalité on se crée une nouvelle branche. Par exemple on décide que la branche porte un nom composé de deux parties, nos initiales, puis un identifiant qu'on se choisi librement. Comme j'ai entrepris la réécriture de l'export, et qu'en parallèle j'écris l'import, je pourrais avoir deux branches: favdb-export et favdb-import.

Jusque là ça va, ça me paraît simple à mettre en oeuvre.

Comment fait-on ensuite pour intégrer une branche. Supposons que j'ai terminé l'import, mais pas l'export, et qu'entre temps le master a évolué suite à la résolution d'un bug. Que faut-il faire pour intégrer ce qui est terminé et validé pour construire une distribution?

À noter que sous Netbeans je n'utilise pas les outils intégré de construction d'une distribution mais bien le script ant piloté par build.xml.

Pas forcément, tu peux créer une branche pour résoudre un bug (mon exemple). Et tu ne travailles pas forcément sur le master, mais peut-être sur la version (le tag'la branche) donnée par celui qui a signalé le bug. Tout dépend de ce qu'on veut faire à ce niveau (demander à quelqu'un d'upgrader sa version pour un bug fix, ou juste mettre à jour sa version).

Tu pourrais effectivement faire deux branches pour l'import/export, si elles n'ont rien à voir. Ou une seule, avec le risque d'interractions.

Imagines qu'on ait des branches par version, et qu'on décide d'en garder 2: Une "stable", qui ne reçoit que des bug-fix ("master") et une "development", par exemple.

Tu poses une question à propos du "merge", c'est exactement comme aujourd'hui, quand tu merges ta version locale avec le master (qui a pu évoluer entre temps, donc il peut y avoir conflit).

Jette un coup d'oeil à:
https://git-scm.com/book/fr/v2/Les-branches-avec-Git-Branches-et-fusions%C2%A0%3A-les-bases
et:
https://git-scm.com/book/fr/v2/Les-branches-avec-Git-Travailler-avec-les-branches
Note: La version en anglais est plus compréhensible.

Peut-être que ce lien est encore mieux:
https://www.atlassian.com/git/tutorials/git-merge

> Pour incrémenter la version il faut modifier plusieurs choses:
> [...]
> - dans nbproject/project.properties : si on n'utilise pas Netbeans, valeur de application.title

nbproject est spécifique à netbeans, non ? Et dans le cas du fichier que tu cites il est de plus lié à ton compte (le path de ton home).
Donc il n'en resterait plus que 2 (sauf oublis). Non ?

Exact.

Et je me demande à quoi sert la version dans le xml... Ce que ça changerait en gros...

Hehehe. Tu vois où je veux en venir.

Oui, oui, viens y.

Bien. Si une version était en un endroit unique, hors source, ça me semblerait plus correct.

Je préfèrerais continuer sur la mailing-list, quand on confirmera qu'elle fonctionne...

br.