Am 06.09.2011 um 18:04 schrieb Andy Seaborne: > > > On 06/09/11 16:34, Paolo Castagna wrote: >> >> >> 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)? > > Identifying which small set of files from a large set of files in the tag is > actually RDQL.
This is reasonable, though it's possible to get the set of changed files between two revisions with the help of svn; and there is other tooling support as Paolo mentioned. I'm not going to insist either. Instead, I tell you our "solution": Inspired by (good old?) CVS, we have created a folder "attic" as a sibling to trunk, tags, branches. Retired code is moved to that folder thereby not distracting us in trunk (both mentally and in terms of resources). Thorsten > > Andy > >> >> Paolo >> >>> in fact, I see forlorn hope. >>> >>> Thorsten >>>
