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 <nickthompson@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
Received on Thu Jul 13 13:05:48 2006