Hi Ze, Bob, Les
Thanks for writing back.
>From your experience, with new features being worked on the trunk, and but
the planning and sizing is poor during developemnt, when it comes to
releasing but the feature is incomplete, how would you turn "on" or "off"
features development at code-freeze be
On 05/07/2013 04:50 AM, Z W wrote:
What's the best practice in use with SVN ?
Maybe this can give you some ideas on how to organize your subversion
repositories:
http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.branchmerge.commonpatterns
From your description, it sounds like you are tr
> For the trunk, what's the common practice to name a version of the trunk?
> We have a trunk and it's not ready for branching.
> We also feel that we need a more specific name for the trunk than what we
> have now called version=trunk.
> However, we can't be specific since we don't know what the b
On Tue, May 7, 2013 at 12:14 AM, Z W wrote:
> Hi Geoff
>
> Thanks for responding.
> So one would not make builds on trunk directly ?
That would depend partly on your tools and workflow. Daily tags are
good for providing a more human-friendly reference name to pass
between developers and QA if bu
Hi Geoff
Thanks for responding.
So one would not make builds on trunk directly ?
Thanks again
On Mon, May 6, 2013 at 9:18 PM, Geoff Hoffman wrote:
> It's common to have
>
> yourrepo
>/branches
>/tags
>/trunk
>
> Each day, tag the trunk (svn copy) as /tags/ and build that in your
>
It's common to have
yourrepo
/branches
/tags
/trunk
Each day, tag the trunk (svn copy) as /tags/ and build that in your
CI tool and push it to your testing server.
Branches are typically feature-related or release-related, e.g.
/branches/feature-name or /branches/development or /branche
