search

krono / squeaksource3

Seaside-based Monticello code repository for Squeak, Pharo and GemStone
0 stars 0 forks source link

SSVersionAlreadyExists thrown by SSVersionView>>copyAll but not handled... #72

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Similar to Issue 24 but different ...

check out  copyall copyversion, copypackage and movepackage move version to 
make sure all variants will handle this exception correctly

Original issue reported on code.google.com by henrichs...@gmail.com on 23 Dec 2011 at 9:40

GoogleCodeExporter commented 9 years ago

Original comment by henrichs...@gmail.com on 23 Dec 2011 at 9:40

GoogleCodeExporter commented 9 years ago 
SSProject>>versionsWithPackageName: is used to collect the list of versions to 
be copied, however, SSProject>>versionsWithPackageName: does not guarantee that 
each version returned is readable by the current user  (see 
SSProject>>isMember:allowedTo:for: for the special case involving released 
versions, implying that non-released versions are not readable).

In SqueakSource 3.0-rc.1.1, SSProject>>copyVersion:to:author:as: is used to 
perform the copy and it _will_ throw an SSAccessViolation if the user is not 
allowed to read a copied version.

sooooo, in addition to handling SSVersionAlreadyExists, you'll need to handle 
SSVersionAccessViolation as well

Original comment by henrichs...@gmail.com on 5 Jan 2012 at 7:08

GoogleCodeExporter commented 9 years ago 
SSVersionView>>copy,SSVersionView>>copyDependencies, SSVersionView>>delete, 
SSVersionView>>deleteAll, SSVersionView>>deleteDependencies, 
SSVersionView>>move, SSVersionView>>moveAll, and 
SSVersionView>>moveDependencies will all need to handle SSAccessViolation and 
SSVersionAlreadyExists exceptions cleanly as of SqueakSource 3.0-rc.1.1

Original comment by henrichs...@gmail.com on 5 Jan 2012 at 7:23

GoogleCodeExporter commented 9 years ago 
BTW, when doing a bulk copy or move, it might be better if the 
SSVersionAlreadyExists exceptions were avoided altogether when doing the 
operation, by filtering out the duplicates ahead of time and only listing the 
versions that can be copied ... 

If we ignore the issues involved with 'released versions' (Issue 79) and filter 
out the duplicate versions then all of the exception handling can be eliminated 
from the view-side...

I would recommend that validation continue to be done in action methods in 
SSProject (see Issue 76) so that if mistakes are made in the filtering you 
won't end up with access violations, but those events should be truly 
exceptional events

Original comment by henrichs...@gmail.com on 6 Jan 2012 at 12:07

GoogleCodeExporter commented 9 years ago

Original comment by henrichs...@gmail.com on 6 Jan 2012 at 1:17