Hosting lift on GitHub

[David Pollak]

Folks,

I just had a great lunch with the folks who run http://github.com

Git is an awesome revision control system (http://www-cs-students.stanford.edu/~blynn/gitmagic/) which does much better branching/merging than Subversion.  It allows for much more "experimentation" than does SVN.

I'd like to move lift to GitHub, but want to get a sense from the rest of you what you think.

So, post your thoughts.  Nothing will happen until there's been a thorough discussion and buy-in from the process-related lift committers.

Thanks,

David

--
Scala lift off unconference, May 10th 2008, San Francisco http://scalaliftoff.com
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us

[Charles F. Munat]

I am not a fan of Subversion at all. I use Mercurial, which is
distributed and very similar to Git, IIRC. So it certainly sounds like a
dandy idea to me.

Chas. Munat
Seattle

[Tim Perrett]

+1 for GitHub - use it all the time and its great.

Cheers

Tim

[David Bernard]

Several month ago, I suggest to move to mercurial (I already used it at office and for my opensource project)
I try git some month ago, and was very disappointed by it : harder to use, doesn't work on windows natively/nicely (there is partial port)
Lot of project choose mercurial against git (Mozilla, OpenJDK,...)
I don't know if there is a git plugin for hudson (there is one for mercurial, already installed on scala-tools.org for scalax and mina-scala)

/davidB

[TylerWeir]

+1 for GitHub

On May 14, 4:50 pm, David Bernard <david.bernard...@gmail.com> wrote:
> Several month ago, I suggest to move to mercurial (I already used it at office and for my opensource project)
> I try git some month ago, and was very disappointed by it : harder to use, doesn't work on windows natively/nicely (there is partial port)
> Lot of project choose mercurial against git (Mozilla, OpenJDK,...)
> I don't know if there is a git plugin for hudson (there is one for mercurial, already installed on scala-tools.org for scalax and mina-scala)
>
> /davidB
>
> David Pollak wrote:
> > Folks,
>

> > I just had a great lunch with the folks who runhttp://github.com

[TylerWeir]

Hey DaveB, does this help?: http://hudson.gotdns.com/wiki/display/HUDSON/Git+Plugin

On May 14, 4:50 pm, David Bernard <david.bernard...@gmail.com> wrote:

> Several month ago, I suggest to move to mercurial (I already used it at office and for my opensource project)
> I try git some month ago, and was very disappointed by it : harder to use, doesn't work on windows natively/nicely (there is partial port)
> Lot of project choose mercurial against git (Mozilla, OpenJDK,...)
> I don't know if there is a git plugin for hudson (there is one for mercurial, already installed on scala-tools.org for scalax and mina-scala)
>
> /davidB
>
> David Pollak wrote:
> > Folks,
>

> > I just had a great lunch with the folks who runhttp://github.com

>
> > Git is an awesome revision control system
> > (http://www-cs-students.stanford.edu/~blynn/gitmagic/) which does much
> > better branching/merging than Subversion.  It allows for much more
> > "experimentation" than does SVN.
>
> > I'd like to move lift to GitHub, but want to get a sense from the rest
> > of you what you think.
>
> > So, post your thoughts.  Nothing will happen until there's been a
> > thorough discussion and buy-in from the process-related lift committers.
>
> > Thanks,
>
> > David
>
> > --
> > Scala lift off unconference, May 10th 2008, San Francisco
> >http://scalaliftoff.com

[David Pollak]

TylerWeir wrote:

Hey DaveB, does this help?: http://hudson.gotdns.com/wiki/display/HUDSON/Git+Plugin
  

The GitHub folk are looking to break out of the Ruby focus and support other languages as well.  I suggested integration with Hudson and becoming a Maven repository (they are currently a Ruby GEM repository.)  They are open to exploring all kinds of ideas like this.

[Alex Boisvert]

+1 on Git or Mercurial.

alex

[David Bernard]

David, Tyler,

What are the advantages of GitHub (vs default self hosted repository with gitweb or mercurial) ?

as example of default mercurial repo with web access:
http://hg.scalaforge.org/
http://alchim.sf.net/hg/

/davidB

[Chris Wanstrath]

Hi David (and friends),

I'm one of the GitHub guys and just had some tasty Thai with David
Pollak.

We created GitHub for two reasons:

1) Make it really easy to throw up a new repository and share your
code

2) Make it really easy to contribute to someone else's code

