[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: Gleason, Todd <tgleason_at_impac.com>
Date: Fri, 24 Oct 2008 15:39:49 -0700

> -----Original Message-----
> From: Mark Eichin [mailto:eichin_at_gmail.com]
> Sent: Friday, October 24, 2008 4:26 PM
> To: users_at_subversion.tigris.org
> Subject: Re: Re: Antwort: Re: Problem using subversion on a large
> repository
> Fixing a build break means generating another tag; code generated in a
> build... should get generated just as well the next time, and does
> *not* get committed. Since we disagree on this, clearly it's policy
> rather than implementation :-)

I'd say it's both policy and implementation. You can generate a new tag
if that's what you like--some of us prefer to continue the build on the
same tag rather than make a new one, or delete and re-create the
original one. Some of us also think that saving the generated files
into source control can be beneficial and make data easier to access.
That's all policy. Subversion's implementation gives you the freedom to
choose either policy, though. A different implementation would restrict
my options.

> 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? 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? Do you find it useful to diff
generated files across builds, possibly from several years ago? Our
environments may be inherently different, but if anything is wrong, I
don't think it's how we use source control.

If you need access control on tags, there are a variety of ways to
accommodate it, from a simple pre-commit hook to some form of path-based
authorization (which you would need if you wanted to "lock down" the
project source anyway). In which case, locking down tags is simply one
instance of a larger problem to solve.


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:40:20 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.