Hi Emerson
I'm not really sure I understand completely. I think that sounds like a
mixture of the two approaches, and one that ends up having more branches
and merging to do than the 'pure' feature-branch strategy, where you
only have one production branch (TRUNK) and then one branch per change.
When that change is ready for releasing to production, I'd merge it into
TRUNK and release that. I don't see a need for a release branch: the
stability of the production code is never compromised, and the
developers are free to carry on working on their respective branch(es).
If I've understood incorrectly, could you explain in more detail please?
Richard
-----Original Message-----
From: emerson cargnin [mailto:echofloripa.yell@gmail.com]
Sent: Wednesday, November 08, 2006 1:41 PM
To: Gundersen, Richard
Subject: Re: RE: Branching strategy - Feature vs Release
What about having a production branch, with the changes made on
release branches (bug fixes) and merging the changes at same time when
the trunk is released and copied to its release branch?
emerson
On 08/11/06, Gundersen, Richard <Richard.Gundersen@london-scottish.com>
wrote:
> Actually, thinking about it a bit more...
>
> While this is an inconvenience, the information is still there for
those
> who want it, it's just a bit harder to get at in one go. And I think I
> would be prepared to put up with this if it means I have a stable
trunk,
> and separate changes (or bundles of changes) on their own branches,
and
> all the benefits that come with this strategy.
>
> What do you think?
>
> -----Original Message-----
> From: Gundersen, Richard
[mailto:Richard.Gundersen@london-scottish.com]
> Sent: Wednesday, November 08, 2006 1:16 PM
> To: Duncan Murdoch
> Cc: users@subversion.tigris.org
> Subject: RE: Branching strategy - Feature vs Release
>
> Ah, I see what you mean. I should try things out myself before
> disagreeing :)
>
> I think this is a problem with SVN rather than either strategy though,
> don't you think? Both approaches will suffer from this lacking feature
> in SVN? Admittedly, the log will be more complete if all development
is
> done on one trunk, but there will still be gaps (admittedly they will
be
> smaller though)
>
> -Richard
>
> -----Original Message-----
> From: Duncan Murdoch [mailto:murdoch@stats.uwo.ca]
> Sent: Wednesday, November 08, 2006 1:03 PM
> To: Gundersen, Richard
> Cc: users@subversion.tigris.org
> Subject: Re: Branching strategy - Feature vs Release
>
> On 11/8/2006 7:34 AM, Gundersen, Richard wrote:
> > Hi Duncan
> >
> > Thanks for the reply, but you do have the full history of a file,
even
> > if it was branched. Every time a change is made to that file,
> regardless
> > of which branch the change was made on, you get a log message (as
long
> > as the developer writes one).
> >
> > When you eventually merge it, you'd have one additional log message
> > saying something like "Merged from my_branch", as well as all the
> > others.
>
> I agree the log messages aren't lost, but they aren't attached to the
> file on the trunk, they are out on the branch. So if you ask for a
log
> of a file on the trunk you won't see them. You need to read the trunk
> log message to find out where the merge came from, and then go there,
> and read those messages.
>
> This may eventually change if svn gets better merge support, but right
> now, the svn log can't tell the difference between a merge and any
other
>
> change on the trunk. There's no way for the client to automatically
> link the branch log message to the trunk file.
>
> Duncan Murdoch
>
>
>
>
> >
> > -Richard
> >
> > -----Original Message-----
> > From: Duncan Murdoch [mailto:murdoch@stats.uwo.ca]
> > Sent: Wednesday, November 08, 2006 12:00 PM
> > To: Gundersen, Richard
> > Cc: users@subversion.tigris.org
> > Subject: Re: Branching strategy - Feature vs Release
> >
> > On 11/8/2006 5:06 AM, Gundersen, Richard wrote:
> >> Hi All
> >>
> >>
> >>
> >> We're having a big debate where I work over whether or not to use
the
> >> "release" based branching strategy, or the "feature" based way.
> >>
> >>
> >>
> >> I've always worked with the latter. These are the reasons why:
> >>
> >>
> >>
> >> 1) Trunk is always stable. This always mimics exactly what's
in
> >> production.
> >>
> >> 2) I do all new work on a branch (whether it's a small
> >> experimental change or a new release which is essentially a
> collection
> >> of new features). This to me has the following additional
advantages
> >>
> >> a. My new changes don't affect the production codebase
> >>
> >> b. When the customer who requested change X wants it to go
> live,
> > I
> >> can merge it in to the trunk (because its own isolated branch), and
> >> release only that change (plus whatever was in trunk originally). I
> > then
> >> commit it, tag it, and hey presto, trunk still mimics production
> >> exactly. With the release based approach, with everyone committing
> >> different changes to the trunk, when a customer wants change X to
go
> >> live, I have to tell him that it can go live, but I have to tell
> > another
> >> customer that because I have to release X, his change Y must also
go
> >> live too. This situation might never occur with systems that have a
> >> simple release lifecycle, but when you're dealing with large
systems
> >> with different sets of customers (especially if they have different
> >> legal requirements, or they are in different countries) I think
this
> > is
> >> really important.
> >>
> >>
> >>
> >> The arguments against this approach are often:
> >>
> >>
> >>
> >> 1) Merging is hard. I don't like it
> >>
> >> a. Well, in my experience with Subversion and CVS, merging is
> >> actually quite easy. I might have a few conflicts to resolve every
> now
> >> and again, but they are usually pretty easy to iron out, especially
> if
> > I
> >> keep my branch up to date with the trunk (which might have had some
> > bug
> >> fixes done to it over time)
> >>
> >> 2) Keeping track of lots of branches is hard.
> >>
> >> a. Not really. If I use a good naming convention, a handful
of
> >> branches are easy enough to keep track of. It's not as if I'm going
> to
> >> have hundreds of branches to worry about, in reality
> >>
> >> 3) We have release branches so you know exactly whats on a
> >> production server
> >>
> >> a. So does this approach - whatever is on the trunk is in
> >> production. And, a release branch by definition changes over time
> > (until
> >> it's tagged as final after which there will still be an element of
> >> merging involved to get it in sync with the development branch
(trunk
> > in
> >> this case)).
> >>
> >>
> >>
> >> I can see why people would favour the release branch strategy,
> because
> >> it 'sounds' much simpler, but I think the benefits of the feature
> > based
> >> approach far outweigh the negatives. I expect a lot of people to
> >> disagree with me, but it's a good debate and I'd welcome any
> comments.
> >
> > One other argument in favour of doing development on the trunk and
> > release from branches: If you look at the log for a file, you see
the
>
> > history of changes, not a series of "lots of changes merged from foo
> > branch" messages.
> >
> > Duncan Murdoch
> >
> >>
> >>
> >>
> >> Thanks
> >>
> >>
> >>
> >> Richard
> >>
> >>
> >>
> >>
> >>
> >>
> >> *** Disclaimer ***
> >>
> >> This electronic communication is confidential and for the exclusive
> > use of the addressee. It may contain private and confidential
> > information. The information, attachments and opinions contained in
> this
> > E-mail are those of its author only and do not necessarily represent
> > those of London Scottish Bank PLC or any other members of the London
> > Scottish Group.
> >>
> >> If you are not the intended addressee, you are prohibited from any
> > disclosure, distribution or further copying or use of this
> communication
> > or the information in it or taking any action in reliance on it. If
> you
> > have received this communication in error please notify the
> Information
> > Security Manager at ISM@London-Scottish.com as soon as possible and
> > delete the message from all places in your computer where it is
> stored.
> >>
> >> We utilise virus scanning software but we cannot guarantee the
> > security of electronic communications and you are advised to check
any
> > attachments for viruses. We do not accept liability for any loss
> > resulting from any corruption or alteration of data or importation
of
> > any virus as a result of receiving this electronic communication.
> >>
> >> Replies to this E-mail may be monitored for operational or business
> > reasons. London Scottish Bank PLC is regulated by the Financial
> Services
> > Authority.
> >>
> ______________________________________________________________________
> >> This email has been scanned by the MessageLabs Email Security
System.
> >
> >
> >
______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security
System.
> > For more information please visit http://www.messagelabs.com/email
> >
______________________________________________________________________
> >
> > *** Disclaimer ***
> >
> > This electronic communication is confidential and for the exclusive
> use of the addressee. It may contain private and confidential
> information. The information, attachments and opinions contained in
this
> E-mail are those of its author only and do not necessarily represent
> those of London Scottish Bank PLC or any other members of the London
> Scottish Group.
> >
> > If you are not the intended addressee, you are prohibited from any
> disclosure, distribution or further copying or use of this
communication
> or the information in it or taking any action in reliance on it. If
you
> have received this communication in error please notify the
Information
> Security Manager at ISM@London-Scottish.com as soon as possible and
> delete the message from all places in your computer where it is
stored.
> >
> > We utilise virus scanning software but we cannot guarantee the
> security of electronic communications and you are advised to check any
> attachments for viruses. We do not accept liability for any loss
> resulting from any corruption or alteration of data or importation of
> any virus as a result of receiving this electronic communication.
> >
> > Replies to this E-mail may be monitored for operational or business
> reasons. London Scottish Bank PLC is regulated by the Financial
Services
> Authority.
> >
______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security
System.
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> *** Disclaimer ***
>
> This electronic communication is confidential and for the exclusive
use
> of the addressee. It may contain private and confidential information.
> The information, attachments and opinions contained in this E-mail are
> those of its author only and do not necessarily represent those of
> London Scottish Bank PLC or any other members of the London Scottish
> Group.
>
> If you are not the intended addressee, you are prohibited from any
> disclosure, distribution or further copying or use of this
communication
> or the information in it or taking any action in reliance on it. If
you
> have received this communication in error please notify the
Information
> Security Manager at ISM@London-Scottish.com as soon as possible and
> delete the message from all places in your computer where it is
stored.
>
> We utilise virus scanning software but we cannot guarantee the
security
> of electronic communications and you are advised to check any
> attachments for viruses. We do not accept liability for any loss
> resulting from any corruption or alteration of data or importation of
> any virus as a result of receiving this electronic communication.
>
> Replies to this E-mail may be monitored for operational or business
> reasons. London Scottish Bank PLC is regulated by the Financial
Services
> Authority.
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> *** Disclaimer ***
>
> This electronic communication is confidential and for the exclusive
use of the addressee. It may contain private and confidential
information. The information, attachments and opinions contained in this
E-mail are those of its author only and do not necessarily represent
those of London Scottish Bank PLC or any other members of the London
Scottish Group.
>
> If you are not the intended addressee, you are prohibited from any
disclosure, distribution or further copying or use of this communication
or the information in it or taking any action in reliance on it. If you
have received this communication in error please notify the Information
Security Manager at ISM@London-Scottish.com as soon as possible and
delete the message from all places in your computer where it is stored.
>
> We utilise virus scanning software but we cannot guarantee the
security of electronic communications and you are advised to check any
attachments for viruses. We do not accept liability for any loss
resulting from any corruption or alteration of data or importation of
any virus as a result of receiving this electronic communication.
>
> Replies to this E-mail may be monitored for operational or business
reasons. London Scottish Bank PLC is regulated by the Financial Services
Authority.
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
*** Disclaimer ***
This electronic communication is confidential and for the exclusive use of the addressee. It may contain private and confidential information. The information, attachments and opinions contained in this E-mail are those of its author only and do not necessarily represent those of London Scottish Bank PLC or any other members of the London Scottish Group.
If you are not the intended addressee, you are prohibited from any disclosure, distribution or further copying or use of this communication or the information in it or taking any action in reliance on it. If you have received this communication in error please notify the Information Security Manager at ISM@London-Scottish.com as soon as possible and delete the message from all places in your computer where it is stored.
We utilise virus scanning software but we cannot guarantee the security of electronic communications and you are advised to check any attachments for viruses. We do not accept liability for any loss resulting from any corruption or alteration of data or importation of any virus as a result of receiving this electronic communication.
Replies to this E-mail may be monitored for operational or business reasons. London Scottish Bank PLC is regulated by the Financial Services Authority.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 8 15:17:12 2006