On the hg sites you linked to, what you've got is a directory browser
and a commit log. Maybe some other features, but it's basically a web
interface to the hg command line tool - everything those sites do, you
can do from the command line. Which is fine, and very useful.

What GitHub gives you beyond the basics are tools to help the DSCM
workflow. I can fork your repository, add my own changes, then start
a discussion on this list asking for feedback. Want to try out my
changes? Make a new branch on your local repository and pull them
in. Then it's trivial to either merge my changes into your 'master'
branch, or discard them.

Don't think my changes are any good? That's fine -- I still have my
own, full-fledged repository on the site with my changes. Anyone else
can pull in the changes if they want. Of course, this is rare. But
with DSCM, it's possible and can be quite useful.

While Git is great at the DSCM, forks of forks model, it's also
awesome at the centralized SVN model. Any project can have multiple
committers - no need to force major contributors to go through the
fork process.

You can also add comments to commits, even on specific lines, which is
a pretty popular feature. Here's an example:
http://github.com/rails/rails/commit/9c2657aa96d3a8f19602ded748e558b0531c1132#railties/lib/rails/plugin/locator.rb-P5

We're very interested in adding more features to help open source
collaboration, mainly because we're big open source users and authors
ourselves.

There's also the expected stuff, like RSS feeds and activity and
whatnot. Oh yeah, and the network graph:

http://github.com/mojombo/god/network

This helps me explore forks with unique commits -- that is, changesets
that don't appear in the 'parent.'

We're adding new stuff all the time, too. The news feed is getting a
revamp in the near future to help the signal to noise ratio.

So that's my pitch. As a GitHub developer, I'd love to see you guys
use the site. But as an open source hacker, the site was written to
make our lives easier.

Check our some of the popular repos to get an idea of how big projects
with multiple committers and contributors handle things:
http://github.com/popular/watched

Thanks,

- Chris Wanstrath

[David Bernard]

Chris,

Thanks for the reply (linked samples help me).
I'm a linux user (and a mercurial user ;-) )
but some of the committers and potential contributor are on Windows/MacOS, when I tried git (one year ago), it didn't work nicely on Windows, is it always the case?
I don't want to force contributor to use cygwin (using maven is a "enought" step for them).
I'm open to learn git, and work with it and GitHub (=> adapted/configure hudson and the release protocol).

Thanks for your interesting info.

Note: today, I started to read the mercurial book (as mercurial support for the office) ;-)

[David Pollak]

On Wed, May 14, 2008 at 3:03 PM, David Bernard <david.be...@gmail.com> wrote:

Chris,

Thanks for the reply (linked samples help me).
I'm a linux user (and a mercurial user ;-) )
but some of the committers and potential contributor are on Windows/MacOS, when I tried git (one year ago), it didn't work nicely on Windows, is it always the case?

Actually... this is a good time to ask:

Are any lift committers on Windows?

How many lift users are on Windows?

 

--
lift, the simply functional web framework http://liftweb.net

[TylerWeir]

> Are any lift committers on Windows?
> How many lift users are on Windows?

My /lifting/ at work is Windows and Linux. Work on /lift/ proper is
OS X.

So far I have found no issues using git/OS X, with the caveat that
nothing is as big as /lift/.

$0.02 CDN

[Bruce Stephens]

On 14 May, 21:50, David Bernard <david.bernard...@gmail.com> wrote:
> Several month ago, I suggest to move to mercurial (I already used it at office and for my opensource project)
> I try git some month ago, and was very disappointed by it : harder to use, doesn't work on windows natively/nicely (there is partial port)
> Lot of project choose mercurial against git (Mozilla, OpenJDK,...)

A few months ago git sucked on Windows, yes. Works OK now, in my
limited experience. "Harder to use" is tricky to argue
(either way), IMHO. git's different, but I'm not sure it's fair to
call it harder to use. The (poorly named) index, and its handling of
branches (again with not terribly well-named concepts like the various
meanings of "tracking branch") make it appear more
complex, but I find the features enormously valuable.

So I'd be in favour of git over mercurial. On the other hand, scalax
uses mercurial, so that should probably have weight.

[Jorge Ortiz]

+infinity for git or mercurial

When I did the 2.7.1 merge for lift, I kept thinking how much easier
it could have been... (not that it was hard, but it's pretty trivial
for git or hg)

