moving scala trunk from svn to git

On Sun, Jun 12, 2011 at 21:07, Paul Phillips <paulp@improving.org> wrote:

I wrote a document describing what needs to be done.  It is on a wiki
and can be edited to include the things I'm not thinking of, or better
ideas.  (There may well be lots of things needed at the epfl end on top
of this, but that's outside the intended scope.)

what kind of things do you have in mind?

On 6/12/11 12:17 PM, Lukas Rytz wrote:
> what kind of things do you have in mind?

It's my nonspecific understanding that there is internal-epfl tooling
which assumes svn. This could be a) incorrect, b) irrelevant, c) not an
issue because svn will continue as before and import the git commits the
same way git has been mirroring the svn commits, which would render that
observation irrelevant.

I would rephrase that line as "there may be obstacles to moving to git
which are out of my hands."

Might be worth adding a filter-branch pass to do some cosmetic cleanup.  Removing the gratuitous git-svn meta additions to commit messages is an obvious one, but a quick glance at the Git mirror hints that you haven't been using an authors file with git-svn.  That's something which I think is important if we want the history to be coherant between the old SVN-imported commits and the new Git ones (e.g. if Martin made a commit against the Git repo, it would show up as "Martin Odersky <odersky@epfl.iforget.theaddress.ch>", but when looking at a historical commit he made, the attribution would be simply "odersky").  This can be done either with filter-branch (see: http://stackoverflow.com/questions/392332/retroactively-correct-authors-with-git-svn) or by running a clean import from SVN.

Daniel

On Sun, Jun 12, 2011 at 2:07 PM, Paul Phillips <paulp@improving.org> wrote:

I wrote a document describing what needs to be done.  It is on a wiki
and can be edited to include the things I'm not thinking of, or better
ideas.  (There may well be lots of things needed at the epfl end on top
of this, but that's outside the intended scope.)

 https://github.com/scala/scala/wiki/Github-Move

On Sun, Jun 12, 2011 at 10:01 PM, Daniel Spiewak wrote:
> commit he made, the attribution would be simply "odersky").  This can be
> done either with filter-branch (see:
> http://stackoverflow.com/questions/392332/retroactively-correct-authors-...)
> or by running a clean import from SVN.

Here's some additional documentation from GitHub on that matter:

http://help.github.com/import-from-subversion/

If the email mapped by the authors file matches that of a registered
user on GitHub, the commits are linked to that user.

-jason

we have the maven-ant-tasks in the build today, so i think pushing all starrs to a repo and auto-resolving them shoildnt be too hard.   what nunbering scheme would you want to use in the future?

On Jun 12, 2011 3:07 PM, "Paul Phillips" <paulp@improving.org> wrote:
> I wrote a document describing what needs to be done. It is on a wiki
> and can be edited to include the things I'm not thinking of, or better
> ideas. (There may well be lots of things needed at the epfl end on top
> of this, but that's outside the intended scope.)
>
> https://github.com/scala/scala/wiki/Github-Move

On 6/12/11 1:31 PM, Josh Suereth wrote:
> we have the maven-ant-tasks in the build today, so i think pushing all
> starrs to a repo and auto-resolving them shoildnt be too hard. what
> nunbering scheme would you want to use in the future?

Starrs have to be forever if we want the historical mechanism to work,
so they are "releases" according to some reasonable test, but they can't
have any "release process", i.e. we have to be able to build them and
ship them immediately because sometimes it is too difficult to bootstrap
unless you can check in a new starr and new code together.

So living in that weird space, I think we keep versioning them according
to the trunk revision, e.g. starr-library-r12345.jar.

Which reminds me of another thing I left out. The one thing I like
about svn is having a canonical monotonically increasing number for the
standard master which one can refer to without suffering 40-char hashes.
I think we should preserve continuity and keep counting our rXXXXXs
after we switch. I know there's some code out there to do this but I
haven't explored it.

Which reminds me of another thing I left out.  The one thing I like
about svn is having a canonical monotonically increasing number for the
standard master which one can refer to without suffering 40-char hashes.
 I think we should preserve continuity and keep counting our rXXXXXs
after we switch.  I know there's some code out there to do this but I
haven't explored it.

This would make it practically nearly for someone to maintain a fork of Scala, since they would need their monotonically increasing identifiers to either rise in conjunction with the master or diverge entirely, depending on the intent of the fork.  Even maintaining a fork for the sake of contributing back to Scala would be difficult if the contribution was a language change, thus necessitating a starr snapshot that is distinct from the chain of snapshots which may be running in mater.

The fact is that Git doesn't play nicely with monotonicity.  Something to do with enabling parallel branches…

Daniel

This would make it practically nearly for someone to maintain a fork of Scala[...]

That was a practically nearly weird sentence.  I meant to say "practically impossible", I just deleted the wrong word when editing.

Daniel

On 6/12/11 1:46 PM, Daniel Spiewak wrote:
> This would make it practically nearly for someone to maintain a fork of
> Scala, since they would need their monotonically increasing identifiers
> to either rise in conjunction with the master or diverge entirely,
> depending on the intent of the fork.

It's true that it's not clear how to deal with non-linear history. I
still think that r12345 is a big improvement over
bee097eaaab8fedd7b0b19ebd94775c9bf2a9509 when it comes to referencing
things. You could still assign ids to commits, you just can't preserve
the time-meaningfulness of the numbers.

I'm not attached to this, I just don't want any aspect of the git move
to seem like a step backwards.

Hi,
Great to see movement in this area. :)
On Sun, Jun 12, 2011 at 9:41 PM, Paul Phillips <paulp@improving.org> wrote:

Which reminds me of another thing I left out.  The one thing I like about svn is having a canonical monotonically increasing number for the
standard master which one can refer to without suffering 40-char hashes.
 I think we should preserve continuity and keep counting our rXXXXXs
after we switch.  I know there's some code out there to do this but I
haven't explored it.

It's worth mentioning that 40-char hashes are often not needed. For example, git log --oneline uses 7 characters:
[ijuma@ijumah]~/src/scala-git% git log --oneline ca79199 Documented what I could figure out about late flags and anti-flags. Elim153df7a Performance tweaks for AbstractFile, no review.eb7327e Test case for implicits which unwrap typeclasses, something which must r 2acedb2 Views using methods implemented in terms of isEmpty (in particular, head
Best,Ismael

ok... thoughts on starr....

(1) go through svn creating org.scala-lang.starr artifacts for all new starr checkins tied to that revision number.   Bump the version (to be) stored in build.properties and apply the build patch for resolving starr remotely.

(2) When creating a new starr, assign it a uuid, which hopefully would be the same as the git commit you are currently working on.   If not, I'm sure an appropriate uuid can be found.   This is to support arbitrary numbers of branched public devel.

(3) For monotonically increasing version numbers in git, use jenkins to tag builds with their number.   Should help narrow down to X commits and help talk about linear history (relative to what jenkins sees).   Branches can tag with a branch name.

Thoughts?

On Jun 14, 2011 7:45 AM, "Ismael Juma" <ismael@juma.me.uk> wrote:
> Hi,
>
> Great to see movement in this area. :)
>
> On Sun, Jun 12, 2011 at 9:41 PM, Paul Phillips <paulp@improving.org> wrote:
>
>> Which reminds me of another thing I left out. The one thing I like
>> about svn is having a canonical monotonically increasing number for the
>> standard master which one can refer to without suffering 40-char hashes.
>> I think we should preserve continuity and keep counting our rXXXXXs
>> after we switch. I know there's some code out there to do this but I
>> haven't explored it.
>>
>
> It's worth mentioning that 40-char hashes are often not needed. For example,
> git log --oneline uses 7 characters:
>
> [ijuma@ijumah]~/src/scala-git% git log --oneline
> ca79199 Documented what I could figure out about late flags and anti-flags.
> Elim
> 153df7a Performance tweaks for AbstractFile, no review.
> eb7327e Test case for implicits which unwrap typeclasses, something which
> must r
> 2acedb2 Views using methods implemented in terms of isEmpty (in particular,
> head
>
> Best,
> Ismael

(3) For monotonically increasing version numbers in git, use jenkins to tag builds with their number.   Should help narrow down to X commits and help talk about linear history (relative to what jenkins sees).   Branches can tag with a branch name.

That's a lot of tags…  It's probably the only reasonable way to do it though.

Daniel

I agree.... hopefully tagging is relatively 'cheap' long term.  Other suggestions welcome :)

On Tue, Jun 14, 2011 at 10:40 AM, Daniel Spiewak <djspiewak@gmail.com> wrote:

(3) For monotonically increasing version numbers in git, use jenkins to tag builds with their number.   Should help narrow down to X commits and help talk about linear history (relative to what jenkins sees).   Branches can tag with a branch name.

That's a lot of tags…  It's probably the only reasonable way to do it though.

Daniel

Also note:  I don't think we really need a monotonically increasing version number.   This is just a last resort option if we feel this would be helpful in some manner.

On Tue, Jun 14, 2011 at 10:44 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I agree.... hopefully tagging is relatively 'cheap' long term.  Other suggestions welcome :)

On Tue, Jun 14, 2011 at 10:40 AM, Daniel Spiewak <djspiewak@gmail.com> wrote:

(3) For monotonically increasing version numbers in git, use jenkins to tag builds with their number.   Should help narrow down to X commits and help talk about linear history (relative to what jenkins sees).   Branches can tag with a branch name.

That's a lot of tags…  It's probably the only reasonable way to do it though.

Daniel