Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: CVS Branching [was RE: [higgins-dev] Code Changes]

Yes, please someone ... because if you're asking me, here's all I know:

- In the project view, right click on the project.
- Team

This yields several choices:
	Tag as Version...
	Branch...
	Merge...
	Switch to Another Branch or Version...

For the org.eclipse.higgins.idas.cp.jndi project, if you want the latest,
use "Switch ..." and pick HEAD.  If you want milestone 0.8, pick M0-8.
You can switch back and forth at will and it seems to give me the correct
files for each.

I used the "Branch..." option to create the M0-8 branch and I let it
auto-fill the Version name (which it made Root_M0-8).

This is the extent of my expertise on the matter.  Anyone else able
to describe more CVS management details in Eclipse?

Tom

>>> Michael McIntosh <mikemci@xxxxxxxxxx> 6/8/2007 12:28 PM >>>
Can someone please send instructions to the list describing how to manage 
this in Eclipse?

Thanks,
Mike

higgins-dev-bounces@xxxxxxxxxxx wrote on 06/08/2007 01:39:41 PM:

> So, we discussed this with Paul via telephone and he agreed that we
> need a good long term approach and that we should proceed with what
> we proposed here below.  We can refine it as we go.
> 
> For naming, I suggest we name our branches according to the
> milestone they represent.  The branch names cannot contain spaces
> nor the characters '$,.:;@|' and they must begin with an alpha
> character.  So, I suggest this:
> 
> M<Major Version>-<Minor Version>-<Sub-Release, if any>
> 
> For milestone 0.8, it'd be:
> 
> M0-8
> 
> Jim is looking at options for cross-project usage of the same branch
> so we could easily move back and forth in eclipse for dependant
> projects.
> 
> I'm going to proceed according to this plan for my projects.
> 
> Tom
> 
> >>> "Tom Doman" <TDoman@xxxxxxxxxx> 6/8/2007 10:22 AM >>>
> We've been discussing this here at Novell (Andy, Jim, and I) and here's
> our suggestion.  We should create M0.8 branches and have Catalyst,
> etc. bug fixes checked into that branch.  HEAD should be for current
> development until such time as we want to stabilize for the next
> milestone, M0.9.  Then, we'll branch for that.  That way, those checking
> out and\or building projects will know exactly what base they are
> dealing.  So, if a stable build is wanted, HEAD is never the place to
> get it.  And as bug fixes are made to branches, those can be merged
> back into HEAD.
> 
> In the nightly builds, we can build any of the branches we're currently
> supporting for ongoing development but we always have stable branches
> of each milestone that we've produced.
> 
> How does that sound?
> 
> Tom
> 
> >>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 6/8/2007 8:51 AM >>>
> My suggestions:
> - the HEAD is where bug-fixing and other very low risk changes should be
> committed.
> - if any of us do create a branch and commit code to it, they'll be
> responsible for remerging those changes to the HEAD stream after 
Catalyst
> (June 27)
> 
> Tom wrote:
> > 
> > Shall we come up with a Higgins prescribed way to name Branches and
> > Versions if we're going to do this?  I'm ready to branch the JNDI CP
> > for some changes but I'm not sure how to name nor what our "go
> > forward" strategy is as far as merging goes.  Will we always merge
> > into HEAD eventually?  Or will we pick a branch named by our current
> > milestone?  Something else?  We need something that makes sense
> > and will make it easy for developers to participate.
> > 
> > I freely admit to being a CVS newbie in this regard.  I've never
> > branched, versioned, or, of course, merged.  So, I'm looking for
> > some seasoned guidance and sensical plan here.  Anyone?
> > 
> > Thanks,
> > Tom
> > 
> > >>> Anthony Nadalin <drsecure@xxxxxxxxxx> 6/6/2007 2:12 PM >>>
> > 
> > So this is where I get worried as since .8 has some changes in HBX and
> > RPPS
> > that are not done this may break the demo, so I would like to make 
sure we
> > freeze HBX and RPPS like real soon to avoid issues in this space. So 
any
> > changes in HBX or RPPS we will fork and resolve after interop
> > 
> > Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> > 
> > 
> > 
> >              "Paul Trevithick"
> >              <paul@socialphysi
> >              cs.org>  To
> >              Sent by:                  "'Higgins \(Trust Framework\)
> >              higgins-dev-bounc         Project developer discussions'"
> >              es@xxxxxxxxxxx            <higgins-dev@xxxxxxxxxxx>
> >  cc
> > 
> >              06/06/2007 12:37 Subject
> >              PM                        RE: [higgins-dev] Code Changes
> > 
> > 
> >              Please respond to
> >              "Higgins \(Trust
> >                 Framework\)
> >              Project developer
> >                discussions"
> >              <higgins-dev@ecli
> >                  pse.org>
> > 
> > 
> > 
> > 
> > 
> > 
> > M0.8 is not done. At this point I propose we hold off on declaring 
victory
> > on M0.8 until after the interop.
> > 
> > 
> > From: higgins-dev-bounces@xxxxxxxxxxx 
> > [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
> > Sent: Wednesday, June 06, 2007 12:50 PM
> > To: Higgins (Trust Framework) Project developer discussions
> > Cc: 'Higgins (Trust Framework) Project developer discussions';
> > higgins-dev-bounces@xxxxxxxxxxx 
> > Subject: Re: [higgins-dev] Code Changes
> > 
> > 
> > 
> > yep that would be good, I also assume we are complete on milestone .8 
and
> > we can hold on that until after the interop
> > 
> > Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> > Inactive hide details for "Jim Sermersheim" <jimse@xxxxxxxxxx>"Jim
> > Sermersheim" <jimse@xxxxxxxxxx>
> > 
> > 
> > 
> > 
> >                          "Jim
> >                          Sermershe
> >                          im"
> >                          <jimse@no
> >                          vell.com>  To
> > 
> >                          Sent by:            "'Higgins (Trust 
Framework)
> >                          higgins-d           Project developer
> >                          ev-bounce           discussions'"
> >                          s@eclipse           <higgins-dev@xxxxxxxxxxx>
> >                          .org
> >  cc
> > 
> >                          06/06/200
> >                          7 11:44 Subject
> >                          AM
> >                                              Re: [higgins-dev] Code
> >                                              Changes
> > 
> > 
> > 
> >                            Please
> >                           respond
> >                              to
> >                           "Higgins
> >                           \(Trust
> >                           Framewor
> >                             k\)
> >                           Project
> >                           develope
> >                              r
> >                           discussi
> >                             ons"
> >                           <higgins
> >                           -dev@ecl
> >                           ipse.org
> >                              >
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > sounds good.
> > 
> > If/when we need to do a bug fix, I suppose we should notify the list 
just
> > in case of unforseen ramifications?
> > 
> > >>> Anthony Nadalin <drsecure@xxxxxxxxxx> 6/6/07 10:33 AM >>>
> > 
> > 
> > I would like to propose that all non-bug related changes be held or 
forked
> > until after June 25, thus putting a freeze on current code before the
> > Burton Interop, as we don't want to spend resources chasing bugs that
> > changes might cause, and we would resume normal processes after June 
25th
> > 
> > Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx 
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev 
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx 
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev 
> > 
> > 
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx 
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev 
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev


Back to the top