> 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.

Reply via email to