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

Standardised Repository Schema

From: Kim Lester <kim_at_dfusion.com.au>
Date: 2003-04-22 19:16:35 CEST

Hi Jeff et al,

        These are myt 1st houghts about the Live,Staging,Devel layout.
        Actually Jeff's email tgurned out to be just an excuse to discuss
        something else I thought worth opening up.

        First of all I understand Jeff's need, for example we have a web
        content authoring system set up with physical dirs and boxes
        with exactly those categories (staging is even called the same...)

        I think the main issue is one of separation. It is nice/good to have
        development work, which is often 'incomplete' when checked in,
        separated from work which is say Beta, and that too separated
        from release quality code/data.

        I'll summarise what I think are the key requirements leading
        to your layout. I've been toying with similar ideas.

        Requirements:
                * Separate dev, test, and release so that no pollution occurs.
                * Permit intermediate developer/test checkins whilst nominally
                        maintaining the reference (trunk) version as monotonically
                        increasing in what I'll arbitrarily call quality.
        'Issues':
                * Trunk, Branches,Tags provide mechanism not policy.

        There are many ways of managing development deltas.
        Two that I'd like to concentrate on are:
                A) Main line development commits with tags to (older) good versions
                B) Development in branches with merges to mainline when passable.

        A) Main line (trunk) developer commits
        ----------------------------------------------------
        This means developers all checkin to the trunk. Branches don't really
        get used for development work in this scenario.
        A known good version of the trunk must be tagged so that a stable
version
        is always ready for checkout by another developer (or worse still a
manager :-))

        Pros:
                * Conceptually simple
                * Works for 1-2 developers on a small project
                * Next person to checkout gets bleeding edge by default
                        (ie code divergence is not a problem, broken bones may be.. :-))

        Cons:
                * Main line will at some point contain good and broken code intermixed
                on its timeline.
                * Must remember (or automate) tagging of most recent known good
versions

        B) Development done in branches
        -----------------------------------------------
        Here the mainline head (always a "good" copy) is checked out into a
branch
        development is done in the branch. The developer can freely checkin
        broken copies each night to save the dreaded:
                tar cvf mondaynite.good.final2.tar project
        (Hands up everyone who is pretending they've never done that!)

        Anyhow once the developer has finished, and has a supposedly improved
        version they then merge it into the trunk (maybe after a little
testing..yes?)

        Pros:
                * Better tracking of changes (a new branch should be created for
                        each logical change)
                * Mainline is potentially much less polluted as merging can be
controlled

        Cons:
                * Conceptually a little harder.
                * Requires more developer rigour or, lets be realistic, wrapper code

        The possibility of using two mainlines also exists, where one mainline
        is the official release (and patches) and the second mainline is the
alpha
        development tree. However I would suggest at least conceptually that
        it is just as simple to have one mainline and a tag/branch for a
release
        version. I think it reasonable to say that in most cases there is one
active
        line and the others are mostly patches to released versions. Therefore
        a single trunk for major development and branches for maintenance
        works well in all the cases I've had to deal with.

        I suggest that for any non-trivial project B) is preferable, and it is
non-trivial
        cases that are the most interesting and in most need of good version
control.
        I'll deal with B) from now on.

        The point about one logical change per branch has many implications.
        Note that there is no reason why one couldn't just checkout a branch
and
        use it for all time, merging as one goes along to keep it and the
trunk in sync.
        I think is is needlessly complex (refer repeated merges, keeping track
of branch
        deltas since last merge etc)
        Instead I would suggest that (and I'm not claiming this to be
original) a branch
        is created for each change (or set of related changes).
        Indeed when a bug tracking system is in use we have a very convenient
        branch naming scheme - the bug/issue#.

        So to fix issue 1234 we create branches/branch-1234

        [ Aside:
        For those encumbered with management who delight in interfering with
        developers and changing the bug tracking system every time a new
        sales droid comes along - or worse those who have several incompatible
CRMs
        out there (If you don't understand - believe me ignorance is bliss on
this one)
        you might like to prefix the 1234 with an bug/CRM/issue system acronym
-eg
        branches/branch-ABC1234 or just branches/ABC1234
        because the change of getting a globally unique
        number out of each system is ...)
        ]

        Now all our changes for issue 1234 get committed to branch-ABC1234
        so we have a nice history of the fixes for issue 1234.
        It also means we can work on several distinct issues at once in our
home dirs
        simply by having the working dirs named after the branch/issue.

        [I know there are cases with humungous projects where it is impractical
        to check out multiple copies, but in these cases I'd suggest one isn't
changing
        EVERY file, so maybe construct a branch of a subtree or a composite of
those
        bits which will be changed. More thought/discussion required here.]

        When it comes time to integrate one or more changes into the main line
        these can be managed by a person or a script. if you have the people
good.
        It all adds to the process workflow paradigm without unduly impinging
on
        developer efficiency. Even automated integration phases are good,
because
        branches which don't build can be easily rejected without affecting
others.

          Ok well this is getting to be a bit long so I'll come back quickly to
Jeff's
        suggestion of Dev/Test/Release.

        I think that whilst at first is make a clean distinction between the
areas,
        it adds somewhat to the migration management tasks and one ends
        up with 3 tag areas, 3 branch areas etc which _might_ be harder to
        manager down the track.

        The need for separation is there however, and I think it can be
        more simply and scalably achieved by going for a naming scheme
        within the single tag and branch directories - ie inverting the
problem.

        So we'd end up with:

        project/tags/RELEASE-x.y.z
        project/tags/DEV-issue# # note may not need DEV tags
        project/tags/TEST-x.y.z

        and the same for branches:
        project/branches/RELEASE-x.y.z # note prob don't need RELEASE branches
        project/branches/DEV-issue#
        project/branches/TEST-x.y.z # note prob. don't need TEST branches

        where x.y.z is a suitable version number etc

        In practice I think only 3 of the above 6 cases would actually be
needed.
        Releases should only be TAGS not branches (one could argue about
patches here)
        DEV are really branches not tags.
        Admittedly with SVN ithis is a moot point, but it is important to get
one's conceptual
        model correct. I'd suggest "releases" are points in time not deltas so
they are tags
        never branches.

        If desirable one could make the RELEASE etc into a subdir rather than
just a prefix
        ie project/tags/RELEASE/....

        A benefit of this general solution rather than /Live/Trunk etc
        is that we can easily add extra tag schemes as required (eg
RELEASE-BETA
        or PILOT etc when the world becomes more complex)

        By creating a template naming convention for tags and branches
        (which still reamains flexible) we create a helpful policy based on a
powerful
        underlying mechanism (SVN)

        A final thought. Using well defined tag/branch names makes automation
        (my pet topic and something I'm working on for SVN) so much simpler.

        Thanks for reading this far :-)

        regards
                kim

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 22 19:17:45 2003

This is an archived mail posted to the Subversion Dev mailing list.