Note that I've already created one such feature branch for locking API
improvements (which contains enough value and is low enough risk to be
merged at any time). In case it's not obvious, I am +1 on the concept.
- Dan
On Tue, 18 Oct 2005, Brock Janiczak wrote:
> I think this is a good idea. Patches are ok for small changes, but you
> can't include binary files (like images) in them.
>
> If no one objects to Mark's plan I will create the feature branch later
> this week or this weekend. Mark, you are also free to create it sooner
> if you want :)
>
>
> Mark Phippard wrote:
> >I have been having a discussion offline with Brock about a change he
> >committed which isn't very compatible with Eclipse 3.0. For now, I think
> >we have agreed to back out the change.
> >
> >I propose we create a folder inside "branches" called "features". There
> >could then be sub-folders called Subclipse, svnAnt etc.. Inside those
> >folders, we can create feature branches to implement a feature that is
> >specific to an Eclipse or Subversion version . I think we could be loose
> >in how we deal with these, but I would recommend that we try to keep them
> >limited to a specific feature so that we can easily merge them to trunk
> >later.
> >
> >For example, create the branch @ HEAD. Commit your changes, and then never
> >touch the branch again. Do not keep it up to date with trunk.
> >
> >When we merge it to trunk we can delete the feature branch.
> >
> >It seems like this would be a good way to take advantage of Subversion
> >repository features.
> >
> >Comments? I would be happy to set this up, or Brock can just do it for
> >this change.
> >
> >Brock, I would suggest backing your change out of trunk and commit it.
> >Then create the branch. Then commit to the branch. That would make it
> >easiest to merge later.
> >
> >Mark
> >
> >
> >_____________________________________________________________________________
> >Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
> >Email Security Management Services powered by MessageLabs.
> >_____________________________________________________________________________
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> >For additional commands, e-mail: dev-help@subclipse.tigris.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Wed Oct 19 04:29:24 2005