You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Rob Wilkerson <r....@gmail.com> on 2006/07/11 18:18:43 UTC
Branching/Merging Best Practices
I'm working on establishing a process for using Subversion once we
have completed a conversion from VSS and I'd like to get some advice
on how/when to merge back into the trunk. I'm not going to carry any
legacy history over from VSS. Instead, I'm going to leave it where it
is and start fresh with Subversion using the most recently released
code base for the product.
Re: Branching/Merging Best Practices
Posted by Ashutosh Mohanty <as...@syncad.com>.
yes, this is the right thing to get going, either " tag "or "branch " they
dont have any difference only for human suitability,
Ashutosh
----- Original Message -----
From: "Marc Haisenko" <ha...@comdasys.com>
To: <us...@subversion.tigris.org>
Cc: "Rob Wilkerson" <r....@gmail.com>
Sent: Wednesday, July 12, 2006 4:18 PM
Subject: Re: Branching/Merging Best Practices
> On Wednesday 12 July 2006 12:36, Rob Wilkerson wrote:
> > Sorry, I accidentally sent this directly to Nick. Hopefully this time
> > it will go to the entire list.
> >
> > ==================================
> >
> > Thanks, Nick. That makes a lot of sense and is the exact opposite of
> > how I was thinking of things. I'm glad I asked. If I understand
> > correctly, then at any given time there may be development actively
> > ongoing against the trunk and one or more branches. For some reason I
> > was thinking that the trunk was sacred. I have no idea why.
>
> There are a few ways of working with branches. One is "trunk is dirty"
which
> means that the trunk always contains the latest changes and you branch off
> stable branches from it.
>
> Another is "trunk is stable" which means that development takes places in
> branches and you then merge your stuff to trunk when you think it's
stable.
> In this type trunk IS sacred ;-)
>
> You can do both with SubVersion, pick the one that suits you best.
>
> We do it like Nick here, and only do branches for bigger changes where we
know
> it'll take a few commits until stuff will work and in the meantime our
system
> would be broken. By making a "working branch" we can break as much as we
want
> without interfering with the developers working on trunk. But it's not
> necessarily the best development method for you as well, you need to
decide
> for yourself.
>
> > Let me ask one follow up question to see how you'd handle the scenario
> > I'm about to face...once I import my current stable version and create
> > a branch for that version my trunk will look exactly the same as that
> > branch. For the next version, though, the code base will be entirely
> > reorganized - new folder structure, pathing, etc. Should I do that
> > work directly on the trunk or is that something so massive that it's
> > better handled on a branch? How are major overhauls like this handled
> > in other shops?
>
> I've done things like this in trunk so far, but just because I was the
only
> one to do such things and was the only developer working that day (we were
> small back then) so I knew I wouldn't interfere with others.
>
> Doing a branch for such things may be a good idea, but be prepared for
some
> conflicts when merging if others changed stuff on trunk while you
reorganized
> in your branch. Hard to say for me which is the best method for you...
>
> C'ya,
> Marc
>
> --
> Marc Haisenko
> Comdasys AG
>
> Rüdesheimer Straße 7
> D-80686 München
> Tel: +49 (0)89 - 548 43 33 0
> Fax: +49 (0)89 - 548 43 33 29
> e-mail: haisenko@comdasys.com
> http://www.comdasys.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branching/Merging Best Practices
Posted by Marc Haisenko <ha...@comdasys.com>.
On Wednesday 12 July 2006 12:36, Rob Wilkerson wrote:
> Sorry, I accidentally sent this directly to Nick. Hopefully this time
> it will go to the entire list.
>
> ==================================
>
> Thanks, Nick. That makes a lot of sense and is the exact opposite of
> how I was thinking of things. I'm glad I asked. If I understand
> correctly, then at any given time there may be development actively
> ongoing against the trunk and one or more branches. For some reason I
> was thinking that the trunk was sacred. I have no idea why.
There are a few ways of working with branches. One is "trunk is dirty" which
means that the trunk always contains the latest changes and you branch off
stable branches from it.
Another is "trunk is stable" which means that development takes places in
branches and you then merge your stuff to trunk when you think it's stable.
In this type trunk IS sacred ;-)
You can do both with SubVersion, pick the one that suits you best.
We do it like Nick here, and only do branches for bigger changes where we know
it'll take a few commits until stuff will work and in the meantime our system
would be broken. By making a "working branch" we can break as much as we want
without interfering with the developers working on trunk. But it's not
necessarily the best development method for you as well, you need to decide
for yourself.
> Let me ask one follow up question to see how you'd handle the scenario
> I'm about to face...once I import my current stable version and create
> a branch for that version my trunk will look exactly the same as that
> branch. For the next version, though, the code base will be entirely
> reorganized - new folder structure, pathing, etc. Should I do that
> work directly on the trunk or is that something so massive that it's
> better handled on a branch? How are major overhauls like this handled
> in other shops?
I've done things like this in trunk so far, but just because I was the only
one to do such things and was the only developer working that day (we were
small back then) so I knew I wouldn't interfere with others.
Doing a branch for such things may be a good idea, but be prepared for some
conflicts when merging if others changed stuff on trunk while you reorganized
in your branch. Hard to say for me which is the best method for you...
C'ya,
Marc
--
Marc Haisenko
Comdasys AG
Rüdesheimer Straße 7
D-80686 München
Tel: +49 (0)89 - 548 43 33 0
Fax: +49 (0)89 - 548 43 33 29
e-mail: haisenko@comdasys.com
http://www.comdasys.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branching/Merging Best Practices
Posted by Rob Wilkerson <r....@gmail.com>.
Sorry, I accidentally sent this directly to Nick. Hopefully this time
it will go to the entire list.
==================================
Thanks, Nick. That makes a lot of sense and is the exact opposite of
how I was thinking of things. I'm glad I asked. If I understand
correctly, then at any given time there may be development actively
ongoing against the trunk and one or more branches. For some reason I
was thinking that the trunk was sacred. I have no idea why.
Let me ask one follow up question to see how you'd handle the scenario
I'm about to face...once I import my current stable version and create
a branch for that version my trunk will look exactly the same as that
branch. For the next version, though, the code base will be entirely
reorganized - new folder structure, pathing, etc. Should I do that
work directly on the trunk or is that something so massive that it's
better handled on a branch? How are major overhauls like this handled
in other shops?
Thanks again for you thoughts.
On 7/12/06, Nick Thompson <ni...@agere.com> wrote:
> On Tuesday 11 July 2006 19:18, Rob Wilkerson wrote:
> > I'm working on establishing a process for using Subversion once we
> > have completed a conversion from VSS and I'd like to get some
> > advice on how/when to merge back into the trunk. I'm not going to
> > carry any legacy history over from VSS. Instead, I'm going to
> > leave it where it is and start fresh with Subversion using the most
> > recently released code base for the product.
> >
> > From the point of view of an inexperience Subversion user, the most
> > intuitive process seems to be this:
> >
> > 1. import latest code into the trunk of the product repository
> > 2. create a branch to begin developing the next version
> > 3. create another branch to provide a maintenance release
> >
> > So now I have 2 branches from the same trunk and I have several
> > questions:
> >
> > 1. After development of the maintenance release has been completed
> > and tested, is it a good practice (I'm assuming it is) to merge
> > that "fixed" code into the branch created for the next version of
> > the product?
> > 2. Since it is a maintenance release of the code that makes up the
> > trunk, should I merge that maintenance release code back into the
> > trunk when it's released?
> > 3. The product, like many others, has major, minor and maintenance
> > releases. Should any or all of these be merged back into the trunk
> > or should branches be left as branches? If they should be merged
> > back into the trunk then when is this usually done?
> >
> > I guess what I'm trying to figure out is the best workflow to use
> > in the development lifecycle of a product. Any guidance would be
> > much appreciated. High level process flow suggestions would help
> > me tremendously.
>
> The usual flow of things is to have your main development on trunk and
> to branch out for release and subsequent maintenance of the release.
> (You might also use branches for big changes that might break the
> code after a commit, but where a commit is non the less required for
> some reason - sharing, milestone capture, module testing. These
> "feature branches" would be merged back to the trunk when the feature
> is complete.)
>
> Applying this to your situation, you would import your original code
> release into trunk and immediately create a branch for maintaining
> that release. Development of the next version would then proceed on
> trunk, until you are ready for the next release. At that point you
> would branch a new release/maintenance branch. Development for the
> subsequent version then proceeds on trunk again.
>
> Merges are simply made on an as required basis. Your process will need
> to include a review board to decide if each fix applied to a
> maintenance branch should also be applied to trunk, in which case it
> is merged or manually duplicated - a maintenance fix may not be able
> to use an optimal solution for example. Same for fixes on the trunk,
> do they need to be back ported to any maintenance branches? Again,
> merges may do the job here, but since this is a back port, the fix
> may have to take a different form.
>
> Anyway, that's more or less what we do, but I don't think I could
> claim it as Original Work. :-)
>
> Good luck.
> --
> > Nick Thompson
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Rob Wilkerson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branching/Merging Best Practices
Posted by Nick Thompson <ni...@agere.com>.
On Wednesday 12 July 2006 11:35, you wrote:
> Thanks, Nick. That makes a lot of sense and is the exact opposite
> of how I was thinking of things. I'm glad I asked. If I
> understand correctly, then at any given time there may be
> development actively ongoing against the trunk and one or more
> branches. For some reason I was thinking that the trunk was
> sacred. I have no idea why.
>
> Let me ask one follow up question to see how you'd handle the
> scenario I'm about to face...once I import my current stable
> version and create a branch for that version my trunk will look
> exactly the same as that branch. For the next version, though, the
> code base will be entirely reorganized - new folder structure,
> pathing, etc. Should I do that work directly on the trunk or is
> that something so massive that it's better handled on a branch?
> How are major overhauls like this handled in other shops?
>
> Thanks again for you thoughts.
Hi Rob,
That is a tough one and I'm not sure I have a good answer.
Reorganizing the directory structure is something that can be done in
Subversion, but appears to cause all sorts of merge/update issues -
something that often comes up on the list. Proper support for file
moves/renames is being worked on I believe and should help later.
My conclusion from that would be, that even though I might like to do
such a change on a branch, I think I would feel safer doing it on the
trunk, while nobody else is working on the project :-( This could be
very difficult to achieve.
I think I might even consider doing it in a new project, possibly in
the same repo, on a different trunk and then have a second phase to
copy across developer changes from the original trunk.
HTH,
Nick.
>
> On 7/12/06, Nick Thompson <ni...@agere.com> wrote:
> > On Tuesday 11 July 2006 19:18, Rob Wilkerson wrote:
> > > I'm working on establishing a process for using Subversion once
> > > we have completed a conversion from VSS and I'd like to get
> > > some advice on how/when to merge back into the trunk. I'm not
> > > going to carry any legacy history over from VSS. Instead, I'm
> > > going to leave it where it is and start fresh with Subversion
> > > using the most recently released code base for the product.
> > >
> > > From the point of view of an inexperience Subversion user, the
> > > most intuitive process seems to be this:
> > >
> > > 1. import latest code into the trunk of the product repository
> > > 2. create a branch to begin developing the next version
> > > 3. create another branch to provide a maintenance release
> > >
> > > So now I have 2 branches from the same trunk and I have several
> > > questions:
> > >
> > > 1. After development of the maintenance release has been
> > > completed and tested, is it a good practice (I'm assuming it
> > > is) to merge that "fixed" code into the branch created for the
> > > next version of the product?
> > > 2. Since it is a maintenance release of the code that makes up
> > > the trunk, should I merge that maintenance release code back
> > > into the trunk when it's released?
> > > 3. The product, like many others, has major, minor and
> > > maintenance releases. Should any or all of these be merged
> > > back into the trunk or should branches be left as branches? If
> > > they should be merged back into the trunk then when is this
> > > usually done?
> > >
> > > I guess what I'm trying to figure out is the best workflow to
> > > use in the development lifecycle of a product. Any guidance
> > > would be much appreciated. High level process flow suggestions
> > > would help me tremendously.
> >
> > The usual flow of things is to have your main development on
> > trunk and to branch out for release and subsequent maintenance of
> > the release. (You might also use branches for big changes that
> > might break the code after a commit, but where a commit is non
> > the less required for some reason - sharing, milestone capture,
> > module testing. These "feature branches" would be merged back to
> > the trunk when the feature is complete.)
> >
> > Applying this to your situation, you would import your original
> > code release into trunk and immediately create a branch for
> > maintaining that release. Development of the next version would
> > then proceed on trunk, until you are ready for the next release.
> > At that point you would branch a new release/maintenance branch.
> > Development for the subsequent version then proceeds on trunk
> > again.
> >
> > Merges are simply made on an as required basis. Your process will
> > need to include a review board to decide if each fix applied to a
> > maintenance branch should also be applied to trunk, in which case
> > it is merged or manually duplicated - a maintenance fix may not
> > be able to use an optimal solution for example. Same for fixes on
> > the trunk, do they need to be back ported to any maintenance
> > branches? Again, merges may do the job here, but since this is a
> > back port, the fix may have to take a different form.
> >
> > Anyway, that's more or less what we do, but I don't think I could
> > claim it as Original Work. :-)
> >
> > Good luck.
> > --
> >
> > > Nick Thompson
--
> Nick Thompson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branching/Merging Best Practices
Posted by Nick Thompson <ni...@agere.com>.
On Tuesday 11 July 2006 19:18, Rob Wilkerson wrote:
> I'm working on establishing a process for using Subversion once we
> have completed a conversion from VSS and I'd like to get some
> advice on how/when to merge back into the trunk. I'm not going to
> carry any legacy history over from VSS. Instead, I'm going to
> leave it where it is and start fresh with Subversion using the most
> recently released code base for the product.
>
> From the point of view of an inexperience Subversion user, the most
> intuitive process seems to be this:
>
> 1. import latest code into the trunk of the product repository
> 2. create a branch to begin developing the next version
> 3. create another branch to provide a maintenance release
>
> So now I have 2 branches from the same trunk and I have several
> questions:
>
> 1. After development of the maintenance release has been completed
> and tested, is it a good practice (I'm assuming it is) to merge
> that "fixed" code into the branch created for the next version of
> the product?
> 2. Since it is a maintenance release of the code that makes up the
> trunk, should I merge that maintenance release code back into the
> trunk when it's released?
> 3. The product, like many others, has major, minor and maintenance
> releases. Should any or all of these be merged back into the trunk
> or should branches be left as branches? If they should be merged
> back into the trunk then when is this usually done?
>
> I guess what I'm trying to figure out is the best workflow to use
> in the development lifecycle of a product. Any guidance would be
> much appreciated. High level process flow suggestions would help
> me tremendously.
The usual flow of things is to have your main development on trunk and
to branch out for release and subsequent maintenance of the release.
(You might also use branches for big changes that might break the
code after a commit, but where a commit is non the less required for
some reason - sharing, milestone capture, module testing. These
"feature branches" would be merged back to the trunk when the feature
is complete.)
Applying this to your situation, you would import your original code
release into trunk and immediately create a branch for maintaining
that release. Development of the next version would then proceed on
trunk, until you are ready for the next release. At that point you
would branch a new release/maintenance branch. Development for the
subsequent version then proceeds on trunk again.
Merges are simply made on an as required basis. Your process will need
to include a review board to decide if each fix applied to a
maintenance branch should also be applied to trunk, in which case it
is merged or manually duplicated - a maintenance fix may not be able
to use an optimal solution for example. Same for fixes on the trunk,
do they need to be back ported to any maintenance branches? Again,
merges may do the job here, but since this is a back port, the fix
may have to take a different form.
Anyway, that's more or less what we do, but I don't think I could
claim it as Original Work. :-)
Good luck.
--
> Nick Thompson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org