RE: [jrmtool-developers] Switch to Subversion

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

Hi Gail,

On Tue, 2006-04-04 at 21:03 -0700, Gail Murphy wrote:
> Hi Jacek, 
> 
> > -----Original Message-----
> > From: Jacek Rosik [mailto:jac...@ul...] 
> > Sent: April 4, 2006 5:18 PM
> > To: mu...@cs...
> > Cc: jRMTool Developers
> > Subject: Re: [jrmtool-developers] Switch to Subversion
> > 
> > Hi Gail
> > 
> > On 4 Apr 2006, at 18:46, Gail Murphy wrote:
> > [snip]
> > >>
> > >> Converted repository is already uploaded to SourceForge. The only 
> > >> thing left now is to enable Subversion access and disable 
> > CVS access. 
> > >> We could leave CVS repository enabled but I think it would only 
> > >> confuse users as I don't think we are going to update it. 
> > Gail, could 
> > >> you do it?
> > 
> > Any progress on this? I tried to do it but I couldn't, 
> > probably administrative rights again.
> > 
> > Subversion repository is already on SF. You can access it at:
> > https://svn.sourceforge.net/svnroot/jrmtool/
> > The required change is only to make subversion option visible 
> > on jrmtool project page.
> 
> Should be accessible now.

Yes, it is accessible. One more thing though. Could You enable two
subversion scripts (last option at the bottom of the subversion
configuration page)? Those scripts are 'check-case-insensitive.py' and
'check-mime-type.py'. First would be useful to make sure that we won't
have any name conflicts on windows machines and second one will ensure
that binary files are treated as binary files.

You could also create a new list for commit messages and enable
'svnnotify.py' script to feed this list. But I don't think that is
necessary as I will be the only contributor for a while. On the other
hand it is quite nice feature if we have more contributors as everyone
will be notified of the changes. Anyway if you decide to do it I'd
rather have commit messages w/o diffs in them.

> > 
> > [snip]
> > >> * Create branch for version 1.0.x. All new features will go into 
> > >> trunk and will form 1.1.x releases. We can port some bugfixes to 
> > >> 1.0.x branch but I don't think there is a need for that.
> > >
> > > Seems right. To be clear, the intended target is Eclipse 3.1?
> > >
> > > Should we start a branch that investigates Eclipse 3.2 support? (I 
> > > would be interested in looking into this)
> > 
> > As me or Andrew mentioned before we would rather target 3.x. 
> > We can't force of our users to use any specific version of 
> > Eclipse. It shouldn't be too hard I suppose. If it proves 
> > otherwise, then we can  
> > investigate possibilities of supporting only selected minor   versio.
> 
> Always preferable but a reasonable number of small changes are likely
> necessary to support 3.2 (based on our experience developing other plugins).

Yes, that is probably true. What I mean is that we have make sure that
those changes won't break backward compatibility (If it's possible).

> > 
> > >
> > >> * After this I'm going to get rid of some files from 
> > repository which 
> > >> shouldn't be there. For example .classpath JavaDB.jar. 
> > Then I'm going 
> > >> to import JavaDB source into repository (need permission 
> > from author, 
> > >> any update on this Gail?). The reason for this is that some of our 
> > >> modifications
> > >
> > > I'm checking into putting in source. For now, we do *not* have 
> > > permission.
> > 
> > We need that before I'll be able to commit Rory's changes (backend
> > improvements) as he has modified JavaDB itself.
> > 
> > > Also, we need to deal with licenses. I would like to move 
> > everything 
> > > onto an EPL license. Other thoughts?
> > >
> > I always get nautious when it comes to legal stuff. 
> > Personally I use either GPL or MIT/BSD I don't even try to 
> > read other licenses ;).  
> > Anyway I'll read EPL and compare it to CPL and let you know 
> > what I'm thinking about it.
> 
> EPL is the next genesis of CPL. I won't contribute to any GPL code but
> that's another story.
EPL is fine by me. If you want to change license to EPL, please do so. I
would like this change to happen before I commit code contributed by FYP
students. I want to have their explicit permission to publish their work
under the terms of specific license.


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