Home » Eclipse Projects » EGit / JGit » Update on project creation status
| | | |
Re: Update on project creation status [message #8665 is a reply to message #8653] |
Mon, 15 June 2009 19:45 |
Eclipse User |
|
|
|
Originally posted by: alex_blewitt.nospam.yahoo.com
Eclipse Webmaster (Denis Roy) wrote:
> Shawn Pearce wrote:
> > But I'm now
>> waiting on the foundation staff to finish creating my account. *sigh*
>
> I know people who know people who do stuff around here. =)
Great stuff! Hopefully we'll be able to start moving towards migration in the
not-too-distant future.
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.
In other news, I've been held up a bit with a few personal things so haven't
had much time to look at the webgit stuff, but if the move is imminent what
I'd like to do is wait until the target is there and then start with the
org.eclipse prefix from the start. Even if we start committing it into a
branch or something for the meantime, I'd like to try and get what I've done
so far up for others to see.
Alex
|
|
|
Re: Update on project creation status [message #8675 is a reply to message #8665] |
Mon, 15 June 2009 20:04 |
Eclipse Webmaster Messages: 607343 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 #8687 is a reply to message #8675] |
Mon, 15 June 2009 20:38 |
Eclipse User |
|
|
|
Originally posted by: alex_blewitt.nospam.yahoo.com
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 ...
Alex
|
|
| |
Re: Update on project creation status [message #8708 is a reply to message #8697] |
Tue, 16 June 2009 15:50 |
Shawn O. Pearce Messages: 82 Registered: July 2009 |
Member |
|
|
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 #8732 is a reply to message #8708] |
Wed, 17 June 2009 07:31 |
|
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.
;)
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
Re: Update on project creation status [message #8743 is a reply to message #8732] |
Wed, 17 June 2009 20:55 |
Robin Rosenberg Messages: 332 Registered: July 2009 |
Senior Member |
|
|
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] |
Thu, 18 June 2009 00:04 |
Shawn O. Pearce Messages: 82 Registered: July 2009 |
Member |
|
|
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 19: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 #8787 is a reply to message #8778] |
Fri, 19 June 2009 12:21 |
Eclipse User |
|
|
|
Originally posted by: j16sdiz.gmail.com
On 19/6/2009 3:00, Alex Blewitt wrote:
[...]
> 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?)
I guess a gerrit-like system would make IP folks a little bit easier.
Anonymous patch can't sneak in accidentally.
--
|
|
|
Re: Update on project creation status [message #8799 is a reply to message #8767] |
Sun, 21 June 2009 18:20 |
|
Shawn Pearce schrieb:
> 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.
As Alex mentioned, the idea would be to run GIT on the project's virtual
server. As long as we don't push to SVN or CVS and only do milestone,
integration or nightly builds everything is fine. When the project wants
to do a full release it needs to submit a full code dump of the release
through the IP process. AFAIK a diff scan is possible after the initial
dump was approved.
So, Egit could live with the GIT repository on the v-server for a while
till we want to make the 1.0 release.
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
Re: Update on project creation status [message #8809 is a reply to message #8799] |
Mon, 22 June 2009 08:32 |
Eclipse User |
|
|
|
Originally posted by: alex_blewitt.nospam.yahoo.com
Gunnar Wagenknecht wrote:
> So, Egit could live with the GIT repository on the v-server for a while
> till we want to make the 1.0 release.
Hopefully by then, Git's popularity within Eclipse will have increased by this
point in time, too. Chris A has proposed a read-only Git copy of Eclipse (ala
http://git.apache.org) for those interested in using Git to stay up to date
(but whilst the projects remain behind on their home CVS/SVN servers). If
there's enough confidence in Git as a general tool, and the corresponding
webmaster's comfort, it might be the case that it stays on Git for ever
without even having to make it to SVN directly.
Another thought occurs - what about having a git-cvsserver running on the
vserver? I think the biggest impedance mismatch at the moent is the (perceived
or real) lack of GUI tools. If there were a git-cvsserver running, and it
worked with the Eclipse CVS tools, then it might facilitate/expidite the
migration from CVS to Git.
Alex
|
|
| | | | | | |
Re: Update on project creation status [message #573081 is a reply to message #8665] |
Mon, 15 June 2009 20:04 |
Eclipse Webmaster Messages: 607343 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 15:50 |
Shawn O. Pearce Messages: 82 Registered: July 2009 |
Member |
|
|
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 #573232 is a reply to message #8708] |
Wed, 17 June 2009 07:31 |
|
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.
;)
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
Re: Update on project creation status [message #573248 is a reply to message #8732] |
Wed, 17 June 2009 20:55 |
Robin Rosenberg Messages: 332 Registered: July 2009 |
Senior Member |
|
|
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] |
Thu, 18 June 2009 00:04 |
Shawn O. Pearce Messages: 82 Registered: July 2009 |
Member |
|
|
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 19:00 |
Alex Blewitt Messages: 946 Registered: July 2009 |
Senior Member |
|
|
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 #573358 is a reply to message #8778] |
Fri, 19 June 2009 12:21 |
Eclipse User |
|
|
|
Originally posted by: j16sdiz.gmail.com
On 19/6/2009 3:00, Alex Blewitt wrote:
[...]
> 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?)
I guess a gerrit-like system would make IP folks a little bit easier.
Anonymous patch can't sneak in accidentally.
--
|
|
|
Re: Update on project creation status [message #573391 is a reply to message #8767] |
Sun, 21 June 2009 18:20 |
|
Shawn Pearce schrieb:
> 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.
As Alex mentioned, the idea would be to run GIT on the project's virtual
server. As long as we don't push to SVN or CVS and only do milestone,
integration or nightly builds everything is fine. When the project wants
to do a full release it needs to submit a full code dump of the release
through the IP process. AFAIK a diff scan is possible after the initial
dump was approved.
So, Egit could live with the GIT repository on the v-server for a while
till we want to make the 1.0 release.
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
| | | | | | | | | | | | |
Goto Forum:
Current Time: Fri Nov 08 23:12:57 GMT 2024
Powered by FUDForum. Page generated in 0.05351 seconds
|