I'm pretty agnostic as to git vs hg, or any particular hosting
provider vs self host.

I agree with Bruce that Scalax using Mercurial should be a
consideration. Jamie preferred Git, but decided on Mercurial mostly on
the weight of community feedback and Windows support. (Though I
believe git's Windows situation has been improving.) I would be less
scary for new adopters if the Scala ecosystem uniformly uses one DVCS.

Another consideration should be tools support. If we start to see
increasingly mature IDE plugins for Scala/lift, we should also
consider which DVCS will integrate best with these IDEs. I know
nothing about this. Does anyone know how well Eclipse, NetBeans,
IntelliJ, etc integrate with Git and Mercurial?

That said, "Scala ecosystem uniformity" and "tools support" are nice
things to have, but they are by no means critical to lift. The one
thing that -is- critical to lift's release process is DavidB. So my
vote goes to whatever makes him most productive.

--j

[Jorge Ortiz]

I need to learn to say all of what I'm thinking:

Not only is Scalax hosted on Mercurial, but Scalax hosts a full copy
of the Scala repository on Mercurial. They also host a copy of the
Scala Docs on Mercurial (which is the approved path for submitting
better documentation to the Scala team).

If we're strongly leaning towards Git, we should make an effort to
coordinate with Scalax and have them switch to Git as well. (Modulo
hassle for everyone involved,) I think Jamie might be amenable to such
a move, as he indicated a personal preference for Git.

--j

[Ivan Tarasov]

Another consideration should be tools support. If we start to see
increasingly mature IDE plugins for Scala/lift, we should also
consider which DVCS will integrate best with these IDEs. I know
nothing about this. Does anyone know how well Eclipse, NetBeans,
IntelliJ, etc integrate with Git and Mercurial?

NetBeans has good support integration with Mercurial. Not sure about Git.
However, I still prefer using command line for doing most of the VCS tasks.

Ivan

[David Bernard]

A very quick comparison to complete:
 
About Mercurial :
Eclipse have a pretty simple (but enough) plugin for Mercurial
Netbeans has a plugin for mercurial, (openJDK, solaris and other "Sun" project are under Mercurial)
Windows with tortoiseHG has a nice plugin
Maven has support for hg (but I never used it)
Hudson : OK
Web+RSS : OK with default web interface

About Git :
Eclipse : I don't know
Netbeans : I don't know
Windows : I don't know (see previous mail from Bruce) : require cygwin ??
Maven : I found a patch somewhere, but nothing documented (need more investigation)
Hudson : OK (to test) Tyler point me the plugin
Web +RSS : OK with GitHub hosting

support for maven isn't really require => more manual operation in the release process

Against some month, DavidP is open to migrate to DSCM, that is the important new.
DavidP, do you know how DSCM works ?
DavidP, mercurial allow to work in parallele on svn and hg (via "hg convert"), if you want to test.

Now we need to choose between Git (and not GitHub) and Mercurial.

from the Mercurial book, I read that git repository (every developpers has a repository) require regular maintenance operation (repack), is it true ?
http://hgbook.red-bean.com/hgbookch1.html#x5-180001.6.2

/davidB

[Chris Wanstrath]

On May 14, 3:03 pm, David Bernard <david.bernard...@gmail.com> wrote:

> Thanks for the reply (linked samples help me).
> I'm a linux user (and a mercurial user ;-) )
> but some of the committers and potential contributor are on Windows/MacOS, when I tried git (one year ago), it didn't work nicely on Windows, is it always the case?
> I don't want to force contributor to use cygwin (using maven is a "enought" step for them).
> I'm open to learn git, and work with it and GitHub (=> adapted/configure hudson and the release protocol).

I'm not a Windows user, but here's a quote from someone who is:

"I don’t know why anyone would say git on windows sucks … been using
it for about a week now … it rocks"

(Source: http://weblog.rubyonrails.org/2008/4/11/rails-premieres-on-github)

The commenter then links to: http://code.google.com/p/msysgit/downloads/list

I've heard a few others say the same. I think the 'poor Windows'
support is a thing of the past.

- Chris

[Chris Wanstrath]

On May 15, 12:46 am, "David Bernard" <david.bernard...@gmail.com>
wrote:

> from the Mercurial book, I read that git repository (every developpers has a
> repository) require regular maintenance operation (repack), is it true ?http://hgbook.red-bean.com/hgbookch1.html#x5-180001.6.2

Repacks are done behind the scenes in recent versions of Git.

- Chris

[Marius]

Damn ... I am one :)

Just didn't see the compelling reason to switch my development env. on
Linux. Personally I would expect any tools used in lift world to
seamlessly work on both Linux and Windows.

GIT sounds nice but what are the actual problems that we're facing
with SVN that will be addressed by GIT? I'm not saying that we should
not move to GIt just that the concrete reason escapes me somehow. What
do you mean by "allows for much more "experimentation" than does SVN.
" ... what kind of "experimentation" we need at source control level?

Br's,
Marius

On May 15, 1:05 am, "David Pollak" <feeder.of.the.be...@gmail.com>
wrote:
> On Wed, May 14, 2008 at 3:03 PM, David Bernard <david.bernard...@gmail.com>

> >http://github.com/rails/rails/commit/9c2657aa96d3a8f19602ded748e558b0...

>
> > > We're very interested in adding more features to help open source
> > > collaboration, mainly because we're big open source users and authors
> > > ourselves.
>
> > > There's also the expected stuff, like RSS feeds and activity and
> > > whatnot. Oh yeah, and the network graph:
>
> > >http://github.com/mojombo/god/network
>
> > > This helps me explore forks with unique commits -- that is, changesets
> > > that don't appear in the 'parent.'
>
> > > We're adding new stuff all the time, too. The news feed is getting a
> > > revamp in the near future to help the signal to noise ratio.
>
> > > So that's my pitch. As a GitHub developer, I'd love to see you guys
> > > use the site. But as an open source hacker, the site was written to
> > > make our lives easier.
>
> > > Check our some of the popular repos to get an idea of how big projects
> > > with multiple committers and contributors handle things:
> > >http://github.com/popular/watched
>
> > > Thanks,
>
> > > - Chris Wanstrath
>
> --

> lift, the simply functional web frameworkhttp://liftweb.net
> Collaborative Task Managementhttp://much4.us

[David Bernard]

Thanks Chris for this uptodate and usefull info.
FYI, the url I provide in previous mail could be used to clone mercgurail repository (like for git).

/davidB

[David Bernard]

Marius you're not alone, I think Eric works on Windows.

Where DSCM (Git and mercurial) are "better" than svn is in the management of branch and merge. This is important if developpers work on variation/experiementation (eg: X works on the migration to scala 2.8, and Z works on an refactor of lift-widget,...), merging and working on parallele branch with svn is hard. An other feature I like a lot : "offline" commit.
for a quick/biased comparison see the link, I sent http://hgbook.red-bean.com/hgbookch1.html#x5-180001.6.2

If you use Git or Mercurial like SVN, there is "more" action to do :
svn : commit
mercurial : commit + push

/davidB

[Marius]

Yeah besides that I see Git is not actually free. How would this work
for lift commiters?

P.S.
Currently I'm using SVN with Tortoise client + Beyond compare merging
tool and frankly it's a seamless experience. If GitHub doesn't work
well on Windows it will be a real bummer ...


Br's,
Marius

On May 15, 11:33 am, "David Bernard" <david.bernard...@gmail.com>
wrote:

> Marius you're not alone, I think Eric works on Windows.
>
> Where DSCM (Git and mercurial) are "better" than svn is in the management of
> branch and merge. This is important if developpers work on
> variation/experiementation (eg: X works on the migration to scala 2.8, and Z
> works on an refactor of lift-widget,...), merging and working on parallele
> branch with svn is hard. An other feature I like a lot : "offline" commit.

> for a quick/biased comparison see the link, I senthttp://hgbook.red-bean.com/hgbookch1.html#x5-180001.6.2

>
> If you use Git or Mercurial like SVN, there is "more" action to do :
> svn : commit
> mercurial : commit + push
>
> /davidB
>

[David Bernard]

Marius,

Git is free (originaly develop by Linus Torvald to manage linux core code)
Git != GitHub
Git is the SCM tool
GitHub is a repository hoster + friendly web tool (Chris correct me, if I'm wrong)
GitHub is like a svnweb++ or a FishEye (parallele with SVN).

There is no TortoiseGit, but there is TortoiseHG (my co-worker use it) very similar to tortoiseSVN

/davidB

[Marius]

Ok cool then.

On May 15, 12:07 pm, "David Bernard" <david.bernard...@gmail.com>
wrote:

> Marius,
>
> Git is free (originaly develop by Linus Torvald to manage linux core code)
> Git != GitHub
> Git is the SCM tool
> GitHub is a repository hoster + friendly web tool (Chris correct me, if I'm
> wrong)
> GitHub is like a svnweb++ or a FishEye (parallele with SVN).
>
> There is no TortoiseGit, but there is TortoiseHG (my co-worker use it) very
> similar to tortoiseSVN
>
> /davidB
>

[David Pollak]

There are three constituents that I think need to have the highest priority in this process: the code psychos, the release engineers, and the lift promotion folks.  Here's how I see it playing out:

• Code Psychos: We generally contribute the most LoC and generally try the most radical stuff.  With SVN, it's hard to try radical stuff.  Yes, one can send a change set around.  Yes, one can create a branch and hope that we can merge the branch into the mainline as long as the mainline hasn't changed too much.  I'd really like to see this change.  For example, I'd like Marius to be able to "ask the question with code" by creating a branch, moving all the lift-related stuff out of the HttpSession and into SessionMaster on a branch, say "what do you guys think?" and we debate with actual code.  Because Git (and apparently Mercurial) have easier branching and merging and allow for more experimentation, I think there's a good argument for using one or the other.  This is the "coders" problem that we solve.  If it's not solved well for me and Marius (of late, the two most psychotic contributors to lift), then it's not a good solution (the Windows issue is huge here.)
  
• Release Engineers: Changing process is hard.  There should exist a good reason.  Right now, we've got one of the slickest, most excellent release processes I've seen in a project.  It's a beautiful blend of different systems that play very, very nicely together (SteveJ's 5 hour release experience is the exception... sorry Steve.)  This is primarily due to DavidB's awesome work and his excellent vision of how release should work.  Any change away from SVN has to factor in the costs of the change and the prospects of a less seamless release process going forward.
• Marketing: Git is the buzz in the San Francisco Web 2.0 world.  GitHub is (pardon the pun) the hub of a lot of that buzz.  As we spend more effort (e.g., the Scala lift off) on growing awareness about lift, especially in the community that lift best serves (a community that's building sites that are highly interactive on the front side and very RESTful on the back side), I want to see us tapping into the buzz-flow of this community.  Further, the GitHub folks want to move away from being a Ruby-centric world, into a world that support other language.  This means that they are looking to do the things that other languages need.  Hudson continuous integration and a public Maven repository are potentially services that GitHub will offer.  This leads to a level of motivation on their part to help get it right for us.

Are these the right constituencies?  Is Mercurial a better choice because the value in the first two areas out-weighs the value in the third area?

Thanks,

David

[Viktor Klang]

I'm on Windows @ home and OSX @ work.

No Eclipse-support = epic fail for me.

--
Viktor Klang
Rogue Software Architect

[philipp schmidt]

Hi,

On Thu, May 15, 2008 at 3:52 PM, Viktor Klang <viktor...@gmail.com> wrote:
> I'm on Windows @ home and OSX @ work.
>
> No Eclipse-support = epic fail for me.

There is http://freshmeat.net/projects/jgit/ but I never tested it.

Philipp

[Jeroen Dirks]

I have been using Git on windows with the egit Eclipse plugin. (It
uses a java rewrite of Git itself.)

http://freshmeat.net/projects/jgit/

I have not worked with a huge code base yet so I am not sure about
performance but support for the basics is there and the project is
still actively worked on.

Jeroen

[Alex Boisvert]

I would add two more elements that make Git more interesting for Code Psychos,
-Speed:  most common operations are local and take no (apparent) time; which means they don't disrupt your coding train of thought as much
-Disconnected operation:  you can work in more places without hitting the network barrier  (I take the train to go to work and I can work the same even if I'm not connected)

alex

[Marius]

On May 15, 4:50 pm, "David Pollak" <feeder.of.the.be...@gmail.com>
wrote:

> There are three constituents that I think need to have the highest priority
> in this process: the code psychos, the release engineers, and the lift
> promotion folks. Here's how I see it playing out:
>

> - Code Psychos: We generally contribute the most LoC and generally try

> the most radical stuff. With SVN, it's hard to try radical stuff. Yes, one
> can send a change set around. Yes, one can create a branch and hope that we
> can merge the branch into the mainline as long as the mainline hasn't
> changed too much. I'd really like to see this change. For example, I'd
> like Marius to be able to "ask the question with code" by creating a branch,
> moving all the lift-related stuff out of the HttpSession and into
> SessionMaster on a branch, say "what do you guys think?" and we debate with
> actual code. Because Git (and apparently Mercurial) have easier branching
> and merging and allow for more experimentation, I think there's a good
> argument for using one or the other. This is the "coders" problem that we
> solve. If it's not solved well for me and Marius (of late, the two most
> psychotic contributors to lift), then it's not a good solution (the Windows
> issue is huge here.)

This does make lots of sense to me. It is easier indeed to express
certain let's say lift-core changes with code that can be debated
without affecting the "mainline" ... But I very keen to see a
platform agnostic (Linux and Windows) solution.

> - Release Engineers: Changing process is hard. There should exist a good

> reason. Right now, we've got one of the slickest, most excellent release
> processes I've seen in a project. It's a beautiful blend of different
> systems that play very, very nicely together (SteveJ's 5 hour release
> experience is the exception... sorry Steve.) This is primarily due to
> DavidB's awesome work and his excellent vision of how release should work.

+++++1

> Any change away from SVN has to factor in the costs of the change and the
> prospects of a less seamless release process going forward.

> - Marketing: Git is the buzz in the San Francisco Web 2.0 world. GitHub

> is (pardon the pun) the hub of a lot of that buzz. As we spend more effort
> (e.g., the Scala lift off) on growing awareness about lift, especially in
> the community that lift best serves (a community that's building sites that
> are highly interactive on the front side and very RESTful on the back side),
> I want to see us tapping into the buzz-flow of this community. Further, the
> GitHub folks want to move away from being a Ruby-centric world, into a world
> that support other language. This means that they are looking to do the
> things that other languages need. Hudson continuous integration and a
> public Maven repository are potentially services that GitHub will offer.
> This leads to a level of motivation on their part to help get it right for
> us.
>
> Are these the right constituencies? Is Mercurial a better choice because
> the value in the first two areas out-weighs the value in the third area?
>
> Thanks,
>
> David
>

> ...
>
> read more »

[TylerWeir]

I will understand if people disagree, as my proposal may not fit with
others ideals or be stupid. :)

