>> I do my Subclipse development in Eclipse 3.0. I would have big concerns
>> about producing our releases on 3.1 and running them on 3.0. In the
>> with my companies other Eclipse-based applications that has not worked.
> So long as you use backwards compatible APIs, it does work. The problem
> is knowing which ones are backwards compatible :)
> How about i undo the fix and attach it to the issue that requested the
> change? That way, when we do move to 3.1 it can be re-applied and not
> It is a useful feature, but it isn't *that* important.
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
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
Comments? I would be happy to set this up, or Brock can just do it for
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.
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Tue Oct 18 08:27:39 2005