[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: RE: Avoid .svn

From: Leon Zandman <lzandman_at_lode.nl>
Date: 2006-02-08 09:06:03 CET

> It's not really a good practice
> to add your compiled binaries to a repository.

Who told you that? If I release binaries I like to keep them around, so
I know exactly what I shipped to my customers. Ofcourse I don't want to
keep every binary on each commit, so I don't add the build output
locations to my repository. But I do manually add binaries that were
created from a tag and add them to that tag. I also add the debug symbol
and map files, which may be essential if you want to solve customer

If you don't store your binaries that and you receive an error report
what are you gonna do? If you haven't stored the binaries you have to
recompile them from the tag. But this might result in totally different
(unusable) files, because over time your compiler might have been
updated/patched etc.

Actually I often add all files related to my projects in a repository,
even compilers and other tools. This allows me to re-create exact
working environments.

> I use VS setup
> projects and never have a problem, tho. Checking out a
> repository with _svn directories will avoid the VS 2002/3
> problem with .svn directories, tho.

That problem is only relevant when using ASP.NET projects in Visual
Studio (and can be easily solved by converting web projects to normal
cts). It has nothing to do with the original posters question. The
problem isn't the naming of the ".svn" folder! It's the fact that Visual
Studio actually deletes the "Debug" and "Release" folders and
re-creating them during a build. In the process the ".svn" (or the
"_svn" folder) get deleted too, which results in a corrupt working copy.
Please read before you post...


Leon Zandman

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 8 09:07:00 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.