Home » Eclipse Projects » EGit / JGit » Update on project creation status
| Update on project creation status [message #6820] |
Fri, 29 May 2009 13:17  |
Eclipse User |
|
|
|
We're not dead... I am still trying to get the paperwork completed by my
day-time employer so I can get my committer bit enabled with the Eclipse
Foundation. And its taking longer than expected to get the rather
simple form through legal.
Any week now... any week. :-(
|
|
| | | | |
| Re: Update on project creation status [message #8675 is a reply to message #8665] |
Mon, 15 June 2009 16:04  |
 Eclipse Webmaster
Messages: 607353
Registered: July 2009 |
Senior Member |
|
|
Alex Blewitt wrote:
> On that note, what are the plans for migrating the code base across, running a
> git server on the server, refactoring the code etc? It would be good if we
> didn't lose any uncommitted patches (e.g. the gitignore stuff I attached on
> code.google.com's issue tracker) as part of the move.
FWIW, I think that the egit project's 'official' code repository will
have to be on either SVN or CVS, since those are the only two repos that
the Foundation officially supports. The git server that you will set up
will be on your own virtual server, where you have root access and no
access to committer accounts for authentication. This sandbox server is
where everyone can discover the joys of git without any impact on real code.
Once all the right conditions have been met, then webmasters can tackle
adding a git server to the farm, where git is a supported code repo from
the Foundation.
Perhaps all that was clear, but your comment left me under the
impression that you'd use git for your eGit official code repo.
|
|
| | |
| Re: Update on project creation status [message #8708 is a reply to message #8697] |
Tue, 16 June 2009 11:50 |
| Eclipse User |
|
|
|
Eclipse Webmaster (Denis Roy) wrote:
> Alex Blewitt wrote:
>> Eclipse Webmaster (Denis Roy) wrote:
>>> FWIW, I think that the egit project's 'official' code repository will
>>> have to be on either SVN or CVS ... but your comment left me under the
>>> impression that you'd use git for your eGit official code repo.
>>
>> I'm just an interested bystander, me :-) The decision will no doubt
>> have to
>> come from the project leads.
>>
>> That said, I can envision a git repo (on the virtual server) which
>> periodically pushes (via git-svn, for example) from the
>> work-in-progress git
>> repository to the svn one.
>>
>> http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
>>
>> That said, I'd expect most of the work to be done against the git repo
>> rather
>> than the SVN repo if only to eat our own dogfood, even if it's just a
>> step
>> along the way. But I'll let more knowledgeable people than me take the
>> lead
>> here ...
>
> Agreed, that is how I envisioned it too. It's good to make sure
> everyone is on the same page, thanks.
I think we would all prefer to work against a Git repository, and have
some sort of automatic mirror dump commit-by-commit to SVN, perhaps with
a "git:commitid" commit property annotation, or just sticking it into
the commit message itself. For merges done in Git, we can just document
the 2nd parent in SVN, but treat it as a normal commit, since SVN pre
1.5 didn't even have a concept of merges. :-)
My only concern is attribution in the SVN server. If its an automated
hook in the git virtual server that writes to SVN, we need to auth as
the author in order to get SVN to take the attribution. That's going to
be a problem.
|
|
| | |
| Re: Update on project creation status [message #8743 is a reply to message #8732] |
Wed, 17 June 2009 16:55 |
| Eclipse User |
|
|
|
Gunnar Wagenknecht wrote:
> Shawn Pearce schrieb:
>> My only concern is attribution in the SVN server. If its an automated
>> hook in the git virtual server that writes to SVN, we need to auth as
>> the author in order to get SVN to take the attribution. That's going to
>> be a problem.
>
> On a side note, if we used CVS till there is an official GIT server, all
> committers would need to use and understand the Eclipse CVS tooling.
> That should help a bit when looking at things how they work with the CVS
> plug-in.
Using the CVS plugin does not help much in understanding how it actually
works. That is covered in a maze of interfaces not visible from the UI. Git
allows for a much better workflow so ripping off CVS/SVN too much will hurt
the Git plugin's usuability in the end, I think. A lot of details should be
similar, but workflow is not that one. I expect EGit to be very different,
because Git workflows are much more like Mylyn workflows than traditional
SVN or CVS workflows.
Egit developers should use Git and Egit for that plugin. One reason is
that we should eat our own dog food as much as possible.
Seems Shawn is set on using SVN here. It has the repository-wide versioning
model which matches Git better than CVS per-version model. I think we should
continue to use Git as our master repo and simply export from our master
branch to SVN, an never the other way, except tags. Other branches should
not be in SVN at all, unless we actually do releases from them.
-- robin
|
|
| |
| Re: Update on project creation status [message #8767 is a reply to message #8743] |
Wed, 17 June 2009 20:04 |
| Eclipse User |
|
|
|
Robin Rosenberg wrote:
> Seems Shawn is set on using SVN here. It has the repository-wide versioning
> model which matches Git better than CVS per-version model. I think we should
> continue to use Git as our master repo and simply export from our master
> branch to SVN, an never the other way, except tags. Other branches should
> not be in SVN at all, unless we actually do releases from them.
To be clear, I'd love to not use SVN *AT ALL*.
The *only* reason I'm willing to use it is because I must use one of SVN
or CVS, until Git is an official support repository. SVN is perhaps
easier to push atomic commits from Git into, so that's what I chose when
I requested the project to be created.
Ideally what I want is a canonical Git repository which flushes somehow
automagically into SVN if the Git committer is also an authorized SVN
committer for the EGit project. Thus, we eat our own dogfood, and only
use Git, but SVN contains an accurate trunk to make the IP folks at
Eclipse happy.
And, as you said, Git tags should be transferred to SVN as well by
making the correct "svn cp trunk tag/$name" to make "tag/$name" in SVN
exactly match the same tag in git.
But branches in Git probably aren't worth pushing there. I doubt we'll
have more than "master", and "pu"... and "pu" rewinds so really only
"master" is worth putting into SVN.
But the issue of identity in SVN is a problem.
|
|
|
| Re: Update on project creation status [message #8778 is a reply to message #8767] |
Thu, 18 June 2009 15:00 |
| Eclipse User |
|
|
|
Originally posted by: alex_blewitt.nospam.yahoo.com
Shawn Pearce wrote:
> Robin Rosenberg wrote:
>> Seems Shawn is set on using SVN here. It has the repository-wide versioning
>> model which matches Git better than CVS per-version model. I think we
should
>> continue to use Git as our master repo and simply export from our master
>> branch to SVN, an never the other way, except tags. Other branches should
>> not be in SVN at all, unless we actually do releases from them.
>
> To be clear, I'd love to not use SVN *AT ALL*.
>
> The *only* reason I'm willing to use it is because I must use one of SVN
> or CVS, until Git is an official support repository. SVN is perhaps
> easier to push atomic commits from Git into, so that's what I chose when
> I requested the project to be created.
Do you even need to push into SVN? Why not just operate a .git repository on
the virtual server for the Egit project, and solely use that? After all, the
point of this is to encourage the adoption of Git generally (and eGit
specifically). There's even an open bug about providing a read-only copy of
Git repositories for other projects in the Eclipse namespace (Robin, Shawn, I
took the liberty of adding you as a cc to the bug; please accept my apologies
if you didn't want that.)
> Ideally what I want is a canonical Git repository which flushes somehow
> automagically into SVN if the Git committer is also an authorized SVN
> committer for the EGit project. Thus, we eat our own dogfood, and only
> use Git, but SVN contains an accurate trunk to make the IP folks at
> Eclipse happy.
I don't think that'll make the IP folks any happier, though. After all, if
some 'bad code' gets into the SVN repo, they'll want to delete it - but it
will still be visible in the .git repository (and, if history is re-written in
SVN, then the git-svn copy will just put it back again, right?)
> But the issue of identity in SVN is a problem.
I agree ... but perhaps we should consider not using SVN at all?
Alex
|
|
| | | | | | | | | |
| Re: Update on project creation status [message #573081 is a reply to message #8665] |
Mon, 15 June 2009 16:04 |
Eclipse Webmaster
Messages: 607353
Registered: July 2009 |
Senior Member |
|
|
Alex Blewitt wrote:
> On that note, what are the plans for migrating the code base across, running a
> git server on the server, refactoring the code etc? It would be good if we
> didn't lose any uncommitted patches (e.g. the gitignore stuff I attached on
> code.google.com's issue tracker) as part of the move.
FWIW, I think that the egit project's 'official' code repository will
have to be on either SVN or CVS, since those are the only two repos that
the Foundation officially supports. The git server that you will set up
will be on your own virtual server, where you have root access and no
access to committer accounts for authentication. This sandbox server is
where everyone can discover the joys of git without any impact on real code.
Once all the right conditions have been met, then webmasters can tackle
adding a git server to the farm, where git is a supported code repo from
the Foundation.
Perhaps all that was clear, but your comment left me under the
impression that you'd use git for your eGit official code repo.
|
|
| | |
| Re: Update on project creation status [message #573188 is a reply to message #8697] |
Tue, 16 June 2009 11:50 |
| Eclipse User |
|
|
|
Eclipse Webmaster (Denis Roy) wrote:
> Alex Blewitt wrote:
>> Eclipse Webmaster (Denis Roy) wrote:
>>> FWIW, I think that the egit project's 'official' code repository will
>>> have to be on either SVN or CVS ... but your comment left me under the
>>> impression that you'd use git for your eGit official code repo.
>>
>> I'm just an interested bystander, me :-) The decision will no doubt
>> have to
>> come from the project leads.
>>
>> That said, I can envision a git repo (on the virtual server) which
>> periodically pushes (via git-svn, for example) from the
>> work-in-progress git
>> repository to the svn one.
>>
>> http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
>>
>> That said, I'd expect most of the work to be done against the git repo
>> rather
>> than the SVN repo if only to eat our own dogfood, even if it's just a
>> step
>> along the way. But I'll let more knowledgeable people than me take the
>> lead
>> here ...
>
> Agreed, that is how I envisioned it too. It's good to make sure
> everyone is on the same page, thanks.
I think we would all prefer to work against a Git repository, and have
some sort of automatic mirror dump commit-by-commit to SVN, perhaps with
a "git:commitid" commit property annotation, or just sticking it into
the commit message itself. For merges done in Git, we can just document
the 2nd parent in SVN, but treat it as a normal commit, since SVN pre
1.5 didn't even have a concept of merges. :-)
My only concern is attribution in the SVN server. If its an automated
hook in the git virtual server that writes to SVN, we need to auth as
the author in order to get SVN to take the attribution. That's going to
be a problem.
|
|
| | |
| Re: Update on project creation status [message #573248 is a reply to message #8732] |
Wed, 17 June 2009 16:55 |
| Eclipse User |
|
|
|
Gunnar Wagenknecht wrote:
> Shawn Pearce schrieb:
>> My only concern is attribution in the SVN server. If its an automated
>> hook in the git virtual server that writes to SVN, we need to auth as
>> the author in order to get SVN to take the attribution. That's going to
>> be a problem.
>
> On a side note, if we used CVS till there is an official GIT server, all
> committers would need to use and understand the Eclipse CVS tooling.
> That should help a bit when looking at things how they work with the CVS
> plug-in.
Using the CVS plugin does not help much in understanding how it actually
works. That is covered in a maze of interfaces not visible from the UI. Git
allows for a much better workflow so ripping off CVS/SVN too much will hurt
the Git plugin's usuability in the end, I think. A lot of details should be
similar, but workflow is not that one. I expect EGit to be very different,
because Git workflows are much more like Mylyn workflows than traditional
SVN or CVS workflows.
Egit developers should use Git and Egit for that plugin. One reason is
that we should eat our own dog food as much as possible.
Seems Shawn is set on using SVN here. It has the repository-wide versioning
model which matches Git better than CVS per-version model. I think we should
continue to use Git as our master repo and simply export from our master
branch to SVN, an never the other way, except tags. Other branches should
not be in SVN at all, unless we actually do releases from them.
-- robin
|
|
| |
| Re: Update on project creation status [message #573294 is a reply to message #8743] |
Wed, 17 June 2009 20:04 |
| Eclipse User |
|
|
|
Robin Rosenberg wrote:
> Seems Shawn is set on using SVN here. It has the repository-wide versioning
> model which matches Git better than CVS per-version model. I think we should
> continue to use Git as our master repo and simply export from our master
> branch to SVN, an never the other way, except tags. Other branches should
> not be in SVN at all, unless we actually do releases from them.
To be clear, I'd love to not use SVN *AT ALL*.
The *only* reason I'm willing to use it is because I must use one of SVN
or CVS, until Git is an official support repository. SVN is perhaps
easier to push atomic commits from Git into, so that's what I chose when
I requested the project to be created.
Ideally what I want is a canonical Git repository which flushes somehow
automagically into SVN if the Git committer is also an authorized SVN
committer for the EGit project. Thus, we eat our own dogfood, and only
use Git, but SVN contains an accurate trunk to make the IP folks at
Eclipse happy.
And, as you said, Git tags should be transferred to SVN as well by
making the correct "svn cp trunk tag/$name" to make "tag/$name" in SVN
exactly match the same tag in git.
But branches in Git probably aren't worth pushing there. I doubt we'll
have more than "master", and "pu"... and "pu" rewinds so really only
"master" is worth putting into SVN.
But the issue of identity in SVN is a problem.
|
|
|
| Re: Update on project creation status [message #573325 is a reply to message #8767] |
Thu, 18 June 2009 15:00 |
| Eclipse User |
|
|
|
Shawn Pearce wrote:
> Robin Rosenberg wrote:
>> Seems Shawn is set on using SVN here. It has the repository-wide versioning
>> model which matches Git better than CVS per-version model. I think we
should
>> continue to use Git as our master repo and simply export from our master
>> branch to SVN, an never the other way, except tags. Other branches should
>> not be in SVN at all, unless we actually do releases from them.
>
> To be clear, I'd love to not use SVN *AT ALL*.
>
> The *only* reason I'm willing to use it is because I must use one of SVN
> or CVS, until Git is an official support repository. SVN is perhaps
> easier to push atomic commits from Git into, so that's what I chose when
> I requested the project to be created.
Do you even need to push into SVN? Why not just operate a .git repository on
the virtual server for the Egit project, and solely use that? After all, the
point of this is to encourage the adoption of Git generally (and eGit
specifically). There's even an open bug about providing a read-only copy of
Git repositories for other projects in the Eclipse namespace (Robin, Shawn, I
took the liberty of adding you as a cc to the bug; please accept my apologies
if you didn't want that.)
> Ideally what I want is a canonical Git repository which flushes somehow
> automagically into SVN if the Git committer is also an authorized SVN
> committer for the EGit project. Thus, we eat our own dogfood, and only
> use Git, but SVN contains an accurate trunk to make the IP folks at
> Eclipse happy.
I don't think that'll make the IP folks any happier, though. After all, if
some 'bad code' gets into the SVN repo, they'll want to delete it - but it
will still be visible in the .git repository (and, if history is re-written in
SVN, then the git-svn copy will just put it back again, right?)
> But the issue of identity in SVN is a problem.
I agree ... but perhaps we should consider not using SVN at all?
Alex
|
|
| | | | | | | | | | | | | | |
Goto Forum:
Current Time: Tue Jul 01 15:58:48 EDT 2025
Powered by FUDForum. Page generated in 0.12108 seconds |
Home