Scala and DVCS (e.g. Git)

On Fri, 2009-09-11 at 09:31 +0100, Alex Blewitt wrote:
> There has been the suggestion (independently, a few times) that the
> Scala source tree moves to a distributed version control system, such
> as Git. This shouldn't be a part of the modularisation effort per se,
> but is still worth considering in its own right.
>
> Git does appear to be the DVCS of choice for a number of organisations
> (e.g. http://git.apache.org, and Eclipse has settled on Git as their
> DVCS as well) although Google Code uses Hg. But aside from the
> particular mechanism, sites like GitHub are increasingly popular (e.g.
> Lift) for many types of projects.
>
> What is EPFL's thoughts regarding a DVCS at some point in the future?
> What requirements need to be satisfied (both in terms of timing and
> also practicalities)?

A thread that includes some answers:

http://thread.gmane.org/gmane.comp.lang.scala/12307/focus=12399

The link is for Martin's answer, but there are others in the thread that
may be of interest.

It's worth nothing that things have improved in the DVCS land since that
thread last year (even if IDE support is still not great for Git).

Best,
Ismael

The additional advantages of git (or other distributed version control
systems) are appealing, but at this time we do have a working system and a
workflow that would be rather disrupted by a migration. The prevailing
thinking in the group at the moment is "it ain't broken - don't fix it".

That is not to say that we are not considering git at this time, and a
migration is definitely in the cards. Right now we are focused on the 2.8
release however, and switching at this time looks a bit unlikely.

