RE: [Long] Public repository scalability, Store improvements needed?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: [Long] Public repository scalability, Store improvements needed?

Steven Kelly

From: Alan Knight [mailto:[hidden email]]
 StoreForGlorp actually adds an #Obsolete blessing level for precisely this purpose, and the package that generates the view at http://www.cincomsmalltalk.com/publicStore will ignore things for which the most recent (or maybe it's any) version has this blessing. That could (should) be integrated into base Store, and other things could make use of it as well.

 

How does that work if there are two branches, and one is marked #Obsolete? That's one of the current weaknesses of the VW Store tools – versions are perceived as a single linear sequence in most of them. The Graph Versions tool can show the branchings, but even that does not show the merges.

 

Steve


--
Alan Knight [|], Cincom Smalltalk Development

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross
Reply | Threaded
Open this post in threaded view
|

RE: [Long] Public repository scalability, Store improvements needed?

Alan Knight-2
At 11:24 AM 3/13/2007, Steven Kelly wrote:
From: Alan Knight [[hidden email]]
 StoreForGlorp actually adds an #Obsolete blessing level for precisely this purpose, and the package that generates the view at http://www.cincomsmalltalk.com/publicStore will ignore things for which the most recent (or maybe it's any) version has this blessing. That could (should) be integrated into base Store, and other things could make use of it as well.
 
How does that work if there are two branches, and one is marked #Obsolete? That's one of the current weaknesses of the VW Store tools – versions are perceived as a single linear sequence in most of them. The Graph Versions tool can show the branchings, but even that does not show the merges.

It would not work - and that doesn't really make any sense with the semantics it's using for Obsolete. It indicates that the package or bundle as a whole is obsolete and should be filtered out of the list. If you wanted to indicate that development on a particular stream had ended, you'd need another mechanism. For that matter, you'd need a mechanism for streams. That's more involved, although thought has been given to it.
--
Alan Knight [|], Cincom Smalltalk Development

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross