You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Marc Davenne <ma...@cramif.cnamts.fr> on 2013/06/26 16:36:31 UTC
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
*****************************************************
"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."
******************************************************
Re: Question about subversion
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Marc Davenne,
am Mittwoch, 26. Juni 2013 um 16:36 schrieben Sie:
> Files who should not be on SVN :
>
> files automatically generated
This depends on the files which get automatically generated and their
purpose: It's perfectly valid to version automatically generated class
stubs e.g. for web service clients and servers which get manually
changed afterwards or simply to make sure that one generated version
stays exactly the same and doesn't use new interface names,
automatically generated GUID or whatever those tools out there
implemented.
> files containing specific information about my
> development environment (so properties files for example)
Depends again, it's perfectly valid to version project files of
Eclipse, Visual Studio or whatever you use to assure that every member
of you project use the same settings etc.
> executable files
Depends again?! ;-) There a some projects out there which version
executables, MSI packages and stuff like that and provide direct
download access to their customers using some web application like
ViewVC or WebSVN. If you have an environment were your executables are
not build automatically using some kind of CI, Hudson, Jenkins,
whatever, versioning manually build and once tested applications can
save a lot of time. Besides that, one may be in an situation were one
has only access to third party, pre compiled libraries in which case
there may be no reason to not version those, too.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Question about subversion
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
2013/6/26 Marc Davenne <ma...@cramif.cnamts.fr>:
> 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
"Files that should not be on SVN" is like "food that should not be in
a restaurant". It depends tremendously on your purposes. For example,
a "tag" with locked down binaries, or installable packages, can be
very useful for controlling what binaries are deployed in some
environments. They're not efficient to store, however, and if there is
a lot of "churn" of testable or development binaries, the record of
them can get out of hand.
It can be very efficient for a source tree for building software to
avoid ".o" files, ".a" files, and other geneerated compilation
productions that are not part of hte source code itself. But I know
plenty of Subversion and other source control systems where developers
store the ".jar" files from java, or store critical binaries for full
software deployments.
Perhaps you can describe your use case? That affects best practices profoundly.
RE: Question about subversion
Posted by Bob Archer <Bo...@amsi.com>.
> Hi there. I have a question about subversion.
I think the previous response was quite correct, it mostly all depends.
> 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
Well, Visual Studio generates "designer" files when you edit a web form... we do check those in. We also use compass and I check in the compiled .css file. Of course, I would like to no longer do that and have the build server generate it.
> . files containing specific information about my development environment (so
> properties files for example)
For the most part, yes. We check in the files with a .template in the name and have an init.bat file that copies them out... this way for any initial checkout you at least get reasonable defaults. Our template files also contain the QA connection strings so even a dev without the dbs set up will be able to locally run the ap. (as was said before, it depends).
. executable files
> PS: I am conscious that we can put anything to subversion but I am looking for
> Best practices Thank you so much
Once again, it depends. Many people feel it is a best practice to be able to do a check-out and then build the file without having to do any specific tool installs on your PC. Stuff like NuGet (gems npm whatever) help a lot, since your build can leverage those tools to get the binaries you need to build test. But, sometimes those tools need to be there. For example, we have nant (build tool) and mbunit (test tool) checked in so that the build server doesn't need to have each of those tools installed, and so also we can rev those tools by project rather than having to upgrade all the projects at once.
Also, we have some legacy VB6 code in our project and we use binary compatibility, so we need to DLLs checked in. As much as I don't like it. I am also considering moving these to a new repo and linking with external so that we don't get all the repo bloat... I can just blow away the "binary" repo every year or so.
But, yes, for the most part, that artifacts that your project builds aren't checked in.. but sometimes dependencies and tools are checked in as binaries.
So.... the correct answer, as with almost anything in development is, it depends.
BOb
>
> ________________________________________
> *****************************************************
> "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."
> ******************************************************
Re: Question about subversion
Posted by Les Mikesell <le...@gmail.com>.
On Thu, Jun 27, 2013 at 7:06 AM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>>> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html
>>
>> In summary: this is a way to tell svn to ignore a file (or filename pattern) when looking for files to check-in. Hence the file itself is not in the repo, but your template version(s) is (are).
>>
>>> And what is this script that would trigger on checkout ?
>>
>> That would be (for me, on windows) a simple batch file (that is also checked in) that the user knows to run.
>
> Every software building system has some common tools for this. GNU
> make uses "autoconf" and the resulting ./configure file. X11 used to
> use "xmkmf" and the "Imakefile". Maven, well, maven has it's own
> ideas.....
Another thing to consider is that you may later wish to add automated
build/CI tools like Jenkins which will do unattended builds for you,
possibly in different environments. So it is good to plan for that
from the start, providing a script or batch file that does all the
steps needed to configure for any local differences and perform the
build as part of the project.
--
Les Mikesell
lesmikesell@gmail.com
Re: Question about subversion
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Thu, Jun 27, 2013 at 6:50 AM, Cooke, Mark <ma...@siemens.com> wrote:
> [Please post inline, it makes it easier to follow...]
>
>> -------- Message original --------
>> Sujet: Re: Question about subversion
>> De : Cooke, Mark <ma...@siemens.com>
>> Pour : Marc Davenne <ma...@cramif.cnamts.fr>, Andrew Reedick
>> <An...@cbeyond.net>
>> Copie à : "users@subversion.apache.org" <us...@subversion.apache.org>
>> Date : 27/06/2013 11:40
>>
>> >> -----Original Message-----
>> >> From: Marc Davenne [mailto:marc.davenne@cramif.cnamts.fr]
>> >> Sent: 27 June 2013 10:25
>> >> To: Andrew Reedick
>> >> Cc: users@subversion.apache.org
>> >> Subject: Re: Question about subversion
>> >>
>> >> 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)
>> >
>> > I think it was BOb who gave an answer for that one... What
>> I do is to svn:ignore the file itself, then check in a
>> default version with a different filename (e.g. extra `.tmpl`
>> extension) and provide some sort of `initialisation` script
>> that can be used on fresh checkout to copy the template
>> file(s) to the right name(s) for use.
>> >
>> > For exmaple, I have several .ini files to target different
>> servers (development, test, site1, site2 etc) all checked in
>> with the actual .ini file name ignored. I then copy the
>> right one for what I want to the right name. The different
>> ini fils are then versioned in the repo.
>> >
>> > ~ mark c
>
>> -----Original Message-----
>> From: Marc Davenne [mailto:marc.davenne@cramif.cnamts.fr]
>> Sent: 27 June 2013 11:15
>> To: Cooke, Mark
>> Cc: Andrew Reedick; users@subversion.apache.org
>> Subject: Re: Question about subversion
>>
>> I am not sure I understand it very well. When you say it is ignored,
>> does it mean it is on svn ?
>
> The subversion book explains svn:ignore better than I will:-
>
> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html
>
> In summary: this is a way to tell svn to ignore a file (or filename pattern) when looking for files to check-in. Hence the file itself is not in the repo, but your template version(s) is (are).
>
>> And what is this script that would trigger on checkout ?
>
> That would be (for me, on windows) a simple batch file (that is also checked in) that the user knows to run.
Every software building system has some common tools for this. GNU
make uses "autoconf" and the resulting ./configure file. X11 used to
use "xmkmf" and the "Imakefile". Maven, well, maven has it's own
ideas.....
RE: Question about subversion
Posted by "Cooke, Mark" <ma...@siemens.com>.
[Please post inline, it makes it easier to follow...]
> -------- Message original --------
> Sujet: Re: Question about subversion
> De : Cooke, Mark <ma...@siemens.com>
> Pour : Marc Davenne <ma...@cramif.cnamts.fr>, Andrew Reedick
> <An...@cbeyond.net>
> Copie à : "users@subversion.apache.org" <us...@subversion.apache.org>
> Date : 27/06/2013 11:40
>
> >> -----Original Message-----
> >> From: Marc Davenne [mailto:marc.davenne@cramif.cnamts.fr]
> >> Sent: 27 June 2013 10:25
> >> To: Andrew Reedick
> >> Cc: users@subversion.apache.org
> >> Subject: Re: Question about subversion
> >>
> >> 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)
> >
> > I think it was BOb who gave an answer for that one... What
> I do is to svn:ignore the file itself, then check in a
> default version with a different filename (e.g. extra `.tmpl`
> extension) and provide some sort of `initialisation` script
> that can be used on fresh checkout to copy the template
> file(s) to the right name(s) for use.
> >
> > For exmaple, I have several .ini files to target different
> servers (development, test, site1, site2 etc) all checked in
> with the actual .ini file name ignored. I then copy the
> right one for what I want to the right name. The different
> ini fils are then versioned in the repo.
> >
> > ~ mark c
> -----Original Message-----
> From: Marc Davenne [mailto:marc.davenne@cramif.cnamts.fr]
> Sent: 27 June 2013 11:15
> To: Cooke, Mark
> Cc: Andrew Reedick; users@subversion.apache.org
> Subject: Re: Question about subversion
>
> I am not sure I understand it very well. When you say it is ignored,
> does it mean it is on svn ?
The subversion book explains svn:ignore better than I will:-
http://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html
In summary: this is a way to tell svn to ignore a file (or filename pattern) when looking for files to check-in. Hence the file itself is not in the repo, but your template version(s) is (are).
> And what is this script that would trigger on checkout ?
That would be (for me, on windows) a simple batch file (that is also checked in) that the user knows to run.
> Can you explain it again ?
Does that help?
~ mark c
Re: Question about subversion
Posted by Marc Davenne <ma...@cramif.cnamts.fr>.
I am not sure I understand it very well. When you say it is ignored,
does it mean it is on svn ?
And what is this script that would trigger on checkout ?
Can you explain it again ?
-------- Message original --------
Sujet: Re: Question about subversion
De : Cooke, Mark <ma...@siemens.com>
Pour : Marc Davenne <ma...@cramif.cnamts.fr>, Andrew Reedick
<An...@cbeyond.net>
Copie à : "users@subversion.apache.org" <us...@subversion.apache.org>
Date : 27/06/2013 11:40
>> -----Original Message-----
>> From: Marc Davenne [mailto:marc.davenne@cramif.cnamts.fr]
>> Sent: 27 June 2013 10:25
>> To: Andrew Reedick
>> Cc: users@subversion.apache.org
>> Subject: Re: Question about subversion
>>
>> 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)
>
> I think it was BOb who gave an answer for that one... What I do is to svn:ignore the file itself, then check in a default version with a different filename (e.g. extra `.tmpl` extension) and provide some sort of `initialisation` script that can be used on fresh checkout to copy the template file(s) to the right name(s) for use.
>
> For exmaple, I have several .ini files to target different servers (development, test, site1, site2 etc) all checked in with the actual .ini file name ignored. I then copy the right one for what I want to the right name. The different ini fils are then versioned in the repo.
>
> ~ mark c
>
*****************************************************
"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."
******************************************************
RE: Question about subversion
Posted by "Cooke, Mark" <ma...@siemens.com>.
> -----Original Message-----
> From: Marc Davenne [mailto:marc.davenne@cramif.cnamts.fr]
> Sent: 27 June 2013 10:25
> To: Andrew Reedick
> Cc: users@subversion.apache.org
> Subject: Re: Question about subversion
>
> 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)
I think it was BOb who gave an answer for that one... What I do is to svn:ignore the file itself, then check in a default version with a different filename (e.g. extra `.tmpl` extension) and provide some sort of `initialisation` script that can be used on fresh checkout to copy the template file(s) to the right name(s) for use.
For exmaple, I have several .ini files to target different servers (development, test, site1, site2 etc) all checked in with the actual .ini file name ignored. I then copy the right one for what I want to the right name. The different ini fils are then versioned in the repo.
~ mark c
Re: Question about subversion
Posted by Marc Davenne <ma...@cramif.cnamts.fr>.
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 <An...@cbeyond.net>
Pour : Marc Davenne <ma...@cramif.cnamts.fr>,
users@subversion.apache.org <us...@subversion.apache.org>
Date : 26/06/2013 18:39
>
>> From: Marc Davenne [mailto:marc.davenne@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."
******************************************************
RE: Question about subversion
Posted by Andrew Reedick <An...@cbeyond.net>.
> From: Marc Davenne [mailto:marc.davenne@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.