Thank you for your answers... all of you
@Andrew
Thank you, the answers you gave were exactly what I thought about (I was
a little bit too general when I asked the question)
- concerning answer number 2 (specific files)
Let's say I have a parameter file with paths for my dev environement.
Typically I would not put it on svn because everybody has different
ones... but how to I version the param file (without it the application
does not work)
-------- Message original --------
Sujet: Re: Question about subversion
De : Andrew Reedick <Andrew.Reedick_at_cbeyond.net>
Pour : Marc Davenne <marc.davenne_at_cramif.cnamts.fr>,
users_at_subversion.apache.org <users_at_subversion.apache.org>
Date : 26/06/2013 18:39
>
>> From: Marc Davenne [mailto:marc.davenne_at_cramif.cnamts.fr]
>> Sent: Wednesday, June 26, 2013 10:37 AM
>> To: users_at_subversion.apache.org
>> Subject: Question about subversion
>>
>> Hi there. I have a question about subversion.
>>
>>
>> I have a theory on what files should not be on SVN and I would like you to tell me if you agree. If you dont agree can you tell me why please. If you see more files that should not be there, tell me and why.
>> Files who should not be on SVN :
>> * files automatically generated
>> * files containing specific information about my development environment (so properties files for example)
>> * executable files
>> PS: I am conscious that we can put anything to subversion but I am looking for Best practices
>> Thank you so much
>
> Wrong question. The correct question is: Do I have what I need to reproduce the build?
>
> Generally speaking:
> * The reasons to avoid checking in generated files are:
> - they can be re-created automatically,
> - checking them in results in duplicate data which
> - takes up space unnecessarily
> - leads to data synchronization issues, i.e. are the generated files I checked in, the same as the files the build generates? And before you say that's a stupid thing to worry about, ask yourself what happens when a checked in generated file is no longer generated by the build? (Someone will have to manually delete the no longer needed generated file from the repo.)
>
> * The reason to avoid checking in dev environment files is because they're different between everyone's work environment and provide no value to the build process.
>
> * The reasons to avoid checking in executable files are:
> - they're big
> - they can't be merged, and/or
> - the executable is generated by the build and thus can be re-built from code if necessary.
>
> However, as others have noted, there are times when you want to check in such files.
>
>
> They're guidelines, not hard and fast rules. Guidelines/Rules exist to support your goals. Your goals are build reproducibility, accurate deployments, and other SCM-ish things that allow your organization to deliver a product that customers will pay money for so that your company can pay your salary. Craft your guidelines/rules in that context and you'll be fine.
>
>
*****************************************************
"Le contenu de ce courriel et ses eventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire.
Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans le présent courriel."
******************************************************
Received on 2013-06-27 11:25:52 CEST