Re: [jrmtool-developers] Copyrights, renaming, etc.

[Jacek R. <jac...@ul...>]

On 26 Apr 2006, at 00:29, Gail Murphy wrote:

> Hi,
>
> I'd like to propose the following changes which I'm willing to do  
> (coordinate in the case of one):
> Change all copyrights to EPL of the form below unless it was a  
> class added by others in which case it should be accurate in the  
> top line, last line:
> / 
> ********************************************************************** 
> *********
>  * Copyright (c) 2004 - 2006 University Of British Columbia and  
> others.
>  * All rights reserved. This program and the accompanying materials
>  * are made available under the terms of the Eclipse Public License  
> v1.0
>  * which accompanies this distribution, and is available at
>  * http://www.eclipse.org/legal/epl-v10.html
>  *
>  * Contributors:
>  *     University Of British Columbia - initial API and implementation
>   
> ********************************************************************** 
> *********/
>
> Switch to a net.sf.jrmtool (etc.) package naming to reflect the  
> fact that others are working on the code.
> Add a net.sf.jrmtool.test package for junit tests of non-Eclipse  
> parts of the system
> Add a net.sf.jrmtool.eclipse.test package for Eclipse-based tests  
> (perhaps non-automated tests for now
>
Fine by me.

>
> I am emailing with Martin Robillard (creator of FEAT) about  
> creating a separate entry under trunk: trunk/feat (if that's  
> feasible) to incorporate the FEAT code under EPL. Hopefully we'll  
> have an update on that available soon.
>
Yes, the plan is to create separate entry for javadb when importing  
Rory's (back-end) changes.

> What is the process we are using on creating branches and doing  
> merges? I'm reluctant to have too many branches outstanding (but  
> maybe that's because I'm a naive subversion user). For instance, it  
> seems like at least the front-end improvements (if they are  
> working) should be merged to trunk before I create a branch to do  
> the copyright change or renaming.

The plan is to merge those branches as soon as possible and them  
delete them (we can still access those branches later using  
subversion). With back-end we are hold off by legal issues. And with  
front-end I have found something I would like to get rid off before  
merging. Jonathan is using some internal JDT classes and I don't like  
it (and it shold not be done). I would like to get rid of those  
dependencies before merge. I'm currently in Poland, I'm comming back  
in 2 weeks, I should sort it out then. If you could wait with above  
mentioned changes that would be great.

As for branching, in subversion it is exactly like copying regular  
files/directories (although history is preserved), so you just create  
a directory under `branches' directory (that is only a convention,  
not obligation). Merging is also simple, you just specify two  
revisions/directories to `svn merge' command and changes introduced  
between those revisions are merged into current working copy. You may  
need to resolve some conflicts and then just commit merged changes  
(running some test before that is of course recomended). There is a  
support for merege in Eclipse/Subclipse, but I alwas prefered command  
line or tortoisesvn.  If you would like to merge front-end changes it  
would look like this:

$ cd /somepath/wc (where wc is checked out https:// 
svn.sourceforge.net/svnroot/jrmtool/trunk/jrmtool)
$ svn merge -r 4:10  https://svn.sourceforge.net/svnroot/jrmtool/ 
branches/frontend-improvements-1.0/jrmtool
...
resolve conflicts (supported by subcvlipse)
..
$svn commit (to commit merged changes)

In Eclipse/Subclipse merge dialog you just specify this url  https:// 
svn.sourceforge.net/svnroot/jrmtool/branches/frontend- 
improvements-1.0/jrmtool and revision range 4-10.

You can find much more here: http://svnbook.red-bean.com/
Here is a great SVN client for windows: http://tortoisesvn.tigris.org

I hope this is helpful. If you have any more questions please ask.

--
Jacek Rosik <jac...@ul...>