a git plan, long term

[Ian Young]

On 6 Aug 2013, at 21:12, Tom Zeller <tzeller at dragonacea.biz> wrote:

> On the last dev call I had a note regarding git, more thoughts follow.

Just some thoughts from me too.

> I like the idea of migrating to git mostly because all history is
> local, which I think would help my workflow.

I think there are various workflow advantages to Git, but they only benefit people who use Git in a Git-like way.  All you get before that is maybe a bit better performance, offline working and (probably) a bit of a brain ache.  So the time before we start to get value back from a move to Git is dependent on how long we take to learn what "Git-like" means.  People who have already had their brains gitified would probably see value more quickly.

The biggest workflow advantage I see from any of the distributed SCMs is the ability to work independently of the central repository for experiments or features while still getting the benefits of source control.  Whether you eventually decide to push all or just some stream of work back "up" becomes more of a personal choice.  Under a centralised SCM, you have to choose between checking in half-baked stuff you might regret and losing source control altogether.

The other thing is the branching model, of course.  We *never* branch in Subversion, as a matter of policy, except when establishing a new minor release line.  Let's just say that "native" Git users branch a lot more than once every couple of years, perhaps as often as for every new piece of work (i.e., potentially even more than once a day).  Many of those branches evaporate away so that a central repository doesn't necessarily make that visible.  Properly understanding how Git-based projects use branches would probably be an important part of any migration.

One side benefit of Git is that all that branching and merging and whatever for new work can be done locally, and that means that it does not require commit access to the project repository.  This doesn't benefit insiders directly, but means that the project is more open to contributions from non-committers.

That also brings me to Github, where a fair proportion of the Git-using community hangs out.  I think this is partly because of the free hosting, but also because the fork-hack-pullrequest workflow they enable is really rather nice for relatively small projects.  I think we'd have trouble with it, though, mainly because their issue tracking is pretty primitive but not least because their ToU has some questionable liability language.  If we did feel able to sign up to their terms, though, I think a case could be made for hosting there (or automatically mirroring repositories there) and just turning off their issue tracking stuff.  This is more or less what Linus appears to have done for the Linux kernel sources (he has rather strong negative feelings on Github-generated pull requests, and doesn't accept them).

> However, I think changing our source code repository before the next
> major version is released would extend our timeline, which seems
> undefendable to me.

You may be right that it's not likely to be a net win over the V3 timeline.  You obviously think it would have value for your workflow, though, so whether it extends our timeline or not is obviously a question of balancing that benefit against the cost.  The balance will probably be different for each of us.

> That being said, I encourage estimating a git migration plan, if that
> can be done in a limited amount of time by someone who has the time.
> Especially if the community has relevant experience.

I'm hoping that having me say a few things will prompt some others to contradict me ;-) so that we can have a real discussion.  I've already had my brain bent enough to be half way towards thinking in Git, so I'd personally be quite keen to move forward, even if just in an experimental way.

I've also spent some time recently converting some existing Subversion repositories to Git:

	https://github.com/ukf

That experience was somewhat mixed.  There are a couple of scripts available, but it took me a while to figure out all the options required to get a decent conversion.  Even when I had those down, each repository I converted turned up some new wrinkle I hadn't considered.  I also ended up wanting to rewrite the tags in a couple of my repositories as signed tags so there was some more fiddling around with that.  So there were several failed attempts before I declared victory in each case.

One thing that wasn't the case in my repositories but is a potential issue for the Shibboleth repositories is that we currently make use of Subversion externals for the Eclipse .settings directory.  I believe I am right in saying that this particular form of Subversion external is now available in Git, although more complex forms are not.  So I don't think there would be a problem in automating that part of the conversion if required, although it will require some changes to the scripts for making new modules, locking parent project versions and the like.  Having said which, I personally dislike the whole externals (in Git, submodules) concept and if we could find a different way to share Eclipse per-project settings we should take the opportunity to see if we can move away from that.

If we think it's worth putting a toe in the water, converting a couple of the V3 repositories (e.g., the parent POM and OpenSAML) and hosting them in a personal account on github pro tem wouldn't take a lot of effort.  I know Rod tried an experiment along those lines with the IdP project though, so perhaps we already know how that panned out?

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20130807/00efe986/attachment.bin