While looking at this, it occurs to me that there are a few other outdated directories taking up significant amounts of space in this repo. The space is cheap, of course, but it does seem a bit confusing/unnecessary to make everyone checking out a copy of the TEI SF repo download all this old crud as well. Can anyone come up with a good reason not to zap also the directory TEIOO-Deprecated ? This is no longer supported, and its function has been superceded by the Stylesheets directory anyway. There are also the following, which I think may now be of purely archival/historical interest : - genetic (contains the record of the work of the genetic working group now incorporated into P5 - Extensions (contains some sample ODDs for olde projectes - I18N (special case of the above, since it contains work done using ODD but not using TEI And two others whose status/usefulness is unknown to me - TEIC (contains stuff related to the website newsfeed - TEICSS (contains sample CSS file and a testfile; last updated 2007 Should we maybe create a separate Archival space for all this? On 09/01/15 22:02, Lou Burnard wrote:

Yes, my fault: a careless checkin during christmas week added an old copy of the stylesheet directory as well as some documentation. It's version 6.38, so should definitely be zapped.

Which I have now done.

On 09/01/15 21:52, Hugh Cayless wrote:

...

It looks like a copy of the Stylesheets got checked in to the Guidelines repo last month. I presume this was an accident and it's ok to get rid of it?

Hugh

That's a good idea for things that might conceivably still be useful, but I think it's ok to actually delete things too. They still exist in the repo's history. Hugh Sent from my phone.

On Jan 10, 2015, at 15:49, Martin Holmes wrote:

I usually have a directory at the root of my repo called "obsolete", where stuff like this goes. If you make it a sibling of tags, branches and trunk, then most of us will never check it out (we tend to work only with trunk).

Cheers, Martin

...

On 15-01-10 04:45 AM, Lou Burnard wrote: While looking at this, it occurs to me that there are a few other outdated directories taking up significant amounts of space in this repo. The space is cheap, of course, but it does seem a bit confusing/unnecessary to make everyone checking out a copy of the TEI SF repo download all this old crud as well.

Can anyone come up with a good reason not to zap also the directory TEIOO-Deprecated ? This is no longer supported, and its function has been superceded by the Stylesheets directory anyway.

There are also the following, which I think may now be of purely archival/historical interest :

- genetic (contains the record of the work of the genetic working group now incorporated into P5 - Extensions (contains some sample ODDs for olde projectes - I18N (special case of the above, since it contains work done using ODD but not using TEI

And two others whose status/usefulness is unknown to me

- TEIC (contains stuff related to the website newsfeed - TEICSS (contains sample CSS file and a testfile; last updated 2007

Should we maybe create a separate Archival space for all this?

...

On 09/01/15 22:02, Lou Burnard wrote: Yes, my fault: a careless checkin during christmas week added an old copy of the stylesheet directory as well as some documentation. It's version 6.38, so should definitely be zapped.

Which I have now done.

...

On 09/01/15 21:52, Hugh Cayless wrote: It looks like a copy of the Stylesheets got checked in to the Guidelines repo last month. I presume this was an accident and it's ok to get rid of it?

Hugh -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

True. But not everything needs to be kept in the attic. It's ok to get rid of stuff when it's no longer useful. Sent from my phone.

On Jan 10, 2015, at 18:10, Martin Holmes wrote:

...

On 15-01-10 03:08 PM, Hugh Cayless wrote: That's a good idea for things that might conceivably still be useful, but I think it's ok to actually delete things too. They still exist in the repo's history.

You don't know they were there, though, unless you know they were there. :-)

...

Hugh

Sent from my phone.

...

On Jan 10, 2015, at 15:49, Martin Holmes wrote:

I usually have a directory at the root of my repo called "obsolete", where stuff like this goes. If you make it a sibling of tags, branches and trunk, then most of us will never check it out (we tend to work only with trunk).

Cheers, Martin

...

On 15-01-10 04:45 AM, Lou Burnard wrote: While looking at this, it occurs to me that there are a few other outdated directories taking up significant amounts of space in this repo. The space is cheap, of course, but it does seem a bit confusing/unnecessary to make everyone checking out a copy of the TEI SF repo download all this old crud as well.

Can anyone come up with a good reason not to zap also the directory TEIOO-Deprecated ? This is no longer supported, and its function has been superceded by the Stylesheets directory anyway.

There are also the following, which I think may now be of purely archival/historical interest :

- genetic (contains the record of the work of the genetic working group now incorporated into P5 - Extensions (contains some sample ODDs for olde projectes - I18N (special case of the above, since it contains work done using ODD but not using TEI

And two others whose status/usefulness is unknown to me

- TEIC (contains stuff related to the website newsfeed - TEICSS (contains sample CSS file and a testfile; last updated 2007

Should we maybe create a separate Archival space for all this?

...

On 09/01/15 22:02, Lou Burnard wrote: Yes, my fault: a careless checkin during christmas week added an old copy of the stylesheet directory as well as some documentation. It's version 6.38, so should definitely be zapped.

Which I have now done.

...

On 09/01/15 21:52, Hugh Cayless wrote: It looks like a copy of the Stylesheets got checked in to the Guidelines repo last month. I presume this was an accident and it's ok to get rid of it?

Hugh -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

Can I make one more argument against the "never throw anything away" policy? Not only does it not really solve the cruft issue by just shoving it under the sofa, it also means a new set of procedures have to be established: what gets moved? How do I decide whether to stuff a thing under the sofa or delete it? How much documentation does there need to be for these things? I think it adds work and cognitive load when all we really need to do is delete it. If someone wants to know how we did things in 2012, they'll revert the repo to an appropriate commit and poke around. If we do this, I bet in a few years the obsolete branch will get nuked anyway. Because nobody will ever use it. Still, if you really want to, at least I can ignore it :-). On Thu, Jan 29, 2015 at 12:36 PM, Syd Bauman wrote:

It seems no one has *done* this yet. I think it's a really good idea.

I think Hugh is, in general, right -- it's OK to nuke stuff, that's why it's in a version control repository. That said, in the TEI universe where the cadre of those responsible for the repository changes over time, I'm more inclined to Martin's clever obsolete/ sibling of branches/, tags/, and trunk/. Besides, that way we could easily reverse the decision, and delete things from obsolete/. (Could reverse decision and recover deleted stuff if needed, too, but much harder.)

But IIRC (and I'd love to be wrong on this), it is not easy in Subversion to ascertain from where a directory was moved. So a check-in comment like "moved .../trunk/duck/quack/waddle/ to .../obsolete/waddle/" would be a good idea, no?

I'm happy to file a ticket, assign it to myself, and do this. I hate cruft.

...

True. But not everything needs to be kept in the attic. It's ok to get rid of stuff when it's no longer useful. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

Actually, I think it might involve difficult decisions. Shall I now instead of deleting anything ever put it instead in the Vault? Where? How much documentation am I obligated to provide for it? Deletion *is* an option, because everything can be recovered. Anyway, I'm not going to argue much if you want to do it. It won't do any harm as long as we can still delete stuff we want to delete. I just think it's silly. On Thu, Jan 29, 2015 at 1:20 PM, Lou Burnard wrote:

Well (I am not advocating it myself) but the "never throw anything away" policy really doesn't involve any difficult decisions -- either something is live and useful or it's under the sofa: deletion isn't an option.

As I seem to have started this thread, can I make some specific suggestions?

My copy of the SF trunk has the following root directories:

Documents Extensions genetic I18N Incubator P5 TEIC TEICSS TEIOO-Deprecated

Documents, Extensions, and P5 are all active Incubator might be more active but it seems a useful place to put stuff that is, er, incubating I18N is an ODD application of interest independently of the TEI so should probably be left alone, until someone (Sebastian?) says it's been superceded. TEIC and TEICSS (we learn from Kevin) are useful for webmastery so should probably be left alone by the rest of us TEIOO-Deprecated I think should be deleted. As I said before, its function is now rolled into the Stylesheets and it hasn't ever been of much interest to anyone outside the TEI community The "genetic" folder is probably still referenced outside the TEI context, even though it's now of purely historical interest as far as we are concerned. If we are making a "Vault" folder (I think that sounds nicer than "sofa" don't you?) it's a good candidate for that.

On 29/01/15 18:06, Hugh Cayless wrote:

...

Can I make one more argument against the "never throw anything away" policy? Not only does it not really solve the cruft issue by just shoving it under the sofa, it also means a new set of procedures have to be established: what gets moved? How do I decide whether to stuff a thing under the sofa or delete it? How much documentation does there need to be for these things? I think it adds work and cognitive load when all we really need to do is delete it. If someone wants to know how we did things in 2012, they'll revert the repo to an appropriate commit and poke around. If we do this, I bet in a few years the obsolete branch will get nuked anyway. Because nobody will ever use it.

Still, if you really want to, at least I can ignore it :-).

On Thu, Jan 29, 2015 at 12:36 PM, Syd Bauman wrote:

It seems no one has *done* this yet. I think it's a really good idea.

...

I think Hugh is, in general, right -- it's OK to nuke stuff, that's why it's in a version control repository. That said, in the TEI universe where the cadre of those responsible for the repository changes over time, I'm more inclined to Martin's clever obsolete/ sibling of branches/, tags/, and trunk/. Besides, that way we could easily reverse the decision, and delete things from obsolete/. (Could reverse decision and recover deleted stuff if needed, too, but much harder.)

But IIRC (and I'd love to be wrong on this), it is not easy in Subversion to ascertain from where a directory was moved. So a check-in comment like "moved .../trunk/duck/quack/waddle/ to .../obsolete/waddle/" would be a good idea, no?

I'm happy to file a ticket, assign it to myself, and do this. I hate cruft.

True. But not everything needs to be kept in the attic. It's ok to

...

get rid of stuff when it's no longer useful.

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

Am 29.01.2015 um 19:31 schrieb Hugh Cayless :

Deletion *is* an option, because everything can be recovered. I’m with Hugh here. The cleaner the repository is, the easier for newcomers to make their way through. That said, we are always desperately in need of human voices of history who will tell what’s been there and where to find it.

Best Peter

I am with Hugh and Peter here. Am 30.01.2015 13:27, schrieb Syd Bauman:

I think deletion is better than bothering with the "simply move obsolete/ directory" option. HOWEVER, far better than either of these is to *annotate* the old stuff.

The one reason against deletion is, that it becomes a bit difficult to find deleted stuff in SVN. One way to make this easier would be to have a HISTORICAL_README with the deletions documented or, which I would prefer, a tag in the commit message saying "DELETE filename" (or maybe repopath). Then it is quite easy to spot deletions without having to svn diff. Deletion also has the benefit that the stuff that has been deleted is, when going back to the revision where it has still been present, in the context where it has been used (which is obviously important to properly understand the deleted artefact) kind regards, Stefan -- Mag. Stefan Majewski Projektmanager Abteilung Forschung und Entwicklung Österreichische Nationalbibliothek Josefsplatz 1, 1015 Wien Tel.: (+43 1) 534 10-434 E-Mail: stefan.majewski@onb.ac.at Skype: stefan.majewski.onb.ac.at

If the majority is in favour of deletion rather than hiding under the sofa, do we have a consensus as to which of the items listed in my pedvious message on this thread should be deleted? and on the criteria for deletion? On 30/01/15 13:26, Peter Stadler wrote:

...

Am 30.01.2015 um 14:19 schrieb Majewski Stefan :

The one reason against deletion is, that it becomes a bit difficult to find deleted stuff in SVN. One way to make this easier would be to have a HISTORICAL_README with the deletions documented or, which I would prefer, a tag in the commit message saying "DELETE filename" (or maybe repopath). Then it is quite easy to spot deletions without having to svn diff. `svn log -v` will give you the information whether a file was added, modified or deleted …

Peter

Since I was the one who originally proposed /obsolete/, IIRC, I'll respectfully retire. But I have in the past spent an awful lot of time checking out various revisions of huge repos in an attempt to find something that got deleted without proper record-keeping, so please, if you do delete something, submit a detailed commit message saying what it was, what it was called, and why it's being deleted. "Cleaned up cruft" isn't helpful when you're trying to find something that you vaguely remember was an XSLT file that did something interesting with respStmts. Cheers, Martin On 15-01-30 05:19 AM, Majewski Stefan wrote:

I am with Hugh and Peter here.

Am 30.01.2015 13:27, schrieb Syd Bauman:

...

I think deletion is better than bothering with the "simply move obsolete/ directory" option. HOWEVER, far better than either of these is to *annotate* the old stuff.

The one reason against deletion is, that it becomes a bit difficult to find deleted stuff in SVN. One way to make this easier would be to have a HISTORICAL_README with the deletions documented or, which I would prefer, a tag in the commit message saying "DELETE filename" (or maybe repopath). Then it is quite easy to spot deletions without having to svn diff.

Deletion also has the benefit that the stuff that has been deleted is, when going back to the revision where it has still been present, in the context where it has been used (which is obviously important to properly understand the deleted artefact)

kind regards, Stefan

We do this in EpiDoc using an svn:external that pulls the latest tagged copy in from its github repo. So there isn't actually a copy in the repo, but when you check it out or update, you get one. On Fri, Jan 30, 2015 at 8:42 AM, James Cummings wrote:

With regard to the Stylesheets that were there... there is a possible argument for having a local to TEI SVN copy of the Stylesheets. We use them for Guidelines production and of course just use the version on github. But we could take a copy of this at each of its releases and use that for the next release not then suddenly having surprises appear as changes continue to be made. So TEI Guidelines production as a consumer of the TEI Stylesheets not in a change-by-change kind of way but at stable releases.

Just throwing out the idea as food for thought.

-James

On 30/01/15 13:30, Martin Holmes wrote:

...

Since I was the one who originally proposed /obsolete/, IIRC, I'll respectfully retire.

But I have in the past spent an awful lot of time checking out various revisions of huge repos in an attempt to find something that got deleted without proper record-keeping, so please, if you do delete something, submit a detailed commit message saying what it was, what it was called, and why it's being deleted. "Cleaned up cruft" isn't helpful when you're trying to find something that you vaguely remember was an XSLT file that did something interesting with respStmts.

Cheers, Martin

On 15-01-30 05:19 AM, Majewski Stefan wrote:

...

I am with Hugh and Peter here.

Am 30.01.2015 13:27, schrieb Syd Bauman:

...

I think deletion is better than bothering with the "simply move obsolete/ directory" option. HOWEVER, far better than either of these is to *annotate* the old stuff.

The one reason against deletion is, that it becomes a bit difficult to find deleted stuff in SVN. One way to make this easier would be to have a HISTORICAL_README with the deletions documented or, which I would prefer, a tag in the commit message saying "DELETE filename" (or maybe repopath). Then it is quite easy to spot deletions without having to svn diff.

Deletion also has the benefit that the stuff that has been deleted is, when going back to the revision where it has still been present, in the context where it has been used (which is obviously important to properly understand the deleted artefact)

kind regards, Stefan

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived