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.reed...@cbeyond.net>
Pour : Marc Davenne <marc.dave...@cramif.cnamts.fr>,
users@subversion.apache.org <users@subversion.apache.org>
Date : 26/06/2013 18:39
From: Marc Davenne [mailto:marc.dave...@cramif.cnamts.fr]
Sent: Wednesday, June 26, 2013 10:37 AM
To: users@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."
******************************************************
