Separate code repo from site repo?

[iangilman]

I'm coming to the conclusion that we should have one repo with just the source code for OpenSeadragon and another one for the site, including a built version of openseadragon.js. This will take care of #11, and generally keep things cleaner.

Any thoughts?

[Ventero]

Keeping the site code in a separate repository is definitely a good idea, and I guess it would make sense to have a built version of openseadragon in that repository as well. Another option for the built version is to simply attach it as a download to this GitHub repository, whenever you think it's a good idea to make a release.

[bgilbert]

@Ventero: GitHub no longer supports attached downloads.

@iangilman: What repository name and branch were you thinking of using for each piece? If you want to retain the current website URL, the site must be stored in the gh-pages branch of thatcher/openseadragon. (If you want to change URLs, that branch will still need dummy pages with meta refresh tags, since GitHub Pages doesn't support proper redirects.)

[Ventero]

@bgilbert Huh, interesting. Thanks for letting me know!

[iangilman]

I've created a new organization, http://github.com/openseadragon, and we can host the new repositories there. Of course we'll redirect from the old gh-pages site to the new one.

While I'm at it, I'm thinking of hooking it up to something like https://travis-ci.org/ (which might mean moving to a different build system, possibly http://gruntjs.com/). We could add bells and whistles like minimization and unit tests...

[iangilman]

As for the branch names, I'm thinking the site would be info (therefore http://openseadragon.github.com/info) and something like core for the actual code.

[bgilbert]

Nice. Since you have a dedicated organization, it probably makes more sense to create an organization page rather than a project page. So you would use the master branch of a repo called openseadragon.github.com, which would be served from the root of http://openseadragon.github.com/.

May I suggest openseadragon as the repo for the code? git clone https://github.com/openseadragon/core produces a local directory named core by default.

[thatcher]

It can be hard to keep up with the pace of change of github as a technology while keeping up with development at work and outside of work. Can you point us at some github documentation pages that describe these conventions so we can read up and try to plan around the state-of-the-art? Last I checked gh-pages branch was the only web publishing option, or maybe it was just the soup-de-jour, though I wouldnt doubt I missed other options or just havent kept up. Links please!

Thanks, Thatcher

[bgilbert]

Here are the options. You can also use a custom domain.

[iangilman]

Awesome, thanks for the pointers (and the naming suggestion). I'll keep you updated on the progress. :-)

[iangilman]

Here's a ping to all the folks who have forks of OpenSeadragon so you know the repo is on the move (or will be sometime in the coming weeks). If you've got any changes you'd like to merge in to this master version, now is a good time. @josh1093, @ewaters, @macreery, @chonselaar2, @cdchapman, @acdha

[acdha]

Excellent - looking forward to the switch!

[edsu]

Nice to see a community forming around this!

[iangilman]

Ok, I think the new openseadragon organization will have three repos:

• openseadragon: The actual code plus build (concat and minify) and tests. This repo will be hooked to Travis for automated testing.
• site-build: The build script for the site, as well as the documentation generator.
• openseadragon.github.com: The actual built public website (including the highsmith example).

Most people will only need the first repo. For those making modifications to the public website, it's assumed you'll have all three repos next to eachother (in the same directory). Updating the site will involve running the script in site-build and then checking the result into the openseadragon.github.com repo.

For the time being at least, we'll use Grunt for building the openseadragon repo (since that's friendly to Travis) and continue to use Ant for building the public site, since it's already set up that way.

I plan to set up the new public site repo first, then convert thatcher/openseadragon to Grunt, and finally, once we're happy with everything, filter out highsmith and push to the openseadragon organization. No firm time frame yet; hopefully within the next few weeks.

[bgilbert]

It might be better for the site-build script to manage captive openseadragon and openseadragon.github.com checkouts stored within its own directory (and listed in its .gitignore), rather than making assumptions about its parent directory structure. That approach has worked well for me in my own projects. It allows the script to ensure the repos are synchronized with origin and in a known state, e.g.:

[ -d openseadragon ] || git clone https://github.com/openseadragon/openseadragon
pushd openseadragon && git fetch && git reset --hard FETCH_HEAD && git clean -dxf && popd

The other approach risks incorrect site builds if ../openseadragon isn't in the expected state.

Also, to be clear: do you intend to overwrite the current history of the openseadragon/openseadragon repository?

[Ventero]

Or you could add openseadragon and site-build as submodules to the openseadragon.github.com repository (or vice versa). If I'm not mistaken, that's more or less the same as @bgilbert's approach, but it's directly supported by git.

[bgilbert]

With submodules, each commit in the main repository links to a specific commit in the submodule repositories, which doesn't make much sense here. The site-build HEAD shouldn't have to be updated when openseadragon changes, or when openseadragon.github.com changes.

It might make some sense for openseadragon.github.com to pull in the other two repos (i.e., its dependencies) via submodules, but IMO that's very awkward for little gain.

[Ventero]

I might be misunderstanding something here, but @iangilman's post sounds to me like openseadragon.github.com has a dependency on site-build, which in turn has a dependency on openseadragon.

I agree that having site-build as submodule in openseadragon.github.com is a bit awkward, but having openseadragon as submodule of site-build does make sense in my opinion. That way site-build wouldn't necessarily always use openseadragon HEAD to build the site, but instead could the submodule could be updated whenever an new stable/official version of openseadragon has been released.

[thatcher]

see issue #11 as Im going to be taking a stab at this today

[iangilman]

Sorry I've been quiet; been out of town. My thought is that openseadragon.github.com would more or less just be the results of a build; all of the actual files necessary to create the site would reside in site-build. The one exception to this being the DZI folder, since it's so huge and won't be changing frequently (another option would be to have a separate dzi-examples project that publishes itself through gh-pages).

site-build would have no direct dependency on the openseadragon repo, since we'd want to bless stable releases. For starters we may just transfer the stable release manually into site-build, but using sub-modules is an intriguing solution to explore.

And yes, we will be keeping the git history for the openseadragon repo (minus the highsmith example).

[iangilman]

This has now been done. The new repositories are at http://github.com/openseadragon. The new website is not quite ready for prime time, but the repos should be ready for forking.