Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Article Syndication on GitHub via Subversion

DZone's Guide to

Article Syndication on GitHub via Subversion

· DevOps Zone
Free Resource

The DevOps Zone is brought to you in partnership with Sonatype Nexus. The Nexus Suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

I’m so excited. I’ve just made a proof of concept of the article-syndication idea I previous wrote about. The proof of concept is entirely demonstrated on GitHub.

Previous Blockers

  1. Submodules in Git were whole branches/repositories
  2. Files in submodules cannot diverge from the original.

So Submodules were out, until the Git team upgrade them to a) allow maintained divergence, and b) sub-directories to be tracked rather than the whole repo.

How I’ve pushed past that

Easy. Just use the Subversion support on Github. Read on …

A hypothetical case

We going to syndicate a single file from one repo to another. Actually that’ll be a single directory because of a subversion limitation. We’re not going to track anything else from the original repo, and for fun, we’re going to map it into another directory. We’re going to have a modification to the original, and a separate modification to the syndicated one.

The timeline for that case

Step by step

Both repos exist on GitHub, as this isn’t just a hypothetical case.

Repo #1: https://github.com/paul-hammant/little-experiment

Repo #2: https://github.com/paul-hammant/subversion-experiment

The first is a pure Git thing that has a single resource that’s relevant. That resource a file called “test” in a sub directory called ‘subdir’. Here, take a look at its history

As you can see, ‘test’ has two commits. One that is the copy/paste from wikipedia for some of their ‘Lorum Ipsum’ page.The second is the addition of some other text, specifically -

The second repo was created empty. I made it after the first commit for repo #1, and before the second commit that added “its fleece was white as snow”. Repo #2 has a directory called ‘foo’. Inside that I did:

svn checkout https://github.com/paul-hammant/little-experiment/trunk/subdir

Yes, that’s created ‘subdir’ its pesky .svn folder and the ‘test’ file that we wanted. Subversion maintains the .svn folder and some of the things within it are text, and some binary. It even has a second copy of ‘test’. Don’t sweat that. We want it, and we’re going to check it in to Git/GitHub. Git’s Compression will reduce the cost of the duplicate. Here is the history for ‘subdir’. Click that and you’ll see:

The the right of the three number in red boxes, are buttons to navigate to the three commits. The first commit ‘354a3fd8d4’is the original ‘test’ file being checked in (twice because of that .svn folder). The second commit added “Mary had a little lamb” like so:

The third commit was where, on the command line, I did ..

cd foo/subdir
svn up
cd ../..
git commit -m "upstream publications changes pulled into syndicated version (that had maintained divergence)"

It merged the upstream text change without complaint. Of course given I checked in the .svn folder, it’s changed a bunch of stuff in there too. I’m not particularly worried about that, as it is a small cost for the ‘maintained divergence’ that I’m wishing for.

After that Merge, Subversion thinks the file is modified. Too bad, it’s not going to be committed back to any Svn repo:

cd foo/subdir
svn st 
M       test

Last thoughts.

Ordinarily you would never use Git and Subversion like this together, but I am very deliberately ignoring the Git-Svn best practice and toolchain. See the “Previous Blockers” above.

We should also consider a ‘tooling cost’ to this design. Specifically ‘git pull’ is not going to do ‘svn up’ for you. You’re going to need a new mechanism to check for (or consume) upstream changes. Similarly, the upstream repository is not going to find it easy to take back cherry-picked changes which is desirable for spelling and other corrections.

The directory ‘subdir’ has to be syndicated because of a limitation of subversion’s checkout. All we really wanted was ‘test’, but we have to have the director too. That said, it can easily be renamed under Git, and still be connected to the correct directory upstream.

Yeah, and I kinda wish I’d done some examples using Jekyll and markdown articles to simulate how newspapers or content publishers would do this.

The DevOps Zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

Topics:

Published at DZone with permission of Paul Hammant, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}