If we would like the best of both worlds (git's DSCM features and the
current build/release setup) what do people think about keeping the
current system and then pushing a mirror up to GitHub?

Using both SVN and Git is relatively common [see links]. Developers
would be free to grab all the git repos they would like and when a
commit was ok'd to be pushed back to the main SVN repository it could
be done with git-svn.

A post commit hook on the svn repo could push to the GitHub mirror.
The amount of effort to set this up may not be worth it, but it's an
option to test out the git waters.

[links]
http://cheat.errtheblog.com/s/gitsvn/
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
http://andy.delcambre.com/2008/3/4/git-svn-workflow

[David Pollak]

http://kylecordes.com/2008/04/30/git-windows-go

[Emmanuel Okyere]

I use svk (http://svk.bestpractical.com/view/HomePage), if I must use an svn repository.

cheers,

Emmanuel.

---

Question people's actions, not their motives – Cicero

[David Bernard]

Alex Boisvert wrote:
> I would add two more elements that make Git more interesting for Code
> Psychos,
> -Speed: most common operations are local and take no (apparent) time;
> which means they don't disrupt your coding train of thought as much
> -Disconnected operation: you can work in more places without hitting
> the network barrier (I take the train to go to work and I can work the
> same even if I'm not connected)

This 2 elements are also valid for mercurial.

/davidB

[David Bernard]

With this "conversation", I've got every response to my questions about git.
I'm ok to work with Git (and adapte the release process).
Marius/Eric could you try git on windows (using GitHub isn't required).

There is bridge Git/Mercurial (and vice/versa) so we switch to the other if we'll be disappointed by the first selected.

/davidB

[David Bernard]

I'll copy a feedback of Jamie Webb (lead of Scalax) about Git and HG :

> The lift team currently discuss about migrate from svn to git or
> mercurial, WDYT ?
> http://groups.google.com/group/liftweb/t/4117f9556d390a7f

Either would be a big improvement over Subversion. The choice is not
simple though. I think I prefer the underlying design of Git, but it
seems that Hg may be more 'enterprise ready'.

Git pros:
- Initial learning curve is now roughly on par with Hg
- Thoroughly documented in man pages
- Branches are truly lightweight and disposable
- More flexible attitude to history (Hg developers consider this a
con)
- More power-user features available (most notably, rebase)

Git cons:
- Second-class Windows support (it runs on Cygwin and there's a native
port in alpha last I checked, but don't expect things to be smooth or
to
get much support from the core developers)
- Potentially a lot more to learn in the long run
- Lacks an overview guide comparable to the Hg book
- Weaker tool support

Hg pros:
- Cross-platform
- Better GUI tool support
- Traditionally been easier to use
- Has an online book providing a solid introduction

Hg cons:
- Details are not always well-documented
- Branching model is rather confused
- History tends to look rather messy (though it's not clear that this
really matters - depends on how much archaeology you want to do)
- Somewhat dumbed-down out of the box - have to mess about with
extensions (notably, MQ) to get a really usable system IMO
- Slower (apparently both are reasonably fast at what they do, but I
notice the startup time of that big Python codebase...)

So, it depends on your needs.

I've considered moving Scalaforge to Git, but I'm not sure it's worth
the trouble, and I'm also waiting to get more experience with it
before
making a decision (I'm using Git for one project, but I haven't needed
to do much fancy stuff yet). I've also looked into extending 'hg
convert' to provide a two-way sync, which actually doesn't look too
hard, with a few provisos.

For my own projects, I also have yet to decide whether to move to Git
or stick with Darcs (which unfortunately has a somewhat uncertain
future at the moment). Following my experience with Scalax, Hg is not
in the running. However, for public projects I am mindful of people
who
are less keen on Linux and the command line than I. Hg irritates me in
comparison to Git or Darcs, but not that much.

Feel free to post this to the Lift list, and let me know how you get
on.

[Paul Snively]

On May 17, 1:39 pm, David Bernard <david.bernard...@gmail.com> wrote:
> I'll copy a feedback of Jamie Webb (lead of Scalax) about Git and HG :
>

[ Much good stuff about Git, Mercurial, and darcs elided for brevity ]

At my day job, we started off with darcs 1.09 and ran into, I think,
every issue that anyone ever complains about, including the dreaded
superexponential merge issue, but also including, e.g. tickling bugs
in OpenSSH's Connection Manager implementation, locking and unlocking
of memory-mapped files not working quite right between, e.g. darcs
running on Mac OS X but accessing a repo on a Samba share, running out
of stack space while committing large-ish binary files, and so on.
With darcs 2.0 I personally no longer fear the superexponential merge,
but I can't speak to the other issues we encountered. In any case, at
work we moved to Mercurial. It's a nice system, plenty fast enough,
runs everywhere we care about. The only issues we seem to encounter
revolve around the branching and merging model. Personally, I would
argue that that's exactly the sort of thing that darcs so brilliantly
avoids by having the insight that, in a DVCS, treating the notions of
"repository" and "branch" separately really doesn't make much sense,
assuming a good patch model. Having said that, I do find Mercurial to
be a quite reasonable second choice to darcs.

Git sends chills down my spine. It's not rational, I know. But I
remember barely even being able to find out where to download the
thing from, and then there were no clear directions on how to build it
(this is admittedly going back some months now). On Mac OS X, the only
sane way to get it was to use Darwin ports, and I'm allergic to
requiring "package managers" to install anything I deem critical
(database servers, compilers, version control systems...). At the time
Git also seemed to be more of a "VCS construction set" than fully-
baked VCS, with dozens and dozens of commands, the expectation being
that you would figure out which to invoke and redirect/pipe to the
next one... no, thanks. And I say that as an avid UNIX command-line
user. But VCS as a discipline with lots of tool choices has gotten
mature enough that there are several reasonable options that don't
require me to be Linus to grok.

Finally, the point that scalax is Mercurial-based does indeed, IMHO,
militate considerably in favor of likewise adopting Mercurial moving
forward, although honesty compels me to admit that I'm completely
ignoring the hosting and administration issues that appear to motivate
the consideration of GitHub. Since I'm not tasked with administering
the repository :-) someone with direct experience of that could no
doubt shed light on the weight that that lends to the decision-making
process.