Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

demerphq (2831)

demerphq
  (email not shown publicly)
http://www.perlm ... l?node_id=108447
Perlmonk. Perl5 Regex Hacker. Telecoms Billing Specialist. Canadian living in Germany.

Journal of demerphq (2831)

Friday December 29, 2006
10:21 AM

Perl5 should switch to using Git as its main source control

[ #32014 ]

I've been thinking a lot about source control lately. Ive been having issues with my development process (using svn/TortoiseSvn) and working with p5p lately that really makes me think that the current scheme is not all that cool.

Currently Perl5 uses a Perforce repository hosted by Activestate. FWICT you are only allowed read access if you have a commit bit and for obvious reasons the pool of people with commit bits is small, and because of attrition in the developer community, /appears/ to be shrinking.

Now, most of the work I do is new features, and accordingly I'm not that fussed about not having a commit bit. Forcing peer review and a sober-second-thought on new features is a good plan, and many a bug has been caught by the two man process. Although annoyingly a couple of doozies have passed oversight for some time without any notice at all. (Which I suppose is to be expected in any development project of this size and complexity.)

However what really annoys me is that I can't easily synchronize my local version with the ongoing patch and when I upload my changes its via a snapshot. My local history is lost, and when the patch is merged in its showed as being from the person who committed it, and not me (although the patch comment usually shows more details). On at least one occassion this has lead to someone blaming a bug on the commiter and not me, the actual responsible party.

So I want a system where i can maintain my local tree, where I can easily sync it with others, and etc. It looks to me like Git is the right choice. While svk also seems interesting I don't like the fact that its based on SVN which Im slowly coming to dislike on an achitectural basis.

The .svn directories everywhere, the size and number of files of change data, etc all really start to get on my nerves. The Git architecture seems much more sound, and has the benefit of being under heavy development by people who are doing stuff just like what the Perl5 developers are doing. As well as some very bright contributors like Linus Torvalds.

Now, I'm not a unix person in general, and it appears Git support on Windows is weak, but since it appears to work fine under cygwin I would happily change to using it. And frankly I'm getting more and more inclined to do a total permanent switchover to linux anyway.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Perl5 should switch to using Git as its main source control 14 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I've been involved with the git community since the beginning, and in fact serve as the "canary in the mine" when it won't work cleanly on OpenBSD or OSX, and provide occasional guidance for the small parts that are written in Perl (the remainder is in C and some shell).

    I have been using git to track the Perl6 docs and Parrot development trees (similar to the way people use svk) so that I can see the entire project history when I'm offline (like at 30K feet in an airplane).

    To come up to speed quickly on

    --
    • Randal L. Schwartz
    • Stonehenge
    • Encouraging a Native Win32 would be really useful. Projects that are platform agnostic (as many non OS project are) need portability in general and with Win32 specifically because of its market penetration.

      I realize asking a bunch of Linux people to keep Win32 development in mind is hardly politically popular, but it would go a long way to making Git more appropriate for projects like Perl. Consider we have active contributors doing dev and testing on pretty much everything you can imagine. The more widely

  • While Perforce's readonlyness and the limited supply of licenses bothers me too (rsync just does not cut it, while I have patches waiting in my tree), doing something that makes it even more difficult for Win32 programmers to participate seems to me to be a very bad idea.

    I can barely get feedback from Win32 users on my pure-Perl modules; it's difficult to believe that there are any Win32 programmers interested in using Perl and willing to install both Cygwin and Git to get at the source code.

    • All I can say in reply to that is that Im one of a very small group of active contributors to Perl5 that uses Win32. And if it doesnt bother me, I'm not too sure why it should bother anybody else. Egotistical I guess, but hey, disk space is cheap, and installing cygwin is easy.

      Also, I tend to think that anybody doing serious OpenSource dev on Win32 has Cygwin installed anyway. Its just too useful and too much of pain to get the required toolsets working from elsewhere.

      But, I have to say I dont see how we ge

      • I have to agree that if you want to change it then whatever you replace it with needs to be Win32 friendly and not the "cygwin" variety of Win32.

        • Id love to know why. I mean, whats the difference between installing an app that links against the cygwin dll's and something that links against some custom active-x object or whatnot?

          From a end user experience, I go to the Cygwin setup tool, select git, procede with the install and I'm done. I then go to my shell and follow the tutorial for using git and it all apears to work just fine.

          So whats the objection?
          • My personal objection to Cygwin is that it seems to mess with both Windows- and Unix specific line endings. Sometimes it just gets it wrong, and then you're in deep shit. A lot of the trouble people appear to be having specifically under Cygwin, appear to be linked to this issue.

            One step back, please, Cygwin seems to go just a bit too far.

            And I actually like bash. I don't know the difference with the other Unix shells, but I do like it.

            • I've seen issues when you use the "use windows line endings" option, but otherwise not. And afaik git treats all files as binary blobs so it shouldnt mess with line endings at all.

              • afaik git treats all files as binary blobs so it shouldnt mess with line endings at all.

                That's not my definition of "properly handling line endings". A version control system that doesn't treat a change of line endings as a simple file attribute change (a meta change), is not doing the proper thing, IMO. And many don't. Most treat this as a change on every single line.

                It's simple enough. If an assumed text file contains plenty LF characters and not a single CR character, then it's a Unix file. If it only contains pairs of CR+LF characters, no other bare CR nor LF characters, then it's a "DOS"

                • How relevent is this tho? All the perl source files use unix line endings, even the win32 specific ones.

          • I hate the way Cygwin tries to map the Windows drive letter fiasco to a Unixoid filesystem hierarchy. It grates on my sensitivities every step of the way when I try to use Cygwin.

            • Well, I've noticed that this seems to be shell related. If you use cmd /most/ apps seem to cope with windows paths properly. I'm not sure what the story is exactly. All I can say is that in my use patterns I encounter it rarely.

      • The last time I did any work on Windows, I used Cygwin as well, but that's because I was much more comfortable with Unix than Windows. I don't know if long-time Windows developers who've never really used Unix would feel the same need to install Cygwin that I did (and I can only guess at your background).

        I just feel leery about switching to a tool that doesn't yet have a native version on such an important platform where we don't attract many contributors. (I can only guess at how Git works on OS/2 and

        • The VMS crowd, however, is very stable minority of users. Unfortunately, they cannot use Perforce natively on recent VMS versions, specifically on Itaniums. There is actually a very limited number of platforms that can natively use the most recent version of Perforce. For example, support for AIX, OpenBSD, and IRIX seems to be dropping off. The lack of git on Win32, however, is much more concerning issue as this effects a large number of Perl users.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.