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

Re: early reflections on subversion methodology

From: Jacob Atzen <jacob_at_aub.dk>
Date: 2005-07-29 12:36:26 CEST

On Fri, Jul 29, 2005 at 10:28:42AM +0100, Thomas Beale wrote:
> Sure, and that is of course our advice in our help pages. But it
> doesn't mean that people will understand that these directories are
> special; it is not always easy to educate users who are not familiar
> with CM systems what trunk/tags/branches are about; some expect it to
> be built in, others don't understand at all to begin with.

There's just no substitue for education. If your developer don't
understand it initially they _will_ have to learn. There's no tool in
the world that will do this for you.

You say you have a "releases" branch which only bugfixes should be
committed to. This is only achievable by human means, no machine is able
to determine wether a certain patch is a bugfix or a new feature and
therefore no software will ever be able to enforce this rule.

Unless you can come up with some machine verifiable rules as to what
goes into which directory you're just plain out of luck. Now if on the
other hand you can come up with some machine verifiable rules then
Subversion actually already has a system in place to enforce those rules
through the pre-commit script.

I've heard of people enforcing a rule of "only valid HTML is to be
commited" in Subversion and enforcing this automatically. Which IMHO
goes to show the strength of the current Subversion design.

A partial solution to your problem might be to limit the number of
people with write access to certain parts of the tree. You could grant
everyone write on trunk, make a "bugfixers" group for your release tree
and a "release-engineer" group for the tags tree.

Quite a few people on this list also like to make sure that you can't
update a tagged version. This can be done by pre-commit hooks.

And finally remember that Subversion never forgets - changes can always
be undone.

- Jacob Atzen
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 29 12:38:44 2005

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.