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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 get rid of our current processes in terms of providing patch zips and an rsyncable trunk. Switching to Git would just mean that one had a choice of another way. Those who didnt want to use Git could keep on working as they have.

      Anyway, I just like Git on a technical level. Im not against using something else, its just I want the solution to have virtually every feature that Git has. And I really dont think the lack of a native win32 port should be a showstopper, especially given its possible to install via Cygwin.

      Yeah, I know, some folks out there have a weird bias against cygwin, but Ive found those folks also tend to think they have to cygwin+bash+etc. They dont, they cygwin command line tools work just fine in the cmd shell.

      • 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.