when we switch from svn.perl.org to trac, consider using git

[Infinoid]

There are a few plugins available for using git with trac:

 http://trac-hacks.org/wiki/GitPlugin

 http://nanosleep.org/proj/trac-git-plugin/

 http://trac-hacks.org/wiki/GitwebPlugin

[jkeenan]

On the one hand, thanks for putting this in the form of a Trac ticket. We've had many changes in our infrastructure lately, but, IMO, inadequate on-list discussion of why we've made these changes.

On the other hand, count me opposed. We have had quite a few changes in our infrastructure lately, forcing all of our developers to spend time learning new tools. If git users can access our SVN repository, great. But I oppose yet another version control system change just because git is the shiny new toy.

Thank you very much.
kid51

[Infinoid]

Replying to jkeenan:

On the other hand, count me opposed. We have had quite a few changes in our infrastructure lately, forcing all of our developers to spend time learning new tools. If git users can access our SVN repository, great. But I oppose yet another version control system change just because git is the shiny new toy.

Obviously my vote is +1 (otherwise I wouldn't have posted the ticket), but not because it's the shiny new toy. I would like to see git on the server side, because it will ease branch merges. Yes, svn 1.5 has improved this somewhat, but we still run into problems (the recent "bcanno" branch merge is one example I'm familiar with), and going through git-svn severely limits how much it can help with that situation.

If possible, I'd like to see some kind of bidirectional gateway in place, so that svn users can continue using svn without having to care. But I am specifically requesting that git be used as the backend storage system, independent of whatever user interface(s) are available to stick in front of it.

[coke]

For those of us who aren't git users, seeing an example of how branches will be both sharable (as they are now) and more easily mergable would definitely help sway the undecideds. (Presuming our new hosting overlords can even accomodate this request.)

[tene]

+1 because the ability to use git directly instead of through git-svn would make my development experience more pleasant.

possible -1 if this would cause problems for anyone or hinder anyone's progress. This only applies if anyone can identify specific problems, and those problems are greater than the problems with svn. It might be helpful to list the problems with svn? I remember people complaining about merges, committing to tags, deleting all of the branches, merges, and metadata. I haven't personally dealt with any of those, though. All I know is that every time I have to touch SVN directly I break something, but that's probably better attributed to personal problems.

[whiteknight]

+1 I'm not currently a git user, but I've heard some good things about the software and am always willing to learn a new tool. Any software that is going to do more to help us and less to hurt us, even if it includes a reasonable learning curve, should be preferred. SVN is a nice tool, and if we do switch to GIT I definitely agree that there should still be an ability to use SVN if people prefer.

[particle]

-1

we are already behind on our ParrotRoadmap goals for 1.0, which has put considerable pressure on our already-constrained all-volunteer resources. this change will not only affect all contributors, but it will cause rework to existing documentation, both in the repository, and on parrot.org. it affects the entire parrot community, at a time where we need their help more than ever. i seriously hesitate add any more dependencies to our tight schedule.

i propose we stick with svn through 1.0 and revisit this item afterward. ~jerry

[Infinoid]

Replying to coke:

For those of us who aren't git users, seeing an example of how branches will be both sharable (as they are now) and more easily mergable would definitely help sway the undecideds. (Presuming our new hosting overlords can even accomodate this request.)

Sure, examples are easy. (Note that I'm not actually a git expert, so there may be better examples than the ones I explain here.)

Take for example jq's Language::Befunge project,  http://repo.or.cz/w/language-befunge.git . In this project are several long-lived branches, one per contributor. (This isn't necessarily the recommended form of branch usage, the organization is more or less arbitrary.) The "master" branch is the trunk, for all intents and purposes.

When changes from one branch are merged into another, their history is preserved. This happens more literally than it does in svn; a branch merge in svn results in a single commit, whereas in git, the full list of changes from one branch are copied to the target branch, directly. See for example the latest changes in my branch,  http://repo.or.cz/w/language-befunge.git?a=shortlog;h=refs/heads/mark-stable . Those changes were merged back into master (trunk) back in july, as you can see most of the way down the page here:  http://repo.or.cz/w/language-befunge.git?a=shortlog;h=refs/heads/master .

Taken by itself, this semantic allows fine-grained management of conflicts. If a conflict occurs, it only affects a single commit, and thus it is easier (during manual review) to see the scope and intent of the commit.

Next, when you resolve a conflict, the changes you make become a (specially marked) commit of their own. That means, you can keep your branch up to date with respect to trunk, and in fact by doing so, you are guaranteeing that the changes in your branch will apply cleanly to trunk. If (by comparison) you do this with svn, you are in fact making merging *harder* later on, by making the branch topology complex (non-linear).

In an earlier post, I alluded vaguely to the bcanno branch. It makes a good example, so I will detail here. The branch was created in r33279, had various local changes applied, had the meantime changes from trunk merged into it (r34985), spent 3 subsequent commits cleaning up the fallout from that merge (r34986, r34987, r34988), made some more local changes, merged trunk changes into the branch again (r35024), made the final touches, and then had trunk changes synced in one final time in preparation for merging it back to trunk (r35048). Jonathan mentioned having some problems with that, and this was the state I found the branch in when I volunteered to do the merge.

So I innocently made a fresh trunk checkout and tried to do "svn merge  http://svn.perl.org/parrot/branches/bcanno". I had a sufficiently recent version of svn, so my syntax was accepted. As the various conflicts came up, I elected to (p)ostpone them. so they would show up in "svn st" as C and let me fix them up later. It chewed on it for a while, and eventually kicked out an obscure error message and exited. (I can't be more specific because I can't reproduce this any more, as the bcanno branch has been removed.)

With git, this simply wouldn't have happened. This is because Jonathan had already *done* the merge (r35048). When merging bcanno into trunk, git would have realized this fact (from the existence of the specially marked merge commit) and just made trunk's commit history identical to that of bcanno's, so no more actual "merging" was required.

Now, svn's branch merging support is slowly improving. But it didn't work in this case, so I was forced to resort to extreme measures (take a checkout of r35048 of the bcanno branch and trunk, remove all the ".svn" files from bcanno, "cp -a" all of the files into the trunk branch, then "svn update", clean up any additional conflicts and commit it) which didn't preserve change histories, and for me, removes a lot of confidence in the tool.

For the curious, I think svn's problematic behavior could be reproduced by recreating the same branch tree topology.

Mark

[barney]

Replying to Infinoid:

Replying to coke:

+1 for moving to git.

I haven't worked with git yet, but what I've heard and seen about git is very convincing. My selfish reason for having Parrot code managed in Git, is that I want to move Pipp to Github. I suppose that this would be easier when Parrot is already in Git.

[Infinoid]

Replying to barney:

I haven't worked with git yet, but what I've heard and seen about git is very convincing. My selfish reason for having Parrot code managed in Git, is that I want to move Pipp to Github. I suppose that this would be easier when Parrot is already in Git.

I don't know if this comment helps my request any, but... I don't think changing parrot's SCM will affect your move much, either way.

Mark

[Infinoid]

Allison has announced to parrot-dev that they are moving to svn.parrot.org today, thus, the answer seems to be "no". Closing ticket; will look at setting up some kind of bidirectional gateway as an interim solution. We should revisit this after 1.0.

[allison]

We certainly won't be moving to git or another alternative source control system before 1.0. That kind of tool change is too disruptive to developer productivity. And, the developers that do prefer git can already use it through git-svn. (perl.org has been running a git mirror or the parrot repository for months now, but AFAIK no one is using it.)

I imagine we will talk about infrastructure changes periodically, as new tools become available. So, I'll give my perspective on git for those future conversations. I don't see git as a good fit for the Parrot development model. The whole point of git is that there is no centralized repository. Instead, each developer has their own repository, and they trade changes back and forth. It was designed for the Linux kernel development model, where anyone can do work, but ultimately Linus decides what does or doesn't go into a release. The canonical source for cutting a release of the kernel is Linus' git repository.

In Parrot, we've taken a completely opposite approach. We've intentionally worked to remove "single points of failure", where any one part of the development process can be entirely blocked on one person. (For example we have multiple release managers in rotation, to share the load, and so any one of them can take over a particular release if needed.) And, from a personal perspective, Linus is full-time funded to work on the Linux kernel and can afford to spend all his time reviewing every change before it touches the "main" repository. I'm not. I'm quite glad that we have a whole group of experienced committers who review and apply patches, and who watch the commit logs and vet changes. That's the Parrot way.