Alan W. Irwin writes: > On 2009-03-24 22:55-0600 Geoffrey Furnish wrote: > > > To that end, I'd like to ask Alan specifically, again, to identify with > > specificity, what you think the specific requirements for such a transition > > would be, from your perspective. > > > > My own view of this list would be, essentially: > > > > 1) Preservation of history > > 2) Demonstration that checking out tagged versions between SF svn and a > > potential git successor repo, results in the same files with the same > > attributes. > > 3) Viable Windows client. (You have previously agreed to this requirement, > but it should be formally in the list so there is no uncertainty about it.)
Yes, of course. Sorry I dropped it in last night's e-mail. I realized the omission as I was drifting off to sleep. And providing a concrete way for windows developers to evaluate the windows git clients is a key part of why I want to establish a publicly visible git repo that I can push some stuff into, and others can clone/pull. > 4) A consensus should emerge that we actually should make the move to git. Yes, definitely agreed. That's why I'm discussing first, and inviting input. I do not want to alienate any of our core team with this. But I am really nonplussed with svn, much more so after having worked with both git and svn for a while now than I was at first. So I am quite willing to play the role of advocate here, despite Maurice's duly noted comments. Also, I think it is worth noting. When my corporate projects switched to git, the developer community was already pretty onboard with the realization that the old system was becoming an impediment. So the focus was on picking a successor system, and we did not really even consider a transition period. We just focused on how to do an initial import, and a one-time instantaneous cutover. For this project, we clearly have people who believe they're happy with svn, in addition to some who are not happy with svn. So a more gradual approach to the possibility of a switchover is clearly in order. Consequently, I'll focus some of my early efforts on facilitating people's use of the git-svn gateway system. I don't really like git-svn itself. As I mentioned in the first introductory note, a git-svn gateway to an svn repo is not nearly as appealing as a wholly-git infrastructure. But it's a way to get started, and people can use git behind a git-svn gateway. So this approach should let us get started with git, on an as-interested basis. And at least people will have the try-before-you-buy advantage. > This is obviously not a democracy so it is not a matter of voting, but we do > form a small community where we want to encourage each other. Thus, we > obviously do not want to railroad anybody with this decision. So I think > the best way to proceed here is by consensus. How I would define such > consensus is at least a substantial fraction of the active developers are > enthused by the idea, and the rest of the developers willing to go along, > i.e., nobody adamantly opposed. Agreed. > However, I think we need more individuals in the first group, i.e., more of > our most active developers who are enthused about the idea before we can > claim there is a consensus for it. IOW, I would hate to see us disrupt the > PLplot development with such a move if it turns out few of the active > developers are enthused about it. Also agreed. Andrew Ross writes: > I am afraid I have recently been distracted elsewhere and I am one of > the core developers not to have responded yet. My feelings mirror Alan's > closely. We have only relatively recently gone through a big move to > svn. This seems to be settling down with our developer and user base now > and I'm a little unwilling to move without a clear benefit. It seems to > me that we are a relatively small project, with few active developers at > any one time. I'm not sure we really make use of the current facilities > available in svn, and I suspect that a move to git won't radically > change that for most developers. I think the reason we don't make much > use of things like branching is as much to do with the fact we don't > see the real need to, rather than the technical issues associated with > doing so in svn. :-). Well, we'll see. I was happy to see Hazen start an svn branch the other day. I will be interested to see how that goes. My own experience with svn branching has led me to conclude that its much more broken than branches were in cvs. I have found many others voicing the same conclusion in blogs and articles around the internet. Stated charitably, I think svn branching works best if the branch gets merged before trunk moves too far. But the farther they drift (turnk and your branch), the mare laborious the merge becomes. This is one of the key things that I think is superiour about git. The "effort to merge" (any branch to any other branch, including master, or vice-versa) is just not something that git developers fret about. > Having said all that, I am interested to read the discussion on git and > I do now feel I appreciate better some of the potential advantages (and > disadvantages) of git. I wouldn't say never to plplot using, I would > just like to see rather more of a need for git and for a concensus to > move. > > Any potential move would have to satisfy the 4 requirements above. > > I think your proposal for establishing a non-sourceforge git repository > which links to svn is a sensible policy for now. It allows people to > test it out and see if it works for them without committing to a > wholesale move for the whole project. Any future move can then be made > based on a rather more informed basis. Exactly. > Please keep the list posted on this. Will do. And thanks to all who have contributed to this thread, both publicly and privately. -- Geoff ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
