You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Z W <mp...@gmail.com> on 2013/05/07 05:50:08 UTC
trunk naming best practice question
Hi All
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 branch name
would be while at the same time, we need to perform daily builds for QA
testing.
What's the best practice in use with SVN ?
Thanks
Sincerely
RE: trunk naming best practice question
Posted by Bob Archer <Bo...@amsi.com>.
> 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 branch name
> would be while at the same time, we need to perform daily builds for QA
> testing.
>
> What's the best practice in use with SVN ?
Really, it's about whatever works best for you. We no longer use the name "trunk" on our projects. I guess it works ok if you branch for release... but that wasn't working for us. So, instead of using "trunk" we use the version number... so in our project you would see...
/ProjectName
/v1.0.0
/v1.1.0
/branches
/feature1
/feature2
/tags
Our procedure is to only merge up versions. We build and release from out version path [branch]. Feature branches are created for items that will take more than a day or more than one person is working on it. We fix bugs in the lowest version number that we are still supporting and merge that fix up all the way through our non-released dev version.
This also helps us a lot with our build server, because we had to constantly redefine what was in the "trunk" working copy. This way creating a build project for a new release is much easier... we svn copy the version to the new release version, update the cruise control.net config file that is in the project folder with the new version number, checkout the new version path to the build server, update the ccnet.config root config to point to the new version.
We also generally don't build from feature branches, but we could if we wanted to. However, the build scripts would have to be changed a bit since artifacts are copied to a folder based on version number atm.
Once again, whatever works best for you. Using a trunk that was never the same version from week to week didn't work for us. We also were doing a lot of cyclic merges and needed a better way.
BOb
Re: trunk naming best practice question
Posted by Les Mikesell <le...@gmail.com>.
On Tue, May 7, 2013 at 12:14 AM, Z W <mp...@gmail.com> 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 builds are done manually. However a
tool like jenkins can be configured to automatically do builds (and
perhaps some testing) after every commit on the trunk and it has its
own concept of numbering the builds.
--
Les Mikesell
lesmikesell@gmail.com
Re: trunk naming best practice question
Posted by Z W <mp...@gmail.com>.
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 <gh...@cardinalpath.com>wrote:
> It's common to have
>
> yourrepo
> /branches
> /tags
> /trunk
>
> Each day, tag the trunk (svn copy) as /tags/<Y-m-d> 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 /branches/v2.0alpha.
> I've also seen it work where each developer has his/her own branch -
> /branches/yourname /branches/hername.
>
> Does that give you some ideas?
>
>
>
>
>
> Geoff Hoffman
> Solutions Architect & LAMP Engineer
> phone +1 623.399.4918
> mobile +1 480.231.8323
> web CardinalPath.com <http://goo.gl/TuuiO>
>
>
>
> On Mon, May 6, 2013 at 8:50 PM, Z W <mp...@gmail.com> wrote:
>
>> Hi All
>>
>> 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 branch name
>> would be while at the same time, we need to perform daily builds for QA
>> testing.
>>
>> What's the best practice in use with SVN ?
>>
>> Thanks
>> Sincerely
>>
>
>
> Connect with us on twitter <http://twitter.com/cardinalpath>, google+<https://plus.google.com/108076800625872227241/posts>
> , facebook <http://www.facebook.com/CardinalPath>,** or linkedin<http://www.linkedin.com/company/cardinal-path>
> .
>
> Catch our next training in Washington May 6-10<http://training.cardinalpath.com/google-adwords-analytics/washington/?utm_campaign=cp-cpt&utm_source=sig-referral&utm_medium=email&utm_content=washington-2013-05-06>
> , Los Angeles May 13 - 17<http://training.cardinalpath.com/google-adwords-analytics/los-angeles/?utm_campaign=cp-cpt&utm_source=sig-referral&utm_medium=email&utm_content=losangeles-2013-05-13>
> , Boston May 20 - 24<http://training.cardinalpath.com/google-adwords-analytics/boston/?utm_campaign=cp-cpt&utm_source=sig-referral&utm_medium=email&utm_content=boston-2013-05-20#2013-05-20>
> , Ottawa May 27-31<http://training.cardinalpath.com/google-adwords-analytics/ottawa/?utm_campaign=cp-cpt&utm_source=sig-referral&utm_medium=email&utm_content=ottawa-2013-05-27>
> or See All<http://training.cardinalpath.com/locations/?utm_campaign=cp-s4s&utm_source=cp-email-footer&utm_medium=email&utm_content=see-all>
> .
>
> This email, including any attachments, is for the sole use of the intended
> recipient and may contain confidential information. If you are not the
> intended recipient, please immediately notify us by reply email or by
> telephone, delete this email and destroy any copies. Thank you.
>
>
Re: trunk naming best practice question
Posted by Geoff Hoffman <gh...@cardinalpath.com>.
It's common to have
yourrepo
/branches
/tags
/trunk
Each day, tag the trunk (svn copy) as /tags/<Y-m-d> 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 /branches/v2.0alpha.
I've also seen it work where each developer has his/her own branch -
/branches/yourname /branches/hername.
Does that give you some ideas?
Geoff Hoffman
Solutions Architect & LAMP Engineer
phone +1 623.399.4918
mobile +1 480.231.8323
web CardinalPath.com <http://goo.gl/TuuiO>
On Mon, May 6, 2013 at 8:50 PM, Z W <mp...@gmail.com> wrote:
> Hi All
>
> 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 branch name
> would be while at the same time, we need to perform daily builds for QA
> testing.
>
> What's the best practice in use with SVN ?
>
> Thanks
> Sincerely
>
--
Connect with us on twitter <http://twitter.com/cardinalpath>, google+<https://plus.google.com/108076800625872227241/posts>
, facebook <http://www.facebook.com/CardinalPath>, or linkedin<http://www.linkedin.com/company/cardinal-path>
.
Catch our next training in Washington May 6-10<http://training.cardinalpath.com/google-adwords-analytics/washington/?utm_campaign=cp-cpt&utm_source=sig-referral&utm_medium=email&utm_content=washington-2013-05-06>
, Los Angeles May 13 - 17<http://training.cardinalpath.com/google-adwords-analytics/los-angeles/?utm_campaign=cp-cpt&utm_source=sig-referral&utm_medium=email&utm_content=losangeles-2013-05-13>
, Boston May 20 - 24<http://training.cardinalpath.com/google-adwords-analytics/boston/?utm_campaign=cp-cpt&utm_source=sig-referral&utm_medium=email&utm_content=boston-2013-05-20#2013-05-20>
, Ottawa May 27-31<http://training.cardinalpath.com/google-adwords-analytics/ottawa/?utm_campaign=cp-cpt&utm_source=sig-referral&utm_medium=email&utm_content=ottawa-2013-05-27>
or See All<http://training.cardinalpath.com/locations/?utm_campaign=cp-s4s&utm_source=cp-email-footer&utm_medium=email&utm_content=see-all>
.
This email, including any attachments, is for the sole use of the intended
recipient and may contain confidential information. If you are not the
intended recipient, please immediately notify us by reply email or by
telephone, delete this email and destroy any copies. Thank you.
Re: trunk naming best practice question
Posted by Z W <mp...@gmail.com>.
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 before creating a release branch.
Thanks
On Thu, May 9, 2013 at 10:21 AM, Zé <jo...@gmx.com> wrote:
> 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<http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.branchmerge.commonpatterns>
>
>
> From your description, it sounds like you are trying to implement the
> release branches approach.
>
> --
> Zé
>
Re: trunk naming best practice question
Posted by Zé <jo...@gmx.com>.
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 trying to implement the
release branches approach.
--
Zé