Thorsten Möller wrote:
> On Monday, September 05, 2011 11:55 PM [GMT+1=CET],
> Andy Seaborne <[email protected]> wrote (with possible 
> deletions):
> 
>> On 05/09/11 22:05, Thorsten Möller wrote:
>>> Am 05.09.2011 um 22:44 schrieb Andy Seaborne:
>>>
>>>> There has been an old copy of RDQL in ARQ, although it's use is
>>>> strongly discouraged (unclear formal semantics; integrated into
>>>> evaluation as a query language by some quite fragile hacks).
>>>>
>>>> It's now been removed from ARQ completely.  The code is available
>>>> in the Archive area of ARQ SVN.  It will not be maintained and it
>>>> will not in the ARQ distribution.
>>> Wouldn't it be sufficient to mark the last state before the removal
>>> by a tag in SVN (rather than having the jar in the working copy just
>>> hanging around)? Is there a need for having an additional file-based
>>> archive if SVN is the archive?
>>  >
>>> Thorsten
>> There's a zip in an area called Archives/.
> It's this file (resp. this directory) that my comment was about, while 
> making a mistake by writing "jar" instead of "zip".
> 
>>  It collects all the RDQL
>> specific files together - source and test suite.  It's not the whole
>> codebase.
> Well, makes it even more fragile from an archiving point of view. 
> Someone that would access this code would likely need it in relation to 
> the same state of the rest of the codebase. How can one know the 
> consistent (latest) state of both? This information is not in the zip 
> file - it would be inherent based on a SVN tag.
> 
> I fail to see reasons for maintaining an archive within an archive; 

I would prefer we use SVN tags (as we do for releases) for this sort of things: 
https://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/tags/
Indeed, in this case, we just need to remember the latest ARQ release with RDQL 
in it (which we can retrieve from the ChangeLog.txt file) and checkout that tag 
if we want to look at RDQL ever again.
The problem is that the more things we have here: 
https://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/trunk/ the more 
"noise" new (potential) committers will experience when they want to get
into the details of a Jena module.
People might ask themselves: "what's there inside that Archive directory"? and 
the most curious will even waste time to look into those .zip files. ;-)

Andy, what's missing from SVN + tags in terms of "archiving" things (and 
therefore having the freedom to remove unused/deprecated stuff)?

Paolo

> in fact, I see forlorn hope.
> 
> Thorsten 
> 

Reply via email to