Skip to content
This repository has been archived by the owner on Nov 2, 2020. It is now read-only.

Remove SVN and CVS artifacts #31

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

Remove SVN and CVS artifacts #31

wants to merge 10 commits into from

Conversation

tgraham-antenna
Copy link
Member

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
Copy link
Member

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
Copy link

phax commented Aug 10, 2017

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

@vincentml
Copy link
Member

@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
Copy link

phax commented Aug 17, 2017

@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
Copy link
Member Author

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
Copy link
Contributor

tofi86 commented Feb 8, 2018

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
Copy link
Member Author

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
Copy link
Contributor

tofi86 commented Feb 12, 2018 via email

@vincentml
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member Author

tgraham-antenna commented Feb 13, 2018

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
Copy link
Member Author

'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.

@tgraham-antenna tgraham-antenna added the infrastructure Housekeeping label Feb 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
infrastructure Housekeeping
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants