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

early reflections on subversion methodology

From: Thomas Beale <thomas_at_deepthought.com.au>
Date: 2005-07-29 02:25:57 CEST

I have used many CM systems, and have been thinking about whether
subversion supports the kinds of processes needed in real development,
particularly release management. I think that the basic advice of using
the trunk/tags/branches directories is ok, but does not go far enough.
We have so far defined the following in our repositories:

        - TRUNK: mainline current development;
        - BRANCHES: branch developments for new or alternative or test
        - TAGS: named baselines (no changes allowed)
        - RELEASES: release branches, i.e. branches corresponding to
                stable major points in the mainline (trunk) development,
                whose only further allowed changes are bugfixes.

This corresponds more or less to the recommended way in Subversion of
separating mainline development; the only difference is that in our
project, upper-case directory names have been chosen to make the special
status of these directories clear in a check-out structure, and the
RELEASES directory has been added.

"Releases" are really a kind of brnch but one where the allowed types of
change is restricted to bugfixes. "Branches" are usually understood to
be rela development changes.

It would be good if subversion a) supported a standard directory
structure like this, and b) if the tools could hide these directories
(at least on the client side) and instead show them as 'views' - i.e.
the user would be in the mainline view, the branch-xyz view, the
release-0.8 view and so on. I don't think it would be hard to do.

- thomas beale

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 29 02:30:33 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.