Re: [Phpgedview-talk] SVN Organisation

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

John Finlay wrote:
>> 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
>>
>>     
>
> Hi Nathan,
>
> Actually it is very common for development work to be done on branches and then merged into the trunk.  In fact I was just looking at another project today that had a similar layout to ours with a "stable" trunk. Of course "stable" is always a relative word.  
>
> In any case the "trunk" is targeted at beta testers and people who want to run their site directly off of the SVN files.  It is also targeted at developers who are doing minor development and bug fixes (sometimes bug fixes are not minor).
>
> It actually works out quite well and simplifies the release strategy because as the beta testers run their sites directly off the svn, we don't have to put out beta releases for every little bug fix.  It also encourages beta testers to fix minor things that they can fix on their own.
>
> Our method simplifies things a lot.  We only have 2 branches a stable branch and a "bleeding edge" branch.  No complicated tag or release structures.  I believe it makes it easier for new users to get involved at a level closer to the developers.
>
> What we have really done is incorporated the beta testers into the SVN.  So the SVN is no longer just a tool for developers, but also a tool for beta testers to quickly and easily get the latest changes.  In return we try to maintain a stable branch that they can rely on.  I feel it has greatly improved the quality control on a very fast paced project.
>
> It also allows for different levels of developers.  There are a few of us who are off experimenting with the bleeding edge stuff, while most of the developers don't want things breaking out from underneath them while they are trying to fix a small bug or make a small UI enhancement.
>
> Overall, it wasn't really planned to be this way.  This is just how our development cycle has evolved over the 5 years since the project was started given the community and users that are involved in the project.  Other projects are likely to evolve differently.  It will likely continue to evolve.
>
> Anyway, I hope that helps.
>
> Thanks,
> --John

Yep - that clears things up. I wasn't trying to advocate one strategy
over another - in the end that's one of the good things about SVN being
so flexible! I was working on a couple of SVN articles this morning -
I'll try to get them finished tomorrow. I'd appreciate it if you could
give them the once-over to check for glaring mistakes!

Cheers
Nath