Once that is out of the door it will be a good time to consider the matter
again. Also, some people in the team rely on SmartSVN, and SmartGit should
be available by that time (it's in advanced development now). So it's fair
to say it's probably just a matter of time.

Toni

Alex Blewitt wrote:
> There has been the suggestion (independently, a few times) that the
> Scala source tree moves to a distributed version control system, such as
> Git. This shouldn't be a part of the modularisation effort per se, but
> is still worth considering in its own right.
>
> Git does appear to be the DVCS of choice for a number of organisations
> (e.g. http://git.apache.org, and Eclipse has settled on Git as their
> DVCS as well) although Google Code uses Hg. But aside from the
> particular mechanism, sites like GitHub are increasingly popular (e.g.
> Lift) for many types of projects.
>
> What is EPFL's thoughts regarding a DVCS at some point in the future?
> What requirements need to be satisfied (both in terms of timing and also
> practicalities)?
>
> Alex
>

On Fri, 2009-09-11 at 12:17 +0200, Antonio Cunei wrote:
> That is not to say that we are not considering git at this time, and a
> migration is definitely in the cards. Right now we are focused on the 2.8
> release however, and switching at this time looks a bit unlikely.
>
> Once that is out of the door it will be a good time to consider the matter
> again. Also, some people in the team rely on SmartSVN, and SmartGit should
> be available by that time (it's in advanced development now). So it's fair
> to say it's probably just a matter of time.

I think this makes sense. 2.8.0 is a big and complex release as it is,
so any migration that involves changes from the EPFL guys should
probably happen after it's out.

Best,
Ismael

On Fri, 2009-09-11 at 10:32 +0100, Ismael Juma wrote:
> A thread that includes some answers:
>
> http://thread.gmane.org/gmane.comp.lang.scala/12307/focus=12399
>
> The link is for Martin's answer, but there are others in the thread that
> may be of interest.
>
> It's worth nothing

I mean "noting", not "nothing".

Ismael

> Once that is out of the door it will be a good time to consider the
> matter again. Also, some people in the team rely on SmartSVN, and
> SmartGit should be available by that time (it's in advanced
> development now). So it's fair to say it's probably just a matter of
> time.
>
Great news to hear. Git is a marvelous piece of software. I've been
through darcs and mercurial (all great) but git gives you another kind
of feeling.

Anyway, when the time comes to move to a DVCS, just open up the
discussion.. I would say the most important thing to consider is how
to best serve your current workflow, or see what can be done to
improve it.

Christos

Great news to hear. Git is a marvelous piece of software. I've been through darcs and mercurial (all great) but git gives you another kind of feeling.

It truly is. I keep discovering new features and new ways to optimise my workflow.
I already followed the "every ticket gits its own branch" mantra, and now I've discovered "git branch -m", I rename my ticket branches to track which tickets I've already integrated into svn trunk/which are waiting for approval/... 
Now all I need is automation&better integration with trac (and trac to get with web 2.0 already, so I can organise my tickets with drag&drop) 
As an example, `git branch` says something like (#annotated):
# branches for tickets I'm working on:  ticket/2281  ticket/2308# in trunk:  fixed/2201  fixed/2305  fixed/513# waiting for approval:   pending/2101  pending/2208  pending/2261  postponed/2266
(they're all on github: http://github.com/adriaanm/scala)
adriaan 

Adriaan,
If you don't mind handling the occasional pull request, would you be willing to offer your github mirror as a reference point for other clones?
Alternatively, I know that paulp has a github mirror available too, which tends to be heavily cloned.  Paul - I ask the same question of you :)


On Fri, Sep 11, 2009 at 4:48 PM, Adriaan Moors <adriaan.moors@cs.kuleuven.be> wrote:

Great news to hear. Git is a marvelous piece of software. I've been through darcs and mercurial (all great) but git gives you another kind of feeling.

It truly is. I keep discovering new features and new ways to optimise my workflow.
I already followed the "every ticket gits its own branch" mantra, and now I've discovered "git branch -m", I rename my ticket branches to track which tickets I've already integrated into svn trunk/which are waiting for approval/... 
Now all I need is automation&better integration with trac (and trac to get with web 2.0 already, so I can organise my tickets with drag&drop) 
As an example, `git branch` says something like (#annotated):
# branches for tickets I'm working on:  ticket/2281  ticket/2308# in trunk:  fixed/2201  fixed/2305  fixed/513# waiting for approval:   pending/2101  pending/2208  pending/2261  postponed/2266
(they're all on github: http://github.com/adriaanm/scala)
adriaan 

If you don't mind handling the occasional pull request, would you be willing to offer your github mirror as a reference point for other clones?

Sure, I'm a relative git(hub) newbie, but I think that should be fine.
 

 Alternatively, I know that paulp has a github mirror available too, which tends to be heavily cloned.  Paul - I ask the same question of you :)

This may be an argument in favour of standardising on Paul's repo. Not sure.
cheersadriaan

Not to get all lawyer-like on you, but I think any contribution into the Scala codebase needs to be accompanied by a CLA.  Pulling from other repositories seems to be a back door around this policy.
(Sorry Kevin)

On Fri, Sep 11, 2009 at 9:07 AM, Adriaan Moors <adriaan.moors@cs.kuleuven.be> wrote:

If you don't mind handling the occasional pull request, would you be willing to offer your github mirror as a reference point for other clones?

Sure, I'm a relative git(hub) newbie, but I think that should be fine.
 

 Alternatively, I know that paulp has a github mirror available too, which tends to be heavily cloned.  Paul - I ask the same question of you :)

This may be an argument in favour of standardising on Paul's repo. Not sure.
cheersadriaan

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Definitely!
I took it for granted that any code code accepted in this manner would only be from someone who had signed the agreement.
It might even make sense to allow commit privs to one of the known github mirrors for certain people.

On Fri, Sep 11, 2009 at 5:16 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Not to get all lawyer-like on you, but I think any contribution into the Scala codebase needs to be accompanied by a CLA.  Pulling from other repositories seems to be a back door around this policy.
(Sorry Kevin)

On Fri, Sep 11, 2009 at 9:07 AM, Adriaan Moors <adriaan.moors@cs.kuleuven.be> wrote:

If you don't mind handling the occasional pull request, would you be willing to offer your github mirror as a reference point for other clones?

Sure, I'm a relative git(hub) newbie, but I think that should be fine.
 

 Alternatively, I know that paulp has a github mirror available too, which tends to be heavily cloned.  Paul - I ask the same question of you :)

This may be an argument in favour of standardising on Paul's repo. Not sure.
cheersadriaan

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On Fri, Sep 11, 2009 at 04:59:09PM +0100, Kevin Wright wrote:
> Alternatively, I know that paulp has a github mirror available too,
> which tends to be heavily cloned.

I would say mine is the de facto git mirror of trunk, so to the extent
there's some advantage to having that in one place (and I don't know
what that advantage is) it may as well be me. Mine also has a few handy
branches available, like 2.7.x.

On Fri, Sep 11, 2009 at 05:48:10PM +0200, Adriaan Moors wrote:
> It truly is. I keep discovering new features and new ways to optimise
> my workflow.

Me too. Since I recently started a long-term parallel branch, I had to
research how to do that without spending my life merging. I hadn't
internalized the awesomeness of the double dot (patches in one branch
but not the other) and triple dot (all patches that are in only one of
the two branches.)

Some of these I will pull into trunk eventually, but I'm trying to
commit everything I have which isn't outright broken to the paulp branch
so that rather than having three dozen branches each slowly diverging
from trunk, I can have one big branch and just bite a merge bullet
periodically.

(Can you sense how much I enjoyed deleting all the MSIL code?)

trunk mirror: http://github.com/paulp/scala/tree/master
paulp branch: http://github.com/paulp/scala/tree/paulp

% git shortlog master..paulp | grep -v Merge

Paul Phillips (42):
Restored scala.io.*.
Removing dotnet and intellij files.
Removing everything MSIL.
More assorted removings.
More MSIL removal.
More MSIL deletion.
Removed phase "detach".
Removed assorted deprecateds.
Removed more files.
Removed .disabled files.
More deprecation removals.
More library removals.
Cleaning up deprecation fallout.
More removals - old scalacheck, MSIL libs, docs.
Adds scala.Zero for all your zero creation needs, and an orZero method to Option.
Unix scripts pass -D options (unaltered) and -J options (after dropping -J) to the underlying JVM invocation. Trac #1222.
Some minor tweaks to CompileSocket, and creation of scala.net.Socket.
Added applyOrElse to PartialFunction.
Small portion of UTF8 patch which I couldn't commit with the rest because svn write permissions were borked.
Fix for Trac #232323.
Fix for Trac #1437.
Creating some Directory methods for standard directories. Trac #2332.
Creates *experimental* scala.io.arm with cleaned up versions of the scalax.resource classes.
Creates two implicits in Ordering's companion which may make Ordering more easily usable. Some commented out sortWith implementations.
Some minor cleanups/tweaks to RichString.
Getting the socket patch and a few other loose ends into a more compilable state.
Restored some overly ambitious deletions.
Updating deprecated methods in test cases.
Fixed two failing tests.
Added zipWith.
Removed devirtualize phase.
JLine patch to make cygwin work better. Trac #2097.
Added =~, !~, etc. methods to RichString.
Added asm-3.2.jar to lib.
Never generate the ACC_SYNTHETIC flag in bytecode. Trac #1128.
Removed unused BitSet implementation.
A dated and needs-work set of reflection utilities. Includes a sizeOf implementation.
Assorted XML cleanups.
Made a plugin error less user unfriendly.

On Fri, Sep 11, 2009 at 09:16:52AM -0700, David Pollak wrote:
> Not to get all lawyer-like on you, but I think any contribution into
> the Scala codebase needs to be accompanied by a CLA. Pulling from
> other repositories seems to be a back door around this policy.

People who send me pull requests should have signed and sent in the
scala contributor agreement -- and assuming that's been done the door
would seem to face frontward. Or you can always sign the paulp license,
which grants me an irrevocable right to do whatever I want with any code
you write for the rest of your life, and then I can relicense it under
the scala license. Of course from that point forward you'll need my
explicit written permission to author code in any non-scala languages,
which I will consider on a case-by-case basis before rejecting them.