Remove SVN and CVS artifacts

[tgraham-antenna]

This moves everything in trunk up one level and removes the trunk directory.

It also removes .svn, CVS, .hgignore, and .DS_Store files/directories left over from previous incarnations.

(It's also a bit too much of a change to just commit without warning.)

[vincentml]

Is there anything to prevent this pull request from being merged? This pull request has been open for some time. Keeping these anachronisms from SVN and CVS in the main branch might start to cause some problems.

[phax]

I think the problem is, that nobody is actively maintaining this repository. Last change: 6 month ago...

[vincentml]

@phax I saw @tgraham-antenna a few weeks ago at Balisage and we talked about Schematron. This repository is the "home" of the Schematron skeleton XSLTs and is maintained. However a big concern is to not break anything by making changes. A test suite is needed, as is being discussed in issue #49. If you are able to help, for example by contributing test cases, that would be most helpful.

[phax]

@vincentml I'm more the Java guy (see https://github.com/phax/ph-schematron) and not the XSLT/Schematron guy. But if there is anything I can help (like batch execution or the like), drop me a note :)

[tgraham-antenna]

The reason why its not merged is the number of PR against the existing HEAD.

Maybe it's my lack of Git foo, but it took contortions to update the branch recently, and, e.g., e2399d6 now shows up in the network diagram three times. I don't want the contortions to have to be repeated for every PR.

This PR is about to become obsolete anyway. I think that the non-'schematron' directories under 'trunk' will now go straight to each being a separate Git repository. (Unlike the new 'schematron-test' repository, they won't reappear as submodules of the 'schematron' repository.)

[tofi86]

Alright, I can understand that you didn't want to break the existing PR's. But what if people send more PullRequests and we stick to the old SVN base forever? Does this make more sense?

IMHO we should decise on the repo structure as soon as possible to have a clean base repository.

[tgraham-antenna]

I should have just committed this at the time rather than wait for approval.

I think that the thing to do now is to break up the current project into multiple projects and then remove the SVN/CVS/Hg/Eiffel artifacts from each individually. The 'trunk/schematron/test' directory is now a submodule, and that's not reflected in this PR.

To Do:

• trunk/ant-schematron/ -> 'ant-schematron' project
• trunk/converters -> 'converters' project
• trunk/xsd2sch -> 'xsd2sch' project
• trunk/schematron/code files move to base directory of 'schematron' project
• Remove SVN/CVS/Hg/Eiffel artifacts from each
• 'schematron' project renamed as 'schematron-xslt2'
  GitHub will redirect the old project URL to the new
• Any dependencies between current trunk subdirectories are recast as submodule dependencies
• Test everything against the comprehensive test suites just to make sure that it all still works.
• 'schematron-xslt2' project gets forked to become 'schematron-xslt1' (Upgrade Schematron compilation XSLTs to XSLT 2.0 #55)

[tofi86]

That sounds like a good plan! Thanks Tony! Let me know if I can help you somehow...

[vincentml]

This proposed restructuring should make it cleaner to import Schematron XSLTs into other projects. For example, a git submodule importing schematron-xslt2 or schematron-xslt1 would import only that Schematron XSLT implementation.

[tgraham-antenna]

Yes, it should be cleaner.

Ideally, the structure of the submodule files and the structure of the files that you unzip from a release would be identical (since the release would be a subset of the module's files). That way, it shouldn't matter if another projects starts with an unzipped release and then 'upgrades' to using a submodule or if the project's source uses a submodule and the project's releases expect an unzipped Schematron release at that position in the project's release's code.

[tgraham-antenna]

If you want to help, you can pick a project and, after the project is created, do the per-project cleanup and get the (new) project working again.

For projects that depend on the Schematron XSLT code, that's (at least) a two-step process. The existing versions of the new project's code in the 'schematron' project can't be removed until the new project is shown to work, and the contents of trunk/schematron/code can't be elevated to the base directory until all of the new projects are shown to work. That means that a new project that depends on the code in trunk/schematron has to be made to work with a 'schematron' submodule that has the current 'schematron' code structure and later has to be revised to work with the Schematron code elevated to the base directory.

Frankly, I don't know if 'ant-schematron', 'converters', or 'xsd2sch' currently work and/or can be built at all. There were/are assumptions about directory structure in the preexisting test directory that weren't reflected in the repository structure (but that's less of a problem with SVN, where you can check out parts of a repository in different places). I don't know what echoes of previous machines still exist in other directories.

[tgraham-antenna]

'ant-schematron' now exists as a separate project. The build.xml file for testing 'xsd2sch' uses ant-schematron.jar, hence the priority. 'xsd2sch' also has an XProc pipeline file, but I haven't tried that yet.

Schematron/ant-schematron#1 asks @rjelliffe if he has a build file for ant-schematron.jar, otherwise someone will have to make a new one.