From: Nikodemus S. <nik...@ra...> - 2007-07-05 11:45:54
|
I'd like to propose an experiment. Let's make a short trial run just using Git. The commiters who already have drunk the koolaid should have no issues with this -- but I believe we have a significant number of people who don't use Git... So the question is, what sort of information and details would _you_ (speaking to SBCL devs mainly) need to seriously consider a trial-run on Git? My basic idea: * Set up a Git repository, and give committers write access to it. * Every committer that wants can have a public personal repository as well. * Chill of the CVS for a week or two. Hack, hack, hack. The central repository remains the official HEAD. * After a week or two commit the new stuff to CVS, and then decide what next. My claims: * Aside from the cost of setting up the repository (and if necessary writing a short SBCL-centric how-to for CVS users) the cost are neglible. * IF this experiment is a success, then gains are going to be significant. * IF this experiment is a failure, then we have lost nothing but a few hours of effort. Also: * We don't need to do this NOW. We can pick our time in a way that is convenient for maximum number of people. * We don't really need a central Git repository for the experiment if all committers have public ones, but then we need to give version numbering and "whose SBCL is the real SBCL" a bit more thought. That might be worth a second experiment, but I don't see huge gains there right now. Cheers, -- Nikodemus |
From: <da...@ax...> - 2007-07-05 15:06:34
|
Speaking as a random lurker on Sbcl I've become a fan of git in the last 6 months. On the axiom project we use Arch, CVS, SVN, and git. Like the transition to lisp, using git involves an "ah-ha" moment when you finally "get it". After that you'll wonder why anyone would consider using anything else. Git is different and tracks changes, not files like CVS. Thus you do a git-add every time you make a change to a file and want to commit the change. So there are 3 "states" to a change, one in which you've made the change but not added it. Git, unlike CVS will ignore the change. The second state is after a git-add but before a commit. The third state is after a commit. A second difference from CVS, and my personal favorite since it completely changed the way I work, is that you can create a branch, do a bunch of work, and then switch back to the master branch. Git will "undo" those changes you've done. When you switch back to the branch it redoes your changes. It shoulds a lot like working in a CVS branch but it is not. Git also does changesets but this requires discipline. You need to resist the urge to "fix this other bug while I'm here". This is a side-effect of changeset mentality and not really a git issue. But coming from CVS it is another hard change. Git-commit just commits to your local copy (that is, it computes a new MD5 hash). In order to change another repository (say a general git server for those who want central service) you need to do a git-push. Git uses a much better tracking system. There is only one .git directory. CVS, SVN, and Arch sprinkle directories everywhere. This bit us on the axiom project because SVN makes the directories read-only which caused a duplicate-copy bug. Git uses MD5 hashes and comes up with a unique number for a commit. Using that number (or a unique prefix) you can name any commit. Changesets are also in Arch but the change-orientation and the ease of branching is not. The Arch required-naming convention is also hard for people to accept. Git allows every clone to be "the central repository" so each person has their own official version. You can "checkout" from other people's version. They can "checkout" from yours. You can also commit. This is a major shift of thinking from using a central repository. CVS and its spawn SVN are much harder to use and require a central repository. I use SVN for work and we use SVN for some of the people on the project. My personal experience is that SVN loses work. This has happened half-a-dozen times for work and twice for axiom. Source code control systems should never lose work. Avoid SVN. Oh, and git is blindingly fast. Did I mention that it is fast? After watching SVN struggle to do anything git simply flies. Tim Daly |
From: Zach B. <xa...@xa...> - 2007-07-05 15:08:47
|
On Thu, Jul 05, 2007 at 10:06:34AM -0500, da...@ax... wrote: > Speaking as a random lurker on Sbcl I've become a fan of git > in the last 6 months. On the axiom project we use Arch, CVS, > SVN, and git. > > Like the transition to lisp, using git involves an "ah-ha" moment > when you finally "get it". After that you'll wonder why anyone > would consider using anything else. I found http://eagain.net/articles/git-for-computer-scientists/ helpful in moving towards an "aha" moment. Zach |
From: Nathan B. <na...@ac...> - 2007-07-05 18:31:47
|
da...@ax... wrote: > Speaking as a random lurker on Sbcl I've become a fan of git > in the last 6 months. On the axiom project we use Arch, CVS, > SVN, and git. > Speaking as a random lurker on Sbcl (thanks BTW): I've become a big fan of Darcs. I'm not really proposing this instead of Git, just that from what I've heard Git has most of that distributed patching goodness that I've come to love. I never used CVS significantly (SVN then Darcs) and my limited experience with CVS on random projects has always been a turn-off. More so than trying to learn Git (or some other DVC with similar popularity volume). I've seen this discussion on a couple projects and it is always assumed that CVS is good enough and "everyone already knows it". This may be true of everyone who has commit access already (an extremely important segment), but I think increasingly will keep newer people at a distance (not necessarily away). Specifically on projects such as this where I'm not really a contributor, the barrier to making any contribution is irritating. While the combo of cvs, diff, and patch mostly get the job done figuring out the correct strip options and parameters for making this acceptable upstream is always weird; and the resulting patchfile object is something that is *not* recorded in the versioning system-- which in my mind defeats the purpose of source control. In darcs I record locally-- that patch now has permanence. I can then send that version-controlled patch object back upstream via email or push to a public branch where more knowledgeable people can accept or reject to the main branch. If Git can do something along these lines-- tracked, encapsulated, transportable patches-- then I wholeheartedly vote for "Make the jump." Nathan Bird |
From: Nathan B. <na...@ac...> - 2007-07-05 19:03:50
|
I don't know if this community had any hand in it but http://programming.reddit.com/ appears to have an above normal number of articles on source control today. :-) a few that I noted: liked: http://ianclatworthy.wordpress.com/2007/06/21/version-control-the-future-is-adaptive/ neutral: http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/ May be worth noting, but I think his concern is overblown. I tend to agree with the comment that this a field still being experimented with as a cause for so many offerings. Reinforces Mr. Newman's concern about jumping between them though. neutral: http://blog.slickedit.com/?p=97 one perspective on the history of source control clients... probably nothing new here for most. |
From: <bdo...@la...> - 2007-07-05 19:06:34
|
On Thu, Jul 05, 2007 at 02:28:46PM -0400, Nathan Bird wrote: > Speaking as a random lurker on Sbcl (thanks BTW): I've become a big fan > of Darcs. I'm not really proposing this instead of Git, just that from > what I've heard Git has most of that distributed patching goodness that > I've come to love. Git is distributed, but Git doesn't version changes, it versions state. This is very different from Darcs. On the bright side, Git has very strong history reconstruction, whereas with Darcs you really don't know where you were unless you tag. > In darcs I record locally-- that patch now has permanence. I can then > send that version-controlled patch object back upstream via email or > push to a public branch where more knowledgeable people can accept or > reject to the main branch. If Git can do something along these lines-- > tracked, encapsulated, transportable patches-- then I wholeheartedly > vote for "Make the jump." Git has some nice email patch-sending and patch-applying tools available (obviously; it's how quite a lot of business in the kernel gets done), but they are not version-controlled in the Darcs sense. The huge downside of Darcs is that SBCL has some patches in its history that make it explode -- merges just run forever. That really lowered my confidence in it. Which is too bad; its interface really is a model of simplicity. Now that I am used to Git, however, I much prefer it to Darcs. ("git citool" gets me my killer feature of Darcs as far as usability, which was being able to commit individual hunks in a file.) The last benefit of Git for me I'll mention here is that the repository model is /simple/. You can understand it in hours. I still don't know how Darcs works internally. (Again, see http://eagain.net/articles/git-for-computer-scientists/) -bcd |
From: Nikodemus S. <nik...@ra...> - 2007-07-05 19:33:13
|
Brian Downing wrote: > Git is distributed, but Git doesn't version changes, it versions state. > This is very different from Darcs. On the bright side, Git has very > strong history reconstruction, whereas with Darcs you really don't know > where you were unless you tag. This is one of my major issues with Darcs: no clear notion of history. Cheers, -- Nikodemus |
From: Nathan B. <na...@ac...> - 2007-07-06 18:07:51
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Nikodemus Siivola wrote: <blockquote cite="mid:468...@ra..." type="cite"> <pre wrap="">Brian Downing wrote: </pre> <blockquote type="cite"> <pre wrap="">Git is distributed, but Git doesn't version changes, it versions state. This is very different from Darcs. On the bright side, Git has very strong history reconstruction, whereas with Darcs you really don't know where you were unless you tag. </pre> </blockquote> <pre wrap=""><!----> This is one of my major issues with Darcs: no clear notion of history. </pre> </blockquote> Yeah, I love what darcs does on many fronts-- but the history reconstruction is a downer. From my experience and what I've read elsewhere the exponential merge isn't a problem (doesn't occur) with a strict usage policy... unfortunately that strict usage policy cuts into much of the goodness so is still a losing situation. This is also where the difficulty of finding where/when a patch came from hurts most.<br> <br> <br> </body> </html> |
From: Attila L. <att...@gm...> - 2007-07-05 19:19:30
|
> The huge downside of Darcs is that SBCL has some patches in its history > that make it explode -- merges just run forever. That really lowered > my confidence in it. Which is too bad; its interface really is a model fwiw, i have a tailor converted darcs repo of the sbcl cvs and the latest darcs have no problem with it. -- attila |
From: <bdo...@la...> - 2007-07-05 19:24:06
|
On Thu, Jul 05, 2007 at 09:19:28PM +0200, Attila Lendvai wrote: > fwiw, i have a tailor converted darcs repo of the sbcl cvs and the > latest darcs have no problem with it. Can you try to do a merge across the whitespacification patch? That was what killed it for me. -bcd |
From: <wil...@ai...> - 2007-07-05 21:14:26
|
On Thu, Jul 05, 2007 at 02:23:55PM -0500, Brian Downing wrote: > On Thu, Jul 05, 2007 at 09:19:28PM +0200, Attila Lendvai wrote: > > fwiw, i have a tailor converted darcs repo of the sbcl cvs and the > > latest darcs have no problem with it. > > Can you try to do a merge across the whitespacification patch? That was > what killed it for me. Yep, one of the two great examples (that I know of...) of SBCL as brutal stress test. I doubt the darcs implementors were expecting to cope with patches from hell like that. Some evidence suggests that perhaps the clisp GC implementors weren't expecting to run an app from hell like SBCL-the-cross-compiler either. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C SBCL isn't done 'til CLISP doesn't run! |
From: <mar...@gm...> - 2007-07-05 21:32:43
|
> Speaking as a random lurker on Sbcl (thanks BTW): I've become a big fan > of Darcs. I'm not really proposing this instead of Git, just that from > what I've heard Git has most of that distributed patching goodness that > I've come to love. Darcs has one serious advantage over Git. It runs on windows, while Git is unix only? While if doesn't matter for linux kernel, ti might be a problem for a cross platform project. Maybe Mercurial can also be evaluated. It runs everywhere. |
From: Thiemo S. <th...@ne...> - 2007-07-06 13:10:37
|
Marko Koci?? wrote: > > Speaking as a random lurker on Sbcl (thanks BTW): I've become a big fan > > of Darcs. I'm not really proposing this instead of Git, just that from > > what I've heard Git has most of that distributed patching goodness that > > I've come to love. > > Darcs has one serious advantage over Git. It runs on windows, while > Git is unix only? While if doesn't matter for linux kernel, ti might > be a problem for a cross platform project. There's a Windows port of Git. However, there's only a very slow (unregisterized) port of Haskell/Darcs for MIPS/Linux and some of the other minor SBCL platforms. Thiemo |
From: Nikodemus S. <nik...@ra...> - 2007-07-05 21:38:54
|
Marko Koci=C4=87 wrote: >> Speaking as a random lurker on Sbcl (thanks BTW): I've become a big fa= n >> of Darcs. I'm not really proposing this instead of Git, just that from= >> what I've heard Git has most of that distributed patching goodness tha= t >> I've come to love. >=20 > Darcs has one serious advantage over Git. It runs on windows, while > Git is unix only? While if doesn't matter for linux kernel, ti might > be a problem for a cross platform project. http://git.or.cz/gitwiki/WindowsInstall > Maybe Mercurial can also be evaluated. It runs everywhere. Cheers, -- Nikodemus |
From: <mar...@gm...> - 2007-07-05 21:53:14
|
> http://git.or.cz/gitwiki/WindowsInstall Thanks for the link. I've been googling for some time and finally found it in http://lilypond.org/git/binaries/mingw/ I can't hardly wait to check it out. Regards, Marko |