On Fri, 13 Aug 2010, Wayne Boucher wrote:

> On (1) how do you think we should handle it?  We could not allow someone to 
> create a new project where one already exists.  We could remove what is there 
> but I don't think that option would get too many votes.  The problem is that 
> we can't really just ignore what is there (say, with a warning) because of 
> the way the loading mechanism works (you cannot have two projects inside one 
> project directory).

So, as I understand it, no part of the project is written to disk until 
one explicitly saves, so the software should not care (or even notice) 
that there's a project with the same name in the current working 
directory. This changes when the user decides to save the project (which 
they might do in a different directory from the current working directory) 
or they switch on the backup (which is off by default) - then the program 
should ask whether the user wants to overwrite the existing 
project/backup.

> On (3) I hope we have sorted it now (patch on the update server).

Seems to be fixed with that update.

> On the update issue, we are going to have to spend some time now thinking 
> about how best to handle major upgrades, especially now that Dan has gotten 
> the packages to work.  I take your point about allowing further minor 
> upgrades to take place.

It's going to be particularly important when you follow the roadmap that 
calls for the stable/development release fork.

> As it happens all the minor upgrades are still on the server but they're 
> just in a place that the software currently can't find it, so we should 
> change that, but that would only impact future releases, unfortunately 
> (unless people fixed things by hand in existing releases).

I think that fixing by hand (presumably just copying a replacement of one 
of the python files to the right place) to retroactivate this would be an 
acceptable solution to most for previous releases.

> Wayne
>
> On Fri, 13 Aug 2010, Brian Smith wrote:
>
>>  On Fri, 13 Aug 2010, Wayne Boucher wrote:
>> 
>> >  With all the pre-compiled options now available I would highly recommend 
>> >  that people who want to upgrade visit the download site 
>> >  (http://www.ccpn.ac.uk/ccpn/software/downloads-v2/) rather than doing so 
>> >  via the Update menu, to make sure you get what you want.  We're going to 
>> >  have to look again at how to best make these "major" upgrades work from 
>> >  the Update menu.  (But it's trivial to upgrade from the download site 
>> >  for pre-compiled releases.)
>>
>>  The upgrade worked fine apart from the link making business - that I did
>>  by hand. Since users are highly likely to first discover that a new
>>  release is out via the update server, it's important that if they do,
>>  their situation is well handled. For source monkeys then the straight
>>  upgrade _should_ always be made to work. With all the precompiled &
>>  packaged versions would it be too troublesome to have the update server
>>  bring any particular release up to its latest version without forcing the
>>  user into major upgrades?
>> 
>> >  Now onto the issues.  (1) has been that way since v2.0, so is a 
>> >  "feature" rather than a "bug", although it seems odd I would agree.
>>
>>  It's definitely not as it should be!
>> 
>> >  (2) is presumably in OpenGL mode only??  That is going to be hard for us 
>> >  to sort (unless we discover one of our machines has that card).
>>
>>  Yes, sorry if I forgot to say so. More as a report so that if someone else
>>  finds the same, we can work towards solving it together!
>> 
>> >  (3) is strange and sounds suspiciously like it might be related to the 
>> >  issue that Vytautas had last week:
>> > 
>> >  https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=CCPNMR&F=&S=&X=3AA3900CF56475F2BB&Y=wb104%40bioc.cam.ac.uk&P=18785
>> > 
>> >  We haven't knowingly changed anything on this front for ages though and 
>> >  we still don't understand what might be happening here.
>> > 
>> > >   3. Profiles: Has 2.1.5 got stricter about user profiles? If I try to 
>> > >   open
>> > >     a project as a different user I get a project invalid message that
>> > >     refers to not being able to find the entry in the original user's
>> > >     profile (because it's looking in the current user's ~/.ccpn 
>> > >     directory
>> > >     for it). Surely failure to find the profile should warn and simply
>> > >     result in the project being opened with default settings anyway?
>>
>>  So, this could have been around before, but I would not necessarily have
>>  noticed. The error (Project invalid,......:No active repository found for
>>  TopObject <ccpnmr.AnalysisProfile.AnalysisProfile ['name of profile']> )
>>  only occurs when the non owner of the project tries to open it without
>>  having write access to the original user's ~/.ccpn directory (which would
>>  be normal, but masked if you try to check it as say a user with superuser
>>  privilges on the machine where the disk is local)
>>
>>  The only profile reference I can find is stored in
>>
>>  projectName/memops/Implementation/projectName.xml
>>
>>  I'm not quite sure what the expected behaviour with profiles is - I didn't
>>  even know I had even created one - is it that if a user has a profile then
>>  it will become associated with any other project they open? Can one have
>>  multiple profiles? Is there an interface to manage/delete/unassociate
>>  profiles?
>>
>>  Traceback (most recent call last):
>>  File "/usr/local/ccpnmr/ccpnmr2.1/python/ccpnmr/analysis/AnalysisGui.py",
>>  line 226, in ?
>>     main(projectDir, max_size, glDirect)
>>  File "/usr/local/ccpnmr/ccpnmr2.1/python/ccpnmr/analysis/AnalysisGui.py",
>>  line 111, in main
>>     top.initProject(project)
>>  File
>>  "/usr/local/ccpnmr/ccpnmr2.1/python/ccpnmr/analysis/AnalysisPopup.py",
>>  line 1503, in initProject
>>     Analysis.initProject(self, project)
>>  File "/usr/local/ccpnmr/ccpnmr2.1/python/ccpnmr/analysis/Analysis.py",
>>  line 284, in initProject
>>     Util.defaultColors(project)
>>  File "ccpnmr2.1/python/ccpnmr/analysis/core/Util.py", line 1149, in
>>  defaultColors
>>  File "ccpnmr2.1/python/ccpnmr/api/AnalysisProfile.py", line 1681, in
>>  getColorSchemes
>>  File "ccpnmr2.1/python/memops/api/Implementation.py", line 5032, in load
>>  memops.general.Implementation.ApiError: No active repository found for
>>  TopObject <ccpnmr.AnalysisProfile.AnalysisProfile ['XXXXXXX']>
>>
>>  --
>>  Dr. Brian O. Smith ---------------------- Brian Smith at glasgow ac uk
>>  School of Life Sciences, College of Medical, Vetinary & Life Sciences,
>>  Joseph Black Building, University of Glasgow, Glasgow G12 8QQ, UK.
>>  Tel: 0141 330 5167/6459/3089                        Fax: 0141 330 4600
>>  ----------------------------------------------------------------------
>>  The University of Glasgow, charity number SC004401
>> 
>

-- 
Dr. Brian O. Smith ---------------------- Brian Smith at glasgow ac uk
School of Life Sciences, College of Medical, Vetinary & Life Sciences,
   Joseph Black Building, University of Glasgow, Glasgow G12 8QQ, UK.
Tel: 0141 330 5167/6459/3089                        Fax: 0141 330 4600
----------------------------------------------------------------------
The University of Glasgow, charity number SC004401