I don't put daily binaries or intermediate files into the repo - I checkin
binaries only for user-facing (tagged) releases. Thus in our case, the
binaries are a small fraction of the total repo, and I've noticed no perf
change since switching to this policy.
-----Original Message-----
From: Eric Nicholson [mailto:enicholson@gmail.com]
Sent: Thursday, June 14, 2007 9:26 AM
To: Toby Johnson
Cc: users@subversion.tigris.org
Subject: Re: Storing VS binaries in Subversion
On 6/14/07, Toby Johnson <toby@etjohnson.us> wrote:
> In this case I would recommend setting up a separate repo for the binary
> stuff. That way your source code repo remains light, small, and fast,
That's great for using blame if you care about it, but having your
code repo depend on a second repo that needs to be kept in sync is
definitely not light, small, or fast.
Being able to check out a fresh or old copy of the code and build is
much more important than diffing/merging/blaming imho.
The principal of not putting artifacts into SCM probably goes back to
RCS days, and a lot has changed since then. It's still generally good
guidance, but there are cases where it needs to be done. There are
only a couple relatively minor tweaks to subversion that would make it
relatively painless: support actual modification times and
configurable conflict resolution.
The worries about expensive binary deltas, poor performance, and
difficult merging aren't as significant as you might think compared to
the alternatives.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 14 18:37:29 2007