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

Re: SVN as CMS

From: David Weintraub <qazwart_at_gmail.com>
Date: Fri, 20 Mar 2009 12:52:50 -0400

There has been a long debate whether or not to store generated
artifacts in your source repository. This isn't just a Subversion
question. It affects all version control systems.

Those who say it is a bad idea say:

* It duplicates information. You already have the files that are
needed to build something. Just rebuild. All you're doing is wasting
space.
* It can lead to lazy CM management. Many organizations store
artifacts because they aren't sure whether or not they can be
regenerated. If you can't regenerate an artifact because your builds
aren't 100% repeatable, you need to solve that issue, and not try to
get around it.
* It can lead to wrong versions being used. For example, I have a C++
header file used to build a particular library. I also include that
C++ header file in my code. Well, there is a new version of the C++
header file, but you're including the old pre-built library that used
the older version: Hilarity ensues.

Those who say it is okay to do say:

* It can save time. Developers don't have to rebuild libraries since
they can simply use the built ones.
* You can make sure everyone uses the same version of the artifact
across the entire project.
* Sure, I believe I can rebuild that artifact to match what we
released, but do I really want to risk a few million in business
because I think I can?

There is some sense in the first two reasons, but then what I really
want to do is treat that artifact as a separate project and as third
party vendor release. Another question is whether the source
repository is actually a good place to store these artifacts. Maven
has a release repository, and we've found that we can use it even in
non-Maven projects.

The big problem in Subversion is that you can't easily remove obsolete
versions of a file. This isn't too bad with straight source code
because deleting intermediate versions won't save you very much since
these files delta very nicely.

However, each version of a binary file takes up quite a bit of room.
For some formats, even a single line change will cause that entire
version to be stored in the repository even if binaries are stored in
delta format. Not being able to remove older obsolete versions of
binary files means that your repository grows at astronomical rates.
Imagine a place where every build is tarred up and stored in your
source repository. (And yes, there are places that do just that).

Therefore, you usually don't store files in binary format in
Subversion. As I've gained more CM experience, I've moved more and
more to the "Don't Store Binaries" side. You're better off storing
built binaries inside a release repository, and then pulling those
files out when needed. As I said, we use Maven for that purpose --
even in our non-Maven projects.

On Fri, Mar 20, 2009 at 9:25 AM, <webpost_at_tigris.org> wrote:
> Hi All,
>
> Just curious to know if it is better idea to use SVN to store generate artifacts on building code. Up to now, i know that we should only use SVN for code and not for any library and artifacts.
>
> Could any one please comment/suggest on this.
>
>
> Thanks
> Pawan
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1364438
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
>

-- 
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1365797
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-20 17:54:12 CET

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.