Re: [Phpgedview-talk] SVN Organisation

[Nathan S. H. <nat...@uk...>]

John Finlay wrote:
> Bug fixes and minor features are done on the trunk.  Stable releases from the trunk are packaged once a month.  You can reliably run your production site off of the trunk svn.
>
> Major changes (db schema, major UI or code rewrites, anything requiring GEDCOM import, etc) should be done on the 4.2 branch and will be included in the 4.2 release.  Some features can get started in the 4.2 branch and then later get merged into the trunk when they are considered stable.
>
> The installation instructions have changed in the 4.2 branch when you run off of SVN.  You have to copy config.dist to config.php as part of installation.  This prevents committing your personal configuration settings to the repository.  This is documented in the readme.txt file in the svn.  
>
> --John
>
>
>   

Hi John/developers,

I'm updating some PGVWiki articles about SVN and am trying to write a
section about the repository layout and usage and I'm confused!

Taking a snippet from a chapter in this book
(http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.reposadmin.projects.chooselayout)
".... create three subdirectories beneath that root: |trunk|, meaning
the directory under which the main project development occurs;
|branches|, which is a directory in which to create various named
branches of the main development line; |tags|, which is a collection of
tree snapshots that are created, and perhaps destroyed, but never changed."

While repository structure *can *be anything you could possibly dream
up, the Subversion book's recommended repository layout is to have trunk
as the the "main development line". This layout is effectively the
standard layout and usage, and is what most people would expect:
http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.tour.importing.layout

The current PhpGedView usage of the SVN repository does not follow this
"standard". The "standard" has the following advantages over the current
layout/usage:
1) Everyone works on trunk - always!
    a) Developers needn't know the name the branch on which to work -
ok, developer *should *know anyway
    b) Users only need to checkout code from trunk - no need to document
"you should checkout from branch-xxx" for the latest code
    c) No confusion over what changes in the branch need merging to
trunk as all changes are made to trunk
2) Branches are created for each major/non-bug-fix release and then used
to track bug fixes
    a) If a bug-fix release is made, a new tag is made from the branch
    b) Once support for a particular release is stopped (i.e. no further
bug fixes), the branch can be deleted

The only downside would be that trunk would be more unstable, contain
bugs, contain partly implemented features than it currently does.
However, I'm unsure who the current "stable" trunk is aimed at
addressing!? In my opinion, a version control system is a tool for the
developers to gain maximum productivity through collaborative/organised
development. In this respect, I feel the extra effort in trying to
maintain a "stable" trunk is possibly misleading/misguided and
counter-productive as it is supposed to be used by developers and anyone
wanting to risk using "bleeding edge" code without warranty.
Implementing a more robust release cycle
(http://en.wikipedia.org/wiki/Software_release_life_cycle) that
generates beta releases and release candidates to the "users" via SVN
tags would give clarity to developers, beta testers and users alike, not
to mention being able to document the whole process much more easily.

Anyway, rant over! ;-)
Nath