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.
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 git, take a look at the links to articles already written about git, including a presentation I gave a few weeks ago. You think you have tough audiences? I had Linus Torvalds himself in the audience for that presentation. {grin}
Re:Yes to "git"
demerphq on 2006-12-30T11:23:57
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 ported the system is the better.
Although I lean towards thinking that the Cygwin port is good enough I think that if Chromatic felt it worth raising then a native Win32 port probably is more important than I personally would have guessed.
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.
Re:Not Right Now
demerphq on 2006-12-30T10:25:25
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.
Re:Not Right Now
sigzero on 2006-12-30T16:14:42
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.
Re:Not Right Now
demerphq on 2006-12-31T00:02:15
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?
Re:Not Right Now
bart on 2006-12-31T01:01:01
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.
Re:Not Right Now
demerphq on 2006-12-31T12:09:14
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.Re:Not Right Now
bart on 2007-01-10T01:12:03
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" file. Only bare CR characters means a Mac (Classic) file.
Any other combination of CR and LF, and it's not really a text file and it should be treated as a binary file.
How hard is that?Re:Not Right Now
demerphq on 2007-01-10T09:02:42
How relevent is this tho? All the perl source files use unix line endings, even the win32 specific ones.Re:Not Right Now
Aristotle on 2006-12-31T10:49:24
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.
Re:Not Right Now
demerphq on 2006-12-31T12:07:17
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. Re:Not Right Now
chromatic on 2006-12-30T19:33:21
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 VMS, however they're not exactly growing audiences.)
Re:Not Right Now
speters on 2006-12-30T20:41:50
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.
