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

Re: Re: Re: Antwort: Re: Problem using subversion on a large repository

From: Mark Eichin <eichin_at_gmail.com>
Date: Fri, 24 Oct 2008 18:56:22 -0400

On Fri, Oct 24, 2008 at 6:39 PM, Gleason, Todd <tgleason_at_impac.com> wrote:
>> In the environments where I use svn (granted, these are former CVS
>> environments) the response to your use cases is "you're doing it
>> wrong" :-) Fortunately, there's a (somewhat crude) way to get our
>> policy, by matching on tags in a pre-commit hook and rejecting the
>> commits. (We'd be happy with more "first class" support for this
>> policy, but there are more important things...)
> In your environments, do you generate human-readable files from binary
> files?

No examples come to mind - if it's not human-readable, it's not
source. (We do occasionally have need to commit binaries, but
although svn handles that better than cvs, it's still mostly
"snapshotting" rather than version control...)

> Is disk space too limited to keep the full output from every
> build under the sun, hence dictating that you'd like to leverage a
> system where files are stored as diffs?

build trees are inherently something to be discarded, thus the
importance of versioning the inputs properly... if you know up front
that you never keep them, you build processes around that and end up
not needing to.

> Do you find it useful to diff
> generated files across builds, possibly from several years ago?

Generally not. We diff source across years, rather often;
occasionally we pull tools out of archives and regenerate things, but
we have enough information recorded that we can - it's quite rare that
it's useful (more often it's enough to reproduce the behaviour of the
old product by actually running it, then looking at source for

> Our
> environments may be inherently different, but if anything is wrong, I
> don't think it's how we use source control.

Sounds like they're *very* different, actually...

> If you need access control on tags

Perhaps I wasn't clear - we don't *need* access control on tags -
access control on tags is simply the only way we have within svn to
make tags actually *be* tags, ie. immutable create-only objects. In
this model, modification of a tag is rewriting history, which can
happen by accident; much of the reason to use version control is to
prevent accidents...

_Mark_ <eichin_at_thok.org> <eichin_at_gmail.com>
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-10-25 00:56:57 CEST

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.