Infrastructure
  1. Infrastructure
  2. INFRA-7524

April Fools: migrate Apache Subversion project over to the git repo

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not A Problem
    • Fix Version/s: Apr 2013
    • Component/s: Git
    • Labels:
      None

      Description

      Grrrr... vote passed. Not happy, but here we go:

      Infra: please migrate our repository at /repos/asf/subversion/ over to the Git repository stuffs.

      We already have the mirror at git.apache.org. But that has always been there as a read-only mirror (along with the copy over to GitHub). Will the git repo be at git-wip.apache.org? (is it *still* considered -wip "work in progress"?)

      Not sure what else you guys need. Haven't exactly studied up on the migration process. Please let me know.

      (tho I'm up late here now and need to sleep soon; others from the PMC will be able to help)

        Activity

        Hide
        Daniel Gruno added a comment -
        Ack, we'll get started on this issue.
        The git repo (both the original subversion and the new git) will be read-only until you have verified that the contents and structure is okay.
        Once you verify that (in this ticket), I'll open up the repo for write access and expect you to use that repo instead of the subversion directory.

        For starters, let me know when you are satisfied with the go-ahead (please inform your committers than the subversion repo will also be read-only during this process), and I'll start the process:
        1) Set svn repo to read-only
        2) Initialize a new read-only git repo from the subversion repo
        3) Have you (or the PMC) verify that the new git repo is sane
        4) Open up write-access to the new git repo
        5) Open up write access to the subversion repo (which is still required for web sites with CMS)
        Show
        Daniel Gruno added a comment - Ack, we'll get started on this issue. The git repo (both the original subversion and the new git) will be read-only until you have verified that the contents and structure is okay. Once you verify that (in this ticket), I'll open up the repo for write access and expect you to use that repo instead of the subversion directory. For starters, let me know when you are satisfied with the go-ahead (please inform your committers than the subversion repo will also be read-only during this process), and I'll start the process: 1) Set svn repo to read-only 2) Initialize a new read-only git repo from the subversion repo 3) Have you (or the PMC) verify that the new git repo is sane 4) Open up write-access to the new git repo 5) Open up write access to the subversion repo (which is still required for web sites with CMS)
        Hide
        Greg Stein added a comment -
        Woah. Wait.

        We need to be able to keep working while we verify the migration. Can't you take a snap, migrate that, then (later) migrate any additional commits that came in after the snap?
        Show
        Greg Stein added a comment - Woah. Wait. We need to be able to keep working while we verify the migration. Can't you take a snap, migrate that, then (later) migrate any additional commits that came in after the snap?
        Hide
        Daniel Gruno added a comment -
        Protocol and common sense dictates that the repository must be read-only while we do the migration.
        Technically, we could keep the svn repo read/write while we migrate, but we honestly haven't done it like that before, so I'm not sure what the result would be.
        [~jfarrell] might have a better answer for you.

        The migration would perhaps take an hour or so, maybe less, surely you won't mind if we lock the repo for that amount of time?
        Show
        Daniel Gruno added a comment - Protocol and common sense dictates that the repository must be read-only while we do the migration. Technically, we could keep the svn repo read/write while we migrate, but we honestly haven't done it like that before, so I'm not sure what the result would be. [~jfarrell] might have a better answer for you. The migration would perhaps take an hour or so, maybe less, surely you won't mind if we lock the repo for that amount of time?
        Hide
        Stefan Sperling added a comment - - edited
        Don't worry, Greg. As promised before, nothing much will really change for you. However the migration is done, you'll still be able to use the svn client as before to work on the svn code base once we've finished up the remaining todo items on the ra-git branch: http://svn.apache.org/viewvc?view=revision&revision=r1583639

        Just wait a few days until that branch is mature enough to be merged to trunk. We'll switch over for real to git-wip.apache.org as soon as this is done. Until then, our git tree will remain read-only and we'll test it internally. Remember that Git is distributed :) We can test the migration without affecting the central repo!
        Show
        Stefan Sperling added a comment - - edited Don't worry, Greg. As promised before, nothing much will really change for you. However the migration is done, you'll still be able to use the svn client as before to work on the svn code base once we've finished up the remaining todo items on the ra-git branch: http://svn.apache.org/viewvc?view=revision&revision=r1583639 Just wait a few days until that branch is mature enough to be merged to trunk. We'll switch over for real to git-wip.apache.org as soon as this is done. Until then, our git tree will remain read-only and we'll test it internally. Remember that Git is distributed :) We can test the migration without affecting the central repo!
        Hide
        Greg Stein added a comment -
        Holy crap! ... sure, you told me not to worry (I still hate the vote result, despite the assurances) ... but I never suspected that solution.

        So I'll be able to use the *svn* client to check out from the ASF git repo? Awesome. I bet the GitHub peeps would love this. They have a whole proxy layer to allow svn clients to perform operations. If your new ra_git can build it *directly* into svn ... hotness.

        And yeah, I see how that helps us devs. We can dogfood svn against our own repo. Thanks, Stefan!
        Show
        Greg Stein added a comment - Holy crap! ... sure, you told me not to worry (I still hate the vote result, despite the assurances) ... but I never suspected that solution. So I'll be able to use the *svn* client to check out from the ASF git repo? Awesome. I bet the GitHub peeps would love this. They have a whole proxy layer to allow svn clients to perform operations. If your new ra_git can build it *directly* into svn ... hotness. And yeah, I see how that helps us devs. We can dogfood svn against our own repo. Thanks, Stefan!
        Hide
        Greg Stein added a comment -
        Daniel: we're still working on the 1.9 release. We just popped an alpha2 recently. Downtime isn't a good thing, and we're already a bit shaky doing this during the release process. (tho: the devs think swapping the backend *before* we push the release will be best)

        Can we do a test migration? I know it is more work for you guys. But maybe we can run a test, and when things look solid, we can take the downtime and do a migration again. It will also give me time to coordinate *when* our devs would be happy with the downtime.

        Thanks.
        Show
        Greg Stein added a comment - Daniel: we're still working on the 1.9 release. We just popped an alpha2 recently. Downtime isn't a good thing, and we're already a bit shaky doing this during the release process. (tho: the devs think swapping the backend *before* we push the release will be best) Can we do a test migration? I know it is more work for you guys. But maybe we can run a test, and when things look solid, we can take the downtime and do a migration again. It will also give me time to coordinate *when* our devs would be happy with the downtime. Thanks.
        Hide
        Jake Farrell added a comment -
        We can do the initial import to git with the svn repo in rw, though we typically try and avoid doing migrations that way. Open Office did it this way and they are still debating when to switch over officially. After verifying the initial migration we can move over the delta and then reverify

        [~gstein] I'll start the migration shortly, it will take awhile to move all history over and get the github mirror setup. When done your primary repo will be at https://git-wip-us.apache.org/repos/asf?p=subversion.git with emails going to the Subversion commits@ mailing list
        Show
        Jake Farrell added a comment - We can do the initial import to git with the svn repo in rw, though we typically try and avoid doing migrations that way. Open Office did it this way and they are still debating when to switch over officially. After verifying the initial migration we can move over the delta and then reverify [~gstein] I'll start the migration shortly, it will take awhile to move all history over and get the github mirror setup. When done your primary repo will be at https://git-wip-us.apache.org/repos/asf?p=subversion.git with emails going to the Subversion commits@ mailing list
        Hide
        Jim Jagielski added a comment -
        Hold on a tic. Just *where* did this vote happen?

        You all should know better than have these types of votes on the private list. I, for one, am incredibly surprised and shocked that Greg, of all people, let this happen.

        I'm sorry, but there's no excuse for this.
        Show
        Jim Jagielski added a comment - Hold on a tic. Just *where* did this vote happen? You all should know better than have these types of votes on the private list. I, for one, am incredibly surprised and shocked that Greg, of all people, let this happen. I'm sorry, but there's no excuse for this.
        Hide
        Bert Huijben added a comment -
        [~jimjag] Voting on something as controversial as this on a public list is just asking for an infinite discussion.

        We didn't discuss joining the ASF on our public lists either before the announcement.
        Show
        Bert Huijben added a comment - [~jimjag] Voting on something as controversial as this on a public list is just asking for an infinite discussion. We didn't discuss joining the ASF on our public lists either before the announcement.
        Hide
        Jim Jagielski added a comment -
        I just rec'd a phone call about this. Who is on task for handling press inquiries? I had to admit that I have no freakin' idea what's going on, which did NOT make me happy. Nor does it look good for us.
        Show
        Jim Jagielski added a comment - I just rec'd a phone call about this. Who is on task for handling press inquiries? I had to admit that I have no freakin' idea what's going on, which did NOT make me happy. Nor does it look good for us.
        Hide
        Tony Stevenson added a comment -
        Im staying ell out of this voting malarky, you lot can run your own ship, but that URL is live for review. Enjoy.
        Show
        Tony Stevenson added a comment - Im staying ell out of this voting malarky, you lot can run your own ship, but that URL is live for review. Enjoy.
        Hide
        Jim Jagielski added a comment -
        ~Bert: WTF is wrong w/ an infinite discussion?? If it's infinite its because there is NO consensus.
        Show
        Jim Jagielski added a comment - ~Bert: WTF is wrong w/ an infinite discussion?? If it's infinite its because there is NO consensus.
        Hide
        Richard Bowen added a comment -
        Greg, I know that you're doing this as VP Subversion, but, as a director, it seems like something you should have explicitly notified the board about. I mean, obviously the board shouldn't stand in the way of projects doing what they want, but, geez, dude, this kind of stunt looks bad for the Foundation and for the project. Frankly, as a director, you should never have let this vote happen on a private mailing list. You of all people should know this is a totally different thing than having a private vote about joining the foundation. I'm really disappointed, Greg. I really expect a lot better from you.
        Show
        Richard Bowen added a comment - Greg, I know that you're doing this as VP Subversion, but, as a director, it seems like something you should have explicitly notified the board about. I mean, obviously the board shouldn't stand in the way of projects doing what they want, but, geez, dude, this kind of stunt looks bad for the Foundation and for the project. Frankly, as a director, you should never have let this vote happen on a private mailing list. You of all people should know this is a totally different thing than having a private vote about joining the foundation. I'm really disappointed, Greg. I really expect a lot better from you.
        Hide
        Jim Jagielski added a comment -
        There is a part of me which thinks that this vote should be invalidated *immediately*. I'd prefer not bringing this up to board level, but I think maybe it requires it.
        Show
        Jim Jagielski added a comment - There is a part of me which thinks that this vote should be invalidated *immediately*. I'd prefer not bringing this up to board level, but I think maybe it requires it.
        Hide
        Mark Phippard added a comment -
        I guess we could have done more in public, but the intent was to make sure the Subversion PMC was more or less on the same page before we stirred up a hornets nest. While not everyone is in total agreement there was enough consensus to move forward. I thought PMCs were free to make their own technical decisions. And Infra definitely supports svn->git migration. Jim/Rich: why are you guys involved at all?

        I do not know how all ASF projects are organized, but with Subversion pretty much 100% of our developers with commit access are part of our PMC. So while we might not have involved our end users, I feel confident that the majority of the developers contributing to Subversion had a chance to weigh in.
        Show
        Mark Phippard added a comment - I guess we could have done more in public, but the intent was to make sure the Subversion PMC was more or less on the same page before we stirred up a hornets nest. While not everyone is in total agreement there was enough consensus to move forward. I thought PMCs were free to make their own technical decisions. And Infra definitely supports svn->git migration. Jim/Rich: why are you guys involved at all? I do not know how all ASF projects are organized, but with Subversion pretty much 100% of our developers with commit access are part of our PMC. So while we might not have involved our end users, I feel confident that the majority of the developers contributing to Subversion had a chance to weigh in.
        Hide
        Jim Jagielski added a comment -
        If subversion is like all other ASF projects, then the dev@ list contains a LOT of people that just the committers and/or PMC members. Recall that we have stated, over and over again, that ALL development is done in the open, on the dev@ list. That's because we want to engage the entire community, which is expected to be following the dev@ list.

        By handling this on private@ you have basically disenfranchised everyone on dev@ who isn't on private@, which, I'm sure, is a pretty significant number of people.

        I don;t share your "confidence" regarding people having a chance to weigh in. And now the decision has been made *for* them. !Good.
        Show
        Jim Jagielski added a comment - If subversion is like all other ASF projects, then the dev@ list contains a LOT of people that just the committers and/or PMC members. Recall that we have stated, over and over again, that ALL development is done in the open, on the dev@ list. That's because we want to engage the entire community, which is expected to be following the dev@ list. By handling this on private@ you have basically disenfranchised everyone on dev@ who isn't on private@, which, I'm sure, is a pretty significant number of people. I don;t share your "confidence" regarding people having a chance to weigh in. And now the decision has been made *for* them. !Good.
        Hide
        Jim Jagielski added a comment -
        To be clear, I don't give a fig if subversion moves to git or not. It's just that the PMC did not act openly. Community > Code.
        Show
        Jim Jagielski added a comment - To be clear, I don't give a fig if subversion moves to git or not. It's just that the PMC did not act openly. Community > Code.
        Hide
        Joe Schaefer added a comment -
        I would like to point out that the new community dynamic for git-based projects is different in many salient ways from a traditional subversion project. Voting in private, or even decisions by fiat of the chair, are most welcome in the new regime. It is good to see the subversion project embrace this new mode of project development in their smart exodus from the chains of the past.
        Show
        Joe Schaefer added a comment - I would like to point out that the new community dynamic for git-based projects is different in many salient ways from a traditional subversion project. Voting in private, or even decisions by fiat of the chair, are most welcome in the new regime. It is good to see the subversion project embrace this new mode of project development in their smart exodus from the chains of the past.
        Hide
        Jim Jagielski added a comment - - edited
        Joe: WTF are you talking about? I can't tell if that's sarcasm or what.
        Show
        Jim Jagielski added a comment - - edited Joe: WTF are you talking about? I can't tell if that's sarcasm or what.
        Hide
        Jake Farrell added a comment -
        While this is getting all sorted out can someone please verify the initial migration which is now complete and live.

        head at f6e7dea29d892bc0bef17e50977d40c236788e28. Mirror setup and Github integration done with initial hooks. pull request emails will go to the dev@ list, commits to commits@.

        Repo: https://git-wip-us.apache.org/repos/asf?p=subversion.git
        Mirror at http://github.com/apache/subversion
        Show
        Jake Farrell added a comment - While this is getting all sorted out can someone please verify the initial migration which is now complete and live. head at f6e7dea29d892bc0bef17e50977d40c236788e28. Mirror setup and Github integration done with initial hooks. pull request emails will go to the dev@ list, commits to commits@. Repo: https://git-wip-us.apache.org/repos/asf?p=subversion.git Mirror at http://github.com/apache/subversion
        Hide
        Tony Stevenson added a comment -
        Jeez, folks.

        This fora is not for discussing the semantics of project decisions. It is for the Infra team to be issued tasks, can you please take your vitriol and noise elsewhere please.
        Show
        Tony Stevenson added a comment - Jeez, folks. This fora is not for discussing the semantics of project decisions. It is for the Infra team to be issued tasks, can you please take your vitriol and noise elsewhere please.
        Hide
        Mark Phippard added a comment -
        Jake looks good. Are we supporting SSH access to Git@ASF or just https? Does Infra have recommendations/docs on process to follow with pull requests? Do we still need ICLA for pull requests?
        Show
        Mark Phippard added a comment - Jake looks good. Are we supporting SSH access to Git@ASF or just https? Does Infra have recommendations/docs on process to follow with pull requests? Do we still need ICLA for pull requests?
        Hide
        Jim Jagielski added a comment -
        Mark: This is exactly the kind of stuff (re: legal aspects re iCLA) that should have been thought about before going off half-cocked and pushing this thru. Please followup on legal-discuss@
        Show
        Jim Jagielski added a comment - Mark: This is exactly the kind of stuff (re: legal aspects re iCLA) that should have been thought about before going off half-cocked and pushing this thru. Please followup on legal-discuss@
        Hide
        Jake Farrell added a comment -
        [~markphip] right now just https for committing, we are working on ssh access and hope to have that when we merge git-wip and git.a.o later this year
        Show
        Jake Farrell added a comment - [~markphip] right now just https for committing, we are working on ssh access and hope to have that when we merge git-wip and git.a.o later this year
        Hide
        C. Michael Pilato added a comment -
        I'm not sure this discussion is trending towards a positive conclusion. I'm starting to see that this ticket is getting a bit of external attention -- which I suppose is understandable -- but all that really means is that the world is watching not just what Subversion does with its source code, but also how the Foundation handles potentially contentious PMC decisions. For the good of the project and the Foundation, let's step back a bit, cool down, and try a more productive approach.

        I can certainly understand why the Board might be concerned about the manner in which this change was decided upon. No doubt there will be many interested parties contacting the Foundation about this move, which understandably could appear to some as a sort of "Uncle!" cry from the project -- a semi-public confession that git has won the so-called version control war. And to the degree that the Board believes that to be true, they will naturally be concerned about the project saving face.

        But the PMC didn't make this decision on philosophical grounds. Subversion is an amazing version control system with broad acceptance within the Enterprise install base -- far greater than any DVCS can boast. It is because we want to better serve those users (and make good on the latter part of our Vision Statement; see http://subversion.apache.org/#vision) that we made a *technical* decision to change a bit of our development practices and tooling. We're still operating within the scope of what is permitted for ASF projects, and have no plans to deviate from "The Apache Way" (which has been often confused with "The Subversion Way", so closely do we adhere to and stand by it). We (and by we, I mean the majority of PMC members) simply believe that the best way to serve the Community with our Code is to adopt the development practices and tools that are becoming the de facto standard for open source development.
        Show
        C. Michael Pilato added a comment - I'm not sure this discussion is trending towards a positive conclusion. I'm starting to see that this ticket is getting a bit of external attention -- which I suppose is understandable -- but all that really means is that the world is watching not just what Subversion does with its source code, but also how the Foundation handles potentially contentious PMC decisions. For the good of the project and the Foundation, let's step back a bit, cool down, and try a more productive approach. I can certainly understand why the Board might be concerned about the manner in which this change was decided upon. No doubt there will be many interested parties contacting the Foundation about this move, which understandably could appear to some as a sort of "Uncle!" cry from the project -- a semi-public confession that git has won the so-called version control war. And to the degree that the Board believes that to be true, they will naturally be concerned about the project saving face. But the PMC didn't make this decision on philosophical grounds. Subversion is an amazing version control system with broad acceptance within the Enterprise install base -- far greater than any DVCS can boast. It is because we want to better serve those users (and make good on the latter part of our Vision Statement; see http://subversion.apache.org/#vision) that we made a *technical* decision to change a bit of our development practices and tooling. We're still operating within the scope of what is permitted for ASF projects, and have no plans to deviate from "The Apache Way" (which has been often confused with "The Subversion Way", so closely do we adhere to and stand by it). We (and by we, I mean the majority of PMC members) simply believe that the best way to serve the Community with our Code is to adopt the development practices and tools that are becoming the de facto standard for open source development.
        Hide
        Greg Stein added a comment - - edited
        Half-cocked, Jim? ... many projects have done similar migrations. We have a LOT of projects using Git for their backend. The whole ICLA situation has been fully-solved (I'm assuming you mean in terms of pull-requests).

        Look. The short of it is: the Apache Subversion project chose this. We want to get our stuff coded and released. For our backend, we don't need the super-huge repositories that Subversion supports. Our project stores some binaries, but we can make Git work for us. We have no need for Subversion's fine-grained authorization ... shoot. We allow ALL ASF committers access to our repository. There are no barriers to the migration here, and some of the stuff that Infra has done for integration with GitHub? Pretty cool. Positives, and only little negatives.

        Don't get me wrong. I see the benefits. As the VP, I gotta represent the project. I really DO NOT LIKE this decision. But that is not for me to decide, and it is not for you (Jim/Rich) to decide for us. It is a decision of the PMC. Sure... they held the vote in private. But that does NOT deny the result of their vote. Pushing this vote to dev@ would simply incite riot. The people who have the voting power would NOT CHANGE.

        So. As the VP of the Apache Subversion project, I opened this ticket. The Infrastructure team is moving on this ticket. If you, Rich, or any other Director/Officer have a problem with that, then bring it up at our April Board meeting. Otherwise, get out of this ticket. As Pilato and Tony have noted: this is not the forum.

        kthxbai.
        Show
        Greg Stein added a comment - - edited Half-cocked, Jim? ... many projects have done similar migrations. We have a LOT of projects using Git for their backend. The whole ICLA situation has been fully-solved (I'm assuming you mean in terms of pull-requests). Look. The short of it is: the Apache Subversion project chose this. We want to get our stuff coded and released. For our backend, we don't need the super-huge repositories that Subversion supports. Our project stores some binaries, but we can make Git work for us. We have no need for Subversion's fine-grained authorization ... shoot. We allow ALL ASF committers access to our repository. There are no barriers to the migration here, and some of the stuff that Infra has done for integration with GitHub? Pretty cool. Positives, and only little negatives. Don't get me wrong. I see the benefits. As the VP, I gotta represent the project. I really DO NOT LIKE this decision. But that is not for me to decide, and it is not for you (Jim/Rich) to decide for us. It is a decision of the PMC. Sure... they held the vote in private. But that does NOT deny the result of their vote. Pushing this vote to dev@ would simply incite riot. The people who have the voting power would NOT CHANGE. So. As the VP of the Apache Subversion project, I opened this ticket. The Infrastructure team is moving on this ticket. If you, Rich, or any other Director/Officer have a problem with that, then bring it up at our April Board meeting. Otherwise, get out of this ticket. As Pilato and Tony have noted: this is not the forum. kthxbai.
        Hide
        Tony Stevenson added a comment -
        Ahh, bugger. You have universal commit don't you? Bugger. Crap

        [~jfarrell] we should talk about this....
        Show
        Tony Stevenson added a comment - Ahh, bugger. You have universal commit don't you? Bugger. Crap [~jfarrell] we should talk about this....
        Hide
        Jim Jagielski added a comment -
        ~greg: OK, maybe half-cocked is one of those "emotionally charged" phrases, but the meaning is correct. This was done without really thinking about the longer term effects, basically the interaction of PMC and their community. The PMC is the steward of the code and the community; The ASF and the board operates under the assumption that PMCs know their community better than anyone else, and so that's why the board doesn't poke their noses into how PMCs operate. That is *until* the PMCs do something that brings that assumption into question.

        As I said, by handling all this via the private@ list, you have basically disengaged the community. Maybe they agree w/ you, maybe they don't. I don't know. But, and this is key, *neither do you*, because the PMC didn't bother to engage the larger community.
        Show
        Jim Jagielski added a comment - ~greg: OK, maybe half-cocked is one of those "emotionally charged" phrases, but the meaning is correct. This was done without really thinking about the longer term effects, basically the interaction of PMC and their community. The PMC is the steward of the code and the community; The ASF and the board operates under the assumption that PMCs know their community better than anyone else, and so that's why the board doesn't poke their noses into how PMCs operate. That is *until* the PMCs do something that brings that assumption into question. As I said, by handling all this via the private@ list, you have basically disengaged the community. Maybe they agree w/ you, maybe they don't. I don't know. But, and this is key, *neither do you*, because the PMC didn't bother to engage the larger community.
        Hide
        Branko Čibej added a comment -
        Speaking off-the-record, as a downstream user of Subversion, with my WANdisco Director of Subversion hat on: this decision, along with the recently announced git repository access module (http://svn.apache.org/r1583639), will make our lives tremendously easier. We can finally rip out all the hacks from our core modules that are needed to make the current sad apology for a repository design marginally amenable to replication. Working with git repositories is so much simpler and more robust that it's not even funny. And given that the Subversion client is much easier to use, we're looking at a winning combination (and bigger revenues).

        All I can say is, thanks guys, this will make my job fun again!
        Show
        Branko Čibej added a comment - Speaking off-the-record, as a downstream user of Subversion, with my WANdisco Director of Subversion hat on: this decision, along with the recently announced git repository access module ( http://svn.apache.org/r1583639), will make our lives tremendously easier. We can finally rip out all the hacks from our core modules that are needed to make the current sad apology for a repository design marginally amenable to replication. Working with git repositories is so much simpler and more robust that it's not even funny. And given that the Subversion client is much easier to use, we're looking at a winning combination (and bigger revenues). All I can say is, thanks guys, this will make my job fun again!
        Hide
        Daniel Gruno added a comment -
        The UCB issue could easily be handled (I'm thinking maybe a mod_lua authnz handler that switches the DB criteria based on the repo accessed), so I don't see that as a blocker of any kind.
        Show
        Daniel Gruno added a comment - The UCB issue could easily be handled (I'm thinking maybe a mod_lua authnz handler that switches the DB criteria based on the repo accessed), so I don't see that as a blocker of any kind.
        Hide
        Greg Stein added a comment -
        WHAT? ... yes, we're geeks. But that made zero sense.

        What DB? I thought we auth'd against LDAP. We simply want anybody in LDAP to be able to commit. And it would seem easy since Git isn't a "mother" repository like /repos/asf/ and setting authz rules on paths. Just "for <this> Git repos, allow any LDAP user".

        Seriously? That isn't workable?
        Show
        Greg Stein added a comment - WHAT? ... yes, we're geeks. But that made zero sense. What DB? I thought we auth'd against LDAP. We simply want anybody in LDAP to be able to commit. And it would seem easy since Git isn't a "mother" repository like /repos/asf/ and setting authz rules on paths. Just "for <this> Git repos, allow any LDAP user". Seriously? That isn't workable?
        Hide
        Jim Jagielski added a comment -
        Is Infra prepared for the huge influx of ALL ASF projects now moving to git? What with this fiasco, we might as well remove the 'wip' notification as noted above and get ready for it.

        I doubt if Sam or Ross was in the loop in this as this will significantly affect Infra workload over the next few months.
        Show
        Jim Jagielski added a comment - Is Infra prepared for the huge influx of ALL ASF projects now moving to git? What with this fiasco, we might as well remove the 'wip' notification as noted above and get ready for it. I doubt if Sam or Ross was in the loop in this as this will significantly affect Infra workload over the next few months.
        Hide
        Matt Doar added a comment -
        How about moving this issue to Bugzilla?
        Show
        Matt Doar added a comment - How about moving this issue to Bugzilla?
        Hide
        Mark Thomas added a comment - - edited
        Or we could just save ourselves a huge bunch of hassle and just migrate the entire ASF to github and be done with it. It isn't as if depending on an external org like github for something like version control presents that much additional risk to the ASF. With the new svn client / git backend tooling, projects stuck in the dark ages with svn shouldn't even notice any difference.
        Show
        Mark Thomas added a comment - - edited Or we could just save ourselves a huge bunch of hassle and just migrate the entire ASF to github and be done with it. It isn't as if depending on an external org like github for something like version control presents that much additional risk to the ASF. With the new svn client / git backend tooling, projects stuck in the dark ages with svn shouldn't even notice any difference.
        Hide
        Greg Stein added a comment -
        [~markt] you know that isn't workable. The Foundation policy is that all source code remains on servers owned/operated by the ASF so that we can establish clear provenance on all releases. GitHub is a fantastic tool, and you guys have done some great work to integrate with it, but we cannot relocate there.
        Show
        Greg Stein added a comment - [~markt] you know that isn't workable. The Foundation policy is that all source code remains on servers owned/operated by the ASF so that we can establish clear provenance on all releases. GitHub is a fantastic tool, and you guys have done some great work to integrate with it, but we cannot relocate there.
        Hide
        #asfinfra Bot added a comment -
        <danielsh_> gstein: Too late to add https://enterprise.github.com/ into 2014-5 budget?
        Show
        #asfinfra Bot added a comment - <danielsh_> gstein: Too late to add https://enterprise.github.com/ into 2014-5 budget?
        Hide
        Mark Thomas added a comment -
        Sure we could. The only barrier is foundation policy and we can change that if we want to. It could be argued that the benefits of moving the primary interface to github (obviously we would keep a mirror running on ASF hardware in case github goes up in smoke) out-weight the risks of commits going committer -> github -> ASF rather than committer -> ASF -> github. If, conceptually, you think of github as a proxy to the 'master' at the ASF you don't even need to change ASF policy.
        Show
        Mark Thomas added a comment - Sure we could. The only barrier is foundation policy and we can change that if we want to. It could be argued that the benefits of moving the primary interface to github (obviously we would keep a mirror running on ASF hardware in case github goes up in smoke) out-weight the risks of commits going committer -> github -> ASF rather than committer -> ASF -> github. If, conceptually, you think of github as a proxy to the 'master' at the ASF you don't even need to change ASF policy.
        Hide
        Greg Stein added a comment -
        [~danielsh] oh, already reached out to my GitHub friend (we drink beers every time I visit SF). Got a good response back, but still waiting on official corporate. It would be interesting to see what kind of support they'd be willing to swing our way.
        Show
        Greg Stein added a comment - [~danielsh] oh, already reached out to my GitHub friend (we drink beers every time I visit SF). Got a good response back, but still waiting on official corporate. It would be interesting to see what kind of support they'd be willing to swing our way.
        Hide
        #asfinfra Bot added a comment -
        <danielsh> Mark: we don't even have to trust github. We know public keys of committers; we can simply stipulate that all commits must be PGP signed ('gpg commit -S'). We'd want to enforce that in github.com/apache/*/pre-receive hooks, of course.
        Show
        #asfinfra Bot added a comment - <danielsh> Mark: we don't even have to trust github. We know public keys of committers; we can simply stipulate that all commits must be PGP signed ('gpg commit -S'). We'd want to enforce that in github.com/apache/*/pre-receive hooks, of course.
        Hide
        Jim Jagielski added a comment -
        ~markt: Canonical source needs to be under ASF infra. IP governance and all that.
        Show
        Jim Jagielski added a comment - ~markt: Canonical source needs to be under ASF infra. IP governance and all that.
        Hide
        Greg Stein added a comment -
        blah blah blah. enough on the haters.

        [~jfarrell] any idea on a solution to bring UCB over to our new git repo world? (and "pah!!" on lua)
        Show
        Greg Stein added a comment - blah blah blah. enough on the haters. [~jfarrell] any idea on a solution to bring UCB over to our new git repo world? (and "pah!!" on lua)
        Hide
        Roman Shaposhnik added a comment -
        Where's our transparent vendor selection process? I like GitHub as much as the next hipster but Atlassian's Stash is pretty compelling. And besides we're already running JIRA and Confluence. Thoughts?
        Show
        Roman Shaposhnik added a comment - Where's our transparent vendor selection process? I like GitHub as much as the next hipster but Atlassian's Stash is pretty compelling. And besides we're already running JIRA and Confluence. Thoughts?
        Hide
        Tony Stevenson added a comment -
        Roman,

        The infra team decided some time back not to use stash. We vaguely re-visited the conversation not so long ago and re-affirmed that position. Stash is not currently on the agenda.
        To be clear, that conversation is to be taken to a mailing list, and not in here, please. I'd like noise split from my todo list.
        Show
        Tony Stevenson added a comment - Roman, The infra team decided some time back not to use stash. We vaguely re-visited the conversation not so long ago and re-affirmed that position. Stash is not currently on the agenda. To be clear, that conversation is to be taken to a mailing list, and not in here, please. I'd like noise split from my todo list.
        Hide
        Jake Farrell added a comment -
        Hey [~rvs], Stash has been evaluated and discussed on the infra@ list
        Show
        Jake Farrell added a comment - Hey [~rvs], Stash has been evaluated and discussed on the infra@ list
        Hide
        Jake Farrell added a comment -
        [~gstein] talking over the options for UCB with others on irc, will come up with something while the initial migration is being verified
        Show
        Jake Farrell added a comment - [~gstein] talking over the options for UCB with others on irc, will come up with something while the initial migration is being verified
        Hide
        Roman Shaposhnik added a comment -
        [~gstein] it is all about drinking beer in SF, isn't it? Or is it that you don't like Darwin Stubby?
        Show
        Roman Shaposhnik added a comment - [~gstein] it is all about drinking beer in SF, isn't it? Or is it that you don't like Darwin Stubby?
        Hide
        Stefan Sperling added a comment -
        Regarding github integration: Carlos and I have been studying github's API to see if we could enable automatic pull requests when an svn client commits to a github repository using libsvn_ra_git. Looks like the necessary info can be obtained with a single GET request against the github repository URL (see https://developer.github.com/v3/repos/#get). So for svn clients using both serf (for the HTTP GET) and libgit2 (for libsvn_ra_git) we will provide integrated support for the pull request workflow with an additional option like 'svn commit --pull-request'. Note that the committing user would already be authenticated to github anyway so the pull request can be opened on the fly using the same credentials.

        The only missing piece of the workflow is the ICLA problem when accepting automated pull requests. Could the infra team provide pre-commit hook scripts that check for ICLA clearance? Then we could auto-accept pull requests from any ASF commiter and put them straight onto a staging branch in our git repository. This would make our lives so much easier. Thanks!
        Show
        Stefan Sperling added a comment - Regarding github integration: Carlos and I have been studying github's API to see if we could enable automatic pull requests when an svn client commits to a github repository using libsvn_ra_git. Looks like the necessary info can be obtained with a single GET request against the github repository URL (see https://developer.github.com/v3/repos/#get) . So for svn clients using both serf (for the HTTP GET) and libgit2 (for libsvn_ra_git) we will provide integrated support for the pull request workflow with an additional option like 'svn commit --pull-request'. Note that the committing user would already be authenticated to github anyway so the pull request can be opened on the fly using the same credentials. The only missing piece of the workflow is the ICLA problem when accepting automated pull requests. Could the infra team provide pre-commit hook scripts that check for ICLA clearance? Then we could auto-accept pull requests from any ASF commiter and put them straight onto a staging branch in our git repository. This would make our lives so much easier. Thanks!
        Hide
        #asfinfra Bot added a comment -
        <pctony> [~stsp] if you provide us with the script we will check it over for commonly overlooked errors, and if it is safe for deployment we can do that for you. But please remember we will always veto it if we dont like it.
        Show
        #asfinfra Bot added a comment - <pctony> [~stsp] if you provide us with the script we will check it over for commonly overlooked errors, and if it is safe for deployment we can do that for you. But please remember we will always veto it if we dont like it.
        Hide
        Jim Jagielski added a comment -
        Considering how much effort this is taking, with my Director hat on, I will be significantly upset if after all this, the board *does* decide that the vote was invalid, requires the PMC to bring this up on dev@, and the whole effort is shot down.

        IMO, it would be prudent to put this on hold until the rest of the board weighs in...
        Show
        Jim Jagielski added a comment - Considering how much effort this is taking, with my Director hat on, I will be significantly upset if after all this, the board *does* decide that the vote was invalid, requires the PMC to bring this up on dev@, and the whole effort is shot down. IMO, it would be prudent to put this on hold until the rest of the board weighs in...
        Hide
        Stefan Sperling added a comment -
        Well, sorry JIm, but you cannot stop me from keeping on coding on ra_git. I intend to have 'svn commit' over ra_git working once we go live with the migrated repository. I made a promise to Greg which I intend to keep no matter what the foundation believes is right or wrong!
        Show
        Stefan Sperling added a comment - Well, sorry JIm, but you cannot stop me from keeping on coding on ra_git. I intend to have 'svn commit' over ra_git working once we go live with the migrated repository. I made a promise to Greg which I intend to keep no matter what the foundation believes is right or wrong!
        Hide
        Jim Jagielski added a comment -
        ~stefan: You can code all you want. That's not my concern. My concern is that we are using Apache Infra resources in an effort which we don't even know will pass muster or not.
        Show
        Jim Jagielski added a comment - ~stefan: You can code all you want. That's not my concern. My concern is that we are using Apache Infra resources in an effort which we don't even know will pass muster or not.
        Hide
        Jim Jagielski added a comment - - edited
        FWIW, this is what's being discussed on board@

        "A 'Task' post was recently entered in Infra's list to force migration of svn over to Linus' git system. This was done after the PMC voted upon this action but the dev@ list was never queried about it. Currently Infra is spending time on this migration, even though both Rich and I have expressed concern over the process that was taken. I encourage other Directors to review the comments posted on the Subversion private@ list in which others also expressed concern and were either ignored or shut down."
        Show
        Jim Jagielski added a comment - - edited FWIW, this is what's being discussed on board@ "A 'Task' post was recently entered in Infra's list to force migration of svn over to Linus' git system. This was done after the PMC voted upon this action but the dev@ list was never queried about it. Currently Infra is spending time on this migration, even though both Rich and I have expressed concern over the process that was taken. I encourage other Directors to review the comments posted on the Subversion private@ list in which others also expressed concern and were either ignored or shut down."
        Hide
        #asfinfra Bot added a comment -
        <jfarrell> experiencing an issue with viewvc slowness post svn > git migration, we are looking into it
        Show
        #asfinfra Bot added a comment - <jfarrell> experiencing an issue with viewvc slowness post svn > git migration, we are looking into it
        Hide
        Jim Jagielski added a comment -
        Until this is complete, is there anyway to close this entry from read access from the outside world? You would not believe the sh*tstorm this is causing... didn't anyone even *think* about how this was going to be perceived?
        Show
        Jim Jagielski added a comment - Until this is complete, is there anyway to close this entry from read access from the outside world? You would not believe the sh*tstorm this is causing... didn't anyone even *think* about how this was going to be perceived?
        Hide
        Daniel Gruno added a comment -
        Jim, this would require us setting up security groups and assigning roles. It's not something we're going to do on a whim just because a director wants it.
        We can look into the matter over a longer period of time, but I'm feeling a bit uneasy about making tickets such as these private in an organization that prides itself with openness.

        Please follow up on the mailing list.
        Show
        Daniel Gruno added a comment - Jim, this would require us setting up security groups and assigning roles. It's not something we're going to do on a whim just because a director wants it. We can look into the matter over a longer period of time, but I'm feeling a bit uneasy about making tickets such as these private in an organization that prides itself with openness. Please follow up on the mailing list.
        Hide
        Jake Farrell added a comment -
        [~humbedooh], [~ke4qqq], [~pctony] and I discussed the universal commit access and we think that it will be possible by extending the existing git auth mechanics that are currently in place, should have it ready to go in the next couple hours, after that its up to you when you want to cut over
        Show
        Jake Farrell added a comment - [~humbedooh], [~ke4qqq], [~pctony] and I discussed the universal commit access and we think that it will be possible by extending the existing git auth mechanics that are currently in place, should have it ready to go in the next couple hours, after that its up to you when you want to cut over
        Hide
        Bert Huijben added a comment -
        [~jimjag] This is precisely why we completed the vote on the PMC list...
        Show
        Bert Huijben added a comment - [~jimjag] This is precisely why we completed the vote on the PMC list...
        Hide
        Greg Stein added a comment -
        Thanks [~jfarrell]. Appreciate you continuing to work on this despite the firestorm (my asbestos suit is getting plenty of wear).

        So it looks like the conversion went well. As mentioned, our primary concern is our newest alpha release. It looks like that came over fine, at: https://git-wip-us.apache.org/repos/asf?p=subversion.git;a=commit;h=7bc1689589e130b9a8b857a1b7a991701784ea22

        I'm gonna have a few of the devs pull that tag and run our standard test series (ra_local/serf/svn each paired against fsfs/bdb/fsx). Shouldn't need to do it this way, but:

        Woulda been nice to just do a file-wise compare against a checkout from the svn repo, but it looks like we're having issues with newline representation. Shouldn't be this hard, so I suspect we've got some user error (needless to say, until we get ra_git up, some of us are just now learning git). Very much missing "svn:eol-style=native" :-P
        Show
        Greg Stein added a comment - Thanks [~jfarrell]. Appreciate you continuing to work on this despite the firestorm (my asbestos suit is getting plenty of wear). So it looks like the conversion went well. As mentioned, our primary concern is our newest alpha release. It looks like that came over fine, at: https://git-wip-us.apache.org/repos/asf?p=subversion.git;a=commit;h=7bc1689589e130b9a8b857a1b7a991701784ea22 I'm gonna have a few of the devs pull that tag and run our standard test series (ra_local/serf/svn each paired against fsfs/bdb/fsx). Shouldn't need to do it this way, but: Woulda been nice to just do a file-wise compare against a checkout from the svn repo, but it looks like we're having issues with newline representation. Shouldn't be this hard, so I suspect we've got some user error (needless to say, until we get ra_git up, some of us are just now learning git). Very much missing "svn:eol-style=native" :-P
        Hide
        Stefan Sperling added a comment -
        I'm also seeing eol-style issues in a local git repository clone of the current migration candidate. These could be resolved by configuring gitattributes to match our svn:eol-style settings.

        ra_git will handle this transparently once property support is added (I'm currently still working on commit which turns out to have some rather nasty unexpected edge cases -- I think I'm running into some libgit2 bugs but really not sure yet).

        But perhaps the migration scripts the infra team is using could be updated to handle this correctly? Newline conversion is not exactly rocket science guys, give or take the workload the infra team is already carrying, seriously... please PM me a link to whatever migration script sources you're using and I'll try to fix them up if you don't have time. Cheers!
        Show
        Stefan Sperling added a comment - I'm also seeing eol-style issues in a local git repository clone of the current migration candidate. These could be resolved by configuring gitattributes to match our svn:eol-style settings. ra_git will handle this transparently once property support is added (I'm currently still working on commit which turns out to have some rather nasty unexpected edge cases -- I think I'm running into some libgit2 bugs but really not sure yet). But perhaps the migration scripts the infra team is using could be updated to handle this correctly? Newline conversion is not exactly rocket science guys, give or take the workload the infra team is already carrying, seriously... please PM me a link to whatever migration script sources you're using and I'll try to fix them up if you don't have time. Cheers!
        Hide
        Ross Gardler added a comment -
        From a technical perspective I'm amazed that the SVN community has "voted" to go in this direction. It is clear that Greg, as VP Subversion, is not in favour of this move (see his reasoning above) but if this is what the Subversion community want so be it. It is not the place of the foundation to stand in the way of progress.

        I wouldn't go quite so far as Joe's take on the whole thing but as ever Joe speaks what many are thinking. We, the foundation, have to look to the outside world to see if our practices are still the "best" practices. Infra have done an awesome job of marrying the strengths of Subversion to the current "new" world of "social coding" and the sub-standard IP due-diligence this approach often encourages in open source projects. It seems like the subversion community have bravely sought to go further than this and to question something that is at the core of their project. All power to them for being willing to make huge sacrifice for the benefit of all (mind you I still find it hard to believe the sacrifice is worth it - but I guess that's why I'm not an SVN committer).

        However, as Jim and Rich ask, does the community want this?

        Frankly I'm pleased to see Rich taking an unusually forceful stance on this. When our EVP decides to speak so clearly and strongly we have to take note - especially when that person is normally extremely careful with his words. Jim is displaying the colours that us long-timers in the ASF have grown to love and respect. His keen eye for a slippery slope is something we need and he surely has spotted a slippery slope here.

        To be clear, my concern is not the questionable technical decision that has been made by the Subversion PMC. It is what this means to the decision making processes in Apache communities. Jim speaks at length on this above so I will not go into those more deeply than to say I expect the board to be assigning me a task relating to the Subversion PMC in the next April meeting - Greg as a VP of the foundation, you simply should know better than to allow this to happen. I hope you clear up this mess before that task is assigned to me.

        My most pressing concern is the impact this will have on our Infra team. I was unaware of this until a few minutes ago, and as with Jim it caught me totally unawares. I've yet to hear from Sam as VP Infra but as far as I can gather the Infra team are not ready for the mass migration that this move will create. Again, Greg, as a Director of the foundation you simply should know better.

        Finally, on an entirely personal note, I've been dodging bullets all day today, but this one hit me. As a Volunteer in this foundation I don't appreciate having to clear up the mess you folks are creating here.
        Show
        Ross Gardler added a comment - From a technical perspective I'm amazed that the SVN community has "voted" to go in this direction. It is clear that Greg, as VP Subversion, is not in favour of this move (see his reasoning above) but if this is what the Subversion community want so be it. It is not the place of the foundation to stand in the way of progress. I wouldn't go quite so far as Joe's take on the whole thing but as ever Joe speaks what many are thinking. We, the foundation, have to look to the outside world to see if our practices are still the "best" practices. Infra have done an awesome job of marrying the strengths of Subversion to the current "new" world of "social coding" and the sub-standard IP due-diligence this approach often encourages in open source projects. It seems like the subversion community have bravely sought to go further than this and to question something that is at the core of their project. All power to them for being willing to make huge sacrifice for the benefit of all (mind you I still find it hard to believe the sacrifice is worth it - but I guess that's why I'm not an SVN committer). However, as Jim and Rich ask, does the community want this? Frankly I'm pleased to see Rich taking an unusually forceful stance on this. When our EVP decides to speak so clearly and strongly we have to take note - especially when that person is normally extremely careful with his words. Jim is displaying the colours that us long-timers in the ASF have grown to love and respect. His keen eye for a slippery slope is something we need and he surely has spotted a slippery slope here. To be clear, my concern is not the questionable technical decision that has been made by the Subversion PMC. It is what this means to the decision making processes in Apache communities. Jim speaks at length on this above so I will not go into those more deeply than to say I expect the board to be assigning me a task relating to the Subversion PMC in the next April meeting - Greg as a VP of the foundation, you simply should know better than to allow this to happen. I hope you clear up this mess before that task is assigned to me. My most pressing concern is the impact this will have on our Infra team. I was unaware of this until a few minutes ago, and as with Jim it caught me totally unawares. I've yet to hear from Sam as VP Infra but as far as I can gather the Infra team are not ready for the mass migration that this move will create. Again, Greg, as a Director of the foundation you simply should know better. Finally, on an entirely personal note, I've been dodging bullets all day today, but this one hit me. As a Volunteer in this foundation I don't appreciate having to clear up the mess you folks are creating here.
        Hide
        Daniel Shahaf (äñ§€¥£¢) added a comment -
        @gstein, couldn't we run 'git fast-export' on a clone of the new Git repo, use esr's or artagnon's converters to create a dumpstream out of that, and compare _that_ against our repository? That would reduce us to comparing two svn repositories, which we know how to automate. (Just diffing dumps should do the trick. Revision files are also deterministic nowadays, but we can't rely on that since the "known-good" repository wouldn't be have been using a 1.9 server since its inception.)

        P.S. Yes, I realise how odd it would be to rely on FS backend internals for debugging the git transition... but hey, if it so happens that 'svnadmin dump' is the best way to make 'git fast-import' verifiable, then let's do it that way! :)
        Show
        Daniel Shahaf (äñ§€¥£¢) added a comment - @gstein, couldn't we run 'git fast-export' on a clone of the new Git repo, use esr's or artagnon's converters to create a dumpstream out of that, and compare _that_ against our repository? That would reduce us to comparing two svn repositories, which we know how to automate. (Just diffing dumps should do the trick. Revision files are also deterministic nowadays, but we can't rely on that since the "known-good" repository wouldn't be have been using a 1.9 server since its inception.) P.S. Yes, I realise how odd it would be to rely on FS backend internals for debugging the git transition... but hey, if it so happens that 'svnadmin dump' is the best way to make 'git fast-import' verifiable, then let's do it that way! :)
        Hide
        Greg Stein added a comment -
        You too Ross? As I told Jim: Rock. Hard place. You think *you're* dodging bullets?

        Fine. Go ask Infra for an addendum to their monthly report, and we can chat at our Board meeting in a couple weeks. Meanwhile, I'll find somebody else to deal with this. I've been VP for 4 years now. I've been trying my best to represent our community and its desires. And to do it in the best way possible, for our project.

        Daniel: nice idea, but we're have to somehow extract /repos/asf/subversion/... from the mother repos. Then get it all renumbered, including the various Node-Copyfrom headers in the resulting dumpfile. After all that work… sure, maybe you could compare dumpfiles. It almost seems easier to rely on the test framework. (yah yah… we don't necessarily test it all) … maybe we could just normalize all EOLs and compare? (yes, it would break some files, but we're trying to examine similarity -- we don't have to build the normalized stuff)
        Show
        Greg Stein added a comment - You too Ross? As I told Jim: Rock. Hard place. You think *you're* dodging bullets? Fine. Go ask Infra for an addendum to their monthly report, and we can chat at our Board meeting in a couple weeks. Meanwhile, I'll find somebody else to deal with this. I've been VP for 4 years now. I've been trying my best to represent our community and its desires. And to do it in the best way possible, for our project. Daniel: nice idea, but we're have to somehow extract /repos/asf/subversion/... from the mother repos. Then get it all renumbered, including the various Node-Copyfrom headers in the resulting dumpfile. After all that work… sure, maybe you could compare dumpfiles. It almost seems easier to rely on the test framework. (yah yah… we don't necessarily test it all) … maybe we could just normalize all EOLs and compare? (yes, it would break some files, but we're trying to examine similarity -- we don't have to build the normalized stuff)
        Hide
        Daniel Shahaf (äñ§€¥£¢) added a comment -
        @gstein, another way to get around the svn:eol-style issue would be to compare (as in, comm(1)) the list of SHA1s of file contents between the git repo and its svn ancestor - that information is cheaply available at both ends. Just make sure to filter out directories (they can't be compared without being parsed) and properties.
        Show
        Daniel Shahaf (äñ§€¥£¢) added a comment - @gstein, another way to get around the svn:eol-style issue would be to compare (as in, comm(1)) the list of SHA1s of file contents between the git repo and its svn ancestor - that information is cheaply available at both ends. Just make sure to filter out directories (they can't be compared without being parsed) and properties.
        Hide
        Greg Stein added a comment -
        Oh, crap. Forgot about properties. We gotta migrate all the svn:ignore props over to .gitignore files. We use svn:mime-type quite a lot. Does that have a git equivalent? I seem to recall some sort of autoprop like thingy in Git. #lost
        Show
        Greg Stein added a comment - Oh, crap. Forgot about properties. We gotta migrate all the svn:ignore props over to .gitignore files. We use svn:mime-type quite a lot. Does that have a git equivalent? I seem to recall some sort of autoprop like thingy in Git. #lost
        Hide
        Bert Huijben added a comment -
        [~gstein] I'm pretty sure the Elego scripts can take care of the ignore handling

        [~danielsh] Git calculates its SHA hashes on more data than just the file content (the object type and size are hashed before the actual data of a file).
        Show
        Bert Huijben added a comment - [~gstein] I'm pretty sure the Elego scripts can take care of the ignore handling [~danielsh] Git calculates its SHA hashes on more data than just the file content (the object type and size are hashed before the actual data of a file).
        Hide
        Greg Stein added a comment -
        [~rhuijben] ah… no wonder he seemed so cranky at Infra's test conversion :-/
        Show
        Greg Stein added a comment - [~rhuijben] ah… no wonder he seemed so cranky at Infra's test conversion :-/
        Hide
        Arvind Prabhakar added a comment -
        While I do believe that various PMCs should have as much autonomy in deciding what infrastructure is best for them, I feel that the VOTE that resulted in this decision is fundamentally flawed at many levels. As mentioned above - such a topic ought to be discussed in the open and held up to public scrutiny before being formalized. What happens to all the developers who have been toiling away at subversion codebase for weeks/months/years - do you expect them to just put up with this? This is a sure way to tell those developers that the project does not give them the regard that they deserve.

        Being a chair of Flume and Sqoop projects, I cannot imagine ever having such a major decision as this behind closed doors without involving the very community that made them successful.

        Show
        Arvind Prabhakar added a comment - While I do believe that various PMCs should have as much autonomy in deciding what infrastructure is best for them, I feel that the VOTE that resulted in this decision is fundamentally flawed at many levels. As mentioned above - such a topic ought to be discussed in the open and held up to public scrutiny before being formalized. What happens to all the developers who have been toiling away at subversion codebase for weeks/months/years - do you expect them to just put up with this? This is a sure way to tell those developers that the project does not give them the regard that they deserve. Being a chair of Flume and Sqoop projects, I cannot imagine ever having such a major decision as this behind closed doors without involving the very community that made them successful.
        Hide
        Stefan Sperling added a comment -
        The Subversion developer community was involved. All of Subversion's developers knew about this well in advance. The discussion was held in private to avoid a flame fest from drowning the discussion before consensus could be reached.
        Show
        Stefan Sperling added a comment - The Subversion developer community was involved. All of Subversion's developers knew about this well in advance. The discussion was held in private to avoid a flame fest from drowning the discussion before consensus could be reached.
        Hide
        Ben Reser added a comment - - edited
        Consensus is a bit of a strong word to use for a decision that Greg, myself and others strongly opposed. Seeing as the private list is just that private I'll just link to my comments to Paul Hammant's suggestion of a Subversion and Mercurial merger. For all practical purposes your end result here is turning Subversion into nothing more than a front end to git. My comments on Paul's email are just as applicable in this case, though obviously the git folks aren't merging with us so much as gaining yet another client. https://mail-archives.apache.org/mod_mbox/subversion-dev/201402.mbox/%3C52F06B27.4010003%40reser.org%3E

        I should note that the fiasco that this conversion is turning into is exactly what I anicipated in the linked email.
        Show
        Ben Reser added a comment - - edited Consensus is a bit of a strong word to use for a decision that Greg, myself and others strongly opposed. Seeing as the private list is just that private I'll just link to my comments to Paul Hammant's suggestion of a Subversion and Mercurial merger. For all practical purposes your end result here is turning Subversion into nothing more than a front end to git. My comments on Paul's email are just as applicable in this case, though obviously the git folks aren't merging with us so much as gaining yet another client. https://mail-archives.apache.org/mod_mbox/subversion-dev/201402.mbox/%3C52F06B27.4010003%40reser.org%3E I should note that the fiasco that this conversion is turning into is exactly what I anicipated in the linked email.
        Hide
        Bert Huijben added a comment -
        [~breser] [~stsp] And we are restarting the discussion here to have another flame fest here too? :((
        Time to get some sleep...
        Show
        Bert Huijben added a comment - [~breser] [~stsp] And we are restarting the discussion here to have another flame fest here too? :(( Time to get some sleep...
        Hide
        Greg Stein added a comment -
        Resolving as "Not a problem". We sure as hell don't want to do this. :-)

        My major thanks to [~jfarrell] for the concept.

        And plenty of thanks to all of my co-conspirators on this issue. Yes.. even my antagonist [~jimjag] was in on the ruse :-) … the Infra team handled this with perfect aplomb. And the Directors and Exec Officers came in with a perfect level of wrath. Our Subversion teammates showed a great sense of community and circling the wagons… Thank you all for making this work!!!

        Last but not least…

        THANK YOU to all of you who actually BELIEVED.
        Show
        Greg Stein added a comment - Resolving as "Not a problem". We sure as hell don't want to do this. :-) My major thanks to [~jfarrell] for the concept. And plenty of thanks to all of my co-conspirators on this issue. Yes.. even my antagonist [~jimjag] was in on the ruse :-) … the Infra team handled this with perfect aplomb. And the Directors and Exec Officers came in with a perfect level of wrath. Our Subversion teammates showed a great sense of community and circling the wagons… Thank you all for making this work!!! Last but not least… THANK YOU to all of you who actually BELIEVED.
        Hide
        Roman Shaposhnik added a comment -
        I was looking forward to seeing it closed on April 2nd as 'Not Reproducible'.
        Show
        Roman Shaposhnik added a comment - I was looking forward to seeing it closed on April 2nd as 'Not Reproducible'.

          People

          • Assignee:
            Jake Farrell
            Reporter:
            Greg Stein
          • Votes:
            5 Vote for this issue
            Watchers:
            30 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development