RE: Question about subversion

> 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.
Received on 2013-06-26 18:40:57 CEST