RE: [jrmtool-developers] Switch to Subversion

[Gail M. <mu...@cs...>]

Subversion scripts enabled.

Commit notifications are on and will be sent (w/o diffs) to
jrm...@li....

To subscribe, see:
https://lists.sourceforge.net/lists/listinfo/jrmtool-revnotify

Gail. 

> -----Original Message-----
> From: Jacek Rosik [mailto:jac...@ul...] 
> Sent: April 11, 2006 5:59 AM
> To: mu...@cs...
> Cc: 'jRMTool Developers'
> Subject: RE: [jrmtool-developers] Switch to Subversion
> 
> 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...>