Jump to: navigation, search

Difference between revisions of "EGit/Proposal"

Line 1: Line 1:
 
= THIS IS A DRAFT, WORK IN PROGRESS PROPOSAL, NOT AN ACTUAL OFFICIAL ECLIPSE PROJECT PROPOSAL YET =
 
= THIS IS A DRAFT, WORK IN PROGRESS PROPOSAL, NOT AN ACTUAL OFFICIAL ECLIPSE PROJECT PROPOSAL YET =
  
= Introduction =
 
  
 
The EGIT project is a proposed open source project under the Eclipse Technology Project.
 
The EGIT project is a proposed open source project under the Eclipse Technology Project.
Line 13: Line 12:
 
Traditional source code version control systems .....
 
Traditional source code version control systems .....
  
 +
= Introduction =
 +
The EGIT plugin is an Eclipse Team provider for Git (a.k.a. "Stupid Content Tracker", http://git.or.cz).
  
The EGIT plugin is a Team provider for Git (a.k.a. "Stupid Content Tracker", http://git.or.cz).
+
Git is the version control system originally developed for the Linux kernel by Linus Torvalds, and is now a general Source Code Management (SCM) tool. One of the Git strength is its ability to support distributed version tracking as well as more centralized schemes, in contrast with tradition SCM that offer only a centralized model (such as CVS and Subversion).
 
+
Beyond the Linux kernel team, Git is now used by many other projects, both for open source and commercial development.  
Git is the version control system originally developed for the Linux kernel by Linus Torvalds, and is now a general Software Configuration Management (SCM) and Distributed Version Control System (DVCS) used by many other projects, both for open source and commercial development. Git is a fast distributed SCM, which means every developer has a full copy of all history of every revision of the code making queries against the history very fast and versatile. The storage model also means most operations are ten to a hundred times faster than with traditional centralized SCMs such as CVS or Subversion. The integrity of the code is protected through the use of secure hashes of content and history, plus optional GPG(PGP)-signing of tags.
+
  
 +
Git is a fast distributed SCM, which means every developer has a full copy of all history of every revision of the code making queries against the history very fast and versatile. The storage model also means most operations are ten to a hundred times faster than with traditional centralized SCMs such as CVS or Subversion. The integrity of the code is guaranteed through the use of secure hashes on the content and history, plus optional GPG(PGP) key signing of tags.
  
 
= Project Goal =
 
= Project Goal =
 
+
The goal of the Egit project is to:
The goal is to implement a Team provider for the Git SCM for eclipse.
+
* implement an Eclipse Team provider for the Git SCM,
 +
* work towards the definitions of new Team extensions and GUI paradigm to better support distributed SCMs in general.
  
 
= Project Scope =
 
= Project Scope =
  
The project will implement a significant amount of functionality of Git in Java for use with primarily Eclipse, although the intention is that core functionality shall be usable outside the Eclipse platform. The limit to what can be implemented in Java is to be discovered. Core functionality is already implemented so we think that most if not all can be implemented in Java without significant performance loss.
+
The project will implement Eclispe tooling for the JGit Java implementation of Git.
 +
Specific attention will be focused on performance. Performance is a big deal with Git. It affects what can be done by being so much faster. Things that couldn't be done because of time constraints are now possible. These things like very fast checkouts, branching, branch switching, merging, tagging, software archeology and synchronization. Merge speed is probably the most important feature.
 +
The EGit plugin meta data shall be fully compatible with the meta data created by the native Git version so both can be used on the same checkout out repository.
  
Performance is a big deal with git. It affects what can be done by being so much faster. Things that couldn't be done because of time constraints are now possible. These things like very fast checkouts, branching, branch switching, merging, tagging, software archeology and synchronization. Merge speed is probably the most important feature.
+
Beyond the Git support implementation, the project will work towards defining new essential extensions to the Eclipse core platform Team framework to account for the specific issues and features provided by distributed version control systems.
 +
It is also our intent to reach out to other project that implement support for distributed SCM in Eclipse to collaborate and exchange in that domain.
  
The Git plugin shall be fully compatible with the native version so both can be used on the same checkout out repository.
+
Finally, the implications of adopting a distributed SCM approach can bring significant benefits especially for large open source projects such as Eclipse and can help lower the barrier to entry for new contributors and source code experimentation easier.
 +
The project will try to be a fervent advocate of distributed SCM benefits to the Eclipse community.
  
 
= Project description =
 
= Project description =
  
The Git team provider will provide the ability to do all everyday task in a Git work flow from inside Eclipse.
+
The Git team provider will provide the ability to do all everyday task in a Git work flow from inside Eclipse, integrated with the Eclipse Team framework, and providing new features specific to Git and distributed version control management.
  
 
== Features ==
 
== Features ==
* Initial project setup: The plugin will allow user to create new Git repositories.
+
* Initial project setup: Support to create new Git repositories.
  
 
* Importing existing code: Existing local Git repositories as well as remote repository can be imported. Remote repositories are imported by `cloning' them resulting in a local copy.
 
* Importing existing code: Existing local Git repositories as well as remote repository can be imported. Remote repositories are imported by `cloning' them resulting in a local copy.
  
* Replicating repositories: It shall be possible to distribute local version to other repositories through "push" operations as well as patches distributed by electronic mail. Receiving content shall be possible by fetching content via the git protocol (raw, ssh and http based) and via e-mailed patches directly from mailboxes, file or clipboard. "Bundles" shall also be supported.
+
* Replicating repositories: It shall be possible to distribute local version to other repositories through "push" operations as well as patches distributed by electronic mail. Receiving content shall be possible by fetching content via the git supported protocols (raw, ssh and http based) and via e-mailed patches directly from mailboxes, files or clipboard. "Bundles" shall also be supported.
  
 
* Quickdiff against any version shall be supported.
 
* Quickdiff against any version shall be supported.
Line 60: Line 66:
 
* Partial checkouts (currently not a native Git feature) shall be possible.
 
* Partial checkouts (currently not a native Git feature) shall be possible.
  
* Some form of synchronization with CVS. At least export to CVS, like git cvsexportcommit.
+
* Some form of synchronization with CVS or other SCM. At least export to CVS, like git cvsexportcommit.
  
== Perspectives ==
+
=== Perspective and Views===
A Git perspective will be provided for browsing repositories before importing Git projects.
+
* A Git perspective will be provided for browsing repositories before importing Git projects, pre-configured with available Team  views and new EGit views.
 +
* History viewer: An history viewer with graphical presentation of history and access for compare editors will be developed as well as other views that may be useful for distributed SCM.
 +
* Repository browser : An explorer for examining Git repositories not connected to an eclipse project. Importing projects shall be possible from here.
 +
* Global directory: An explorer to find manage Git repositories ( at the minimum minimum all known local clones and their "remotes")
  
== Extension points ==
+
=== Extension points ===
 
Quickdiff must be enhanced to allow selective committing.
 
Quickdiff must be enhanced to allow selective committing.
 +
New extensions points will be designed as needed to expose new core extensibility common to many distributed SCM.
  
== Views ==
+
=== Extensions to existing Eclipse Team functionality ===
A history viewer with graphical presentation of history and access for compare editors.
+
 
+
== Repository browser ==
+
An explorer for examining Git repositories not connected to an eclipse project. Importing projects shall be possible from here.
+
 
+
== Extensions to existing Eclipse Team functionality ==
+
 
Team provider
 
Team provider
 
Resource decorators
 
Resource decorators
 
Quickdiff provider
 
Quickdiff provider
  
== CVS export ==
+
==== CVS export ==
 
Git commits shall be exportable to a CVS repository with the same structure.  
 
Git commits shall be exportable to a CVS repository with the same structure.  
 
CVS import is a much harder problem where no perfect solution exists.
 
CVS import is a much harder problem where no perfect solution exists.
  
= Initial Code contributions =
+
= Organization=
The existing code base shall be re-licensed under the EPL (this has already been approved by current comitters).
+
  
= Relation to other projects, dependencies =
+
== Mentors ==
* Git - The SCM we want to provide an interface through. http://git.or.cz
+
TBD
  
* Mylyn - Task based IDE. Git is very much about simplifying the delivery of well defined solutions to specific problems in an orderly fashion so it seems both projects have similar objectives. I have no idea about what git integration with Mylyn would look like for lack of Mylyn knowledge.
+
== Initial Committers ==
 +
* Robin Rosenberg (project lead)?
 +
* Shawn Pearce (project lead) ?
 +
* Philippe Ombredanne
  
add blurb on jGit
 
  
SVN team provider
+
== Initial Code Contribution ==
 +
The initial code contribution is based on the existing EGit code base licensed under the EPL. (this has already been approved by current comitters).
  
Eclipse platform team support
+
=== Licensing and Intellectual property ===
CVS support
+
A point of note is that EGit depends on the JGit, a pure Java Git implementation of Git.
 +
JGit was originally licensed under a combination of GPL and LGPL and is now made available under a (BSD/Apache/MIT TBD) license.
 +
Git itself is licensed under the GPL V2.
 +
JGit is a clean implementation of the core Git data structures and as such has received the approval of the core Git maintainers (including LT, TBD) to be licensed under any open source license the authors wish.
  
  
= Development plan =
+
== Tentative Development plan ==
 
+
==Project Organization==
+
=== Lead ===
+
Shawn Pearce
+
 
+
=== Initial Committers ===
+
* Robin Rosenberg
+
* Shawn Pearce
+
* Philippe Ombredanne
+
  
=== Milestones planning ===
+
Some functionality already exists, but there is no real plan at the moment for lack of committed resources. The project's rough priorities are:
Some functionality already exists, but there is no real plan at the moment for lack of committed resources. A rough idea of prioritization is
+
  
 
Already done:
 
Already done:
Line 140: Line 139:
 
* Repacking (this a really a core Git feature and the one that can be really hard or impossible to perform in Java).
 
* Repacking (this a really a core Git feature and the one that can be really hard or impossible to perform in Java).
 
* Rename tracking is an on-demand feature in git. Git does not record such information, it discovers it from content. The tight data structures in git makes implementing this in real time possible, but could still be a challenge.
 
* Rename tracking is an on-demand feature in git. Git does not record such information, it discovers it from content. The tight data structures in git makes implementing this in real time possible, but could still be a challenge.
 +
 +
 +
 +
== Interested Parties ==
 +
TBD
 +
 +
== User community ==
 +
EGIt and JGit already have an established community and we expect that this community of users and contributors will join this new project at Eclipse. Of note is that the general support of Git on Windows is limited. By being platform neutral, EGit has the opportunity to provide advanced Git support also on this platform and serve the needs of a larger community.
 +
 +
= Relation to other Eclipse projects and to other open source projects =
 +
 +
* Git - The SCM we want to provide an interface through. http://git.or.cz
 +
* JGit - a pure Java implementation of Git licensed under (BSD/Apache/MIT TBD ?) license.
 +
 +
* Eclipse platform team support
 +
** CVS team provider
 +
** SVN team provider
 +
 +
* Mylyn - a Task based IDE that provides privileged integration with Eclipse-supported team providers . A possible integration with EGit could be considered.
 +
 +
* Buckminster

Revision as of 20:45, 29 March 2008

THIS IS A DRAFT, WORK IN PROGRESS PROPOSAL, NOT AN ACTUAL OFFICIAL ECLIPSE PROJECT PROPOSAL YET

The EGIT project is a proposed open source project under the Eclipse Technology Project.

According to the Eclipse Development Process, this proposal is intended to declare the intent and scope of the EGIT project as well as to gather input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.egit newsgroup.

Background

Here we need to put some quick intro on the value of a DVCS, and present a bit the field. I am sure Shawn has some good slides on tat, he had made a presnetation @ the GSOC mentor summit that we could extract some bits from.

Traditional source code version control systems .....

Introduction

The EGIT plugin is an Eclipse Team provider for Git (a.k.a. "Stupid Content Tracker", http://git.or.cz).

Git is the version control system originally developed for the Linux kernel by Linus Torvalds, and is now a general Source Code Management (SCM) tool. One of the Git strength is its ability to support distributed version tracking as well as more centralized schemes, in contrast with tradition SCM that offer only a centralized model (such as CVS and Subversion). Beyond the Linux kernel team, Git is now used by many other projects, both for open source and commercial development.

Git is a fast distributed SCM, which means every developer has a full copy of all history of every revision of the code making queries against the history very fast and versatile. The storage model also means most operations are ten to a hundred times faster than with traditional centralized SCMs such as CVS or Subversion. The integrity of the code is guaranteed through the use of secure hashes on the content and history, plus optional GPG(PGP) key signing of tags.

Project Goal

The goal of the Egit project is to:

  • implement an Eclipse Team provider for the Git SCM,
  • work towards the definitions of new Team extensions and GUI paradigm to better support distributed SCMs in general.

Project Scope

The project will implement Eclispe tooling for the JGit Java implementation of Git. Specific attention will be focused on performance. Performance is a big deal with Git. It affects what can be done by being so much faster. Things that couldn't be done because of time constraints are now possible. These things like very fast checkouts, branching, branch switching, merging, tagging, software archeology and synchronization. Merge speed is probably the most important feature. The EGit plugin meta data shall be fully compatible with the meta data created by the native Git version so both can be used on the same checkout out repository.

Beyond the Git support implementation, the project will work towards defining new essential extensions to the Eclipse core platform Team framework to account for the specific issues and features provided by distributed version control systems. It is also our intent to reach out to other project that implement support for distributed SCM in Eclipse to collaborate and exchange in that domain.

Finally, the implications of adopting a distributed SCM approach can bring significant benefits especially for large open source projects such as Eclipse and can help lower the barrier to entry for new contributors and source code experimentation easier. The project will try to be a fervent advocate of distributed SCM benefits to the Eclipse community.

Project description

The Git team provider will provide the ability to do all everyday task in a Git work flow from inside Eclipse, integrated with the Eclipse Team framework, and providing new features specific to Git and distributed version control management.

Features

  • Initial project setup: Support to create new Git repositories.
  • Importing existing code: Existing local Git repositories as well as remote repository can be imported. Remote repositories are imported by `cloning' them resulting in a local copy.
  • Replicating repositories: It shall be possible to distribute local version to other repositories through "push" operations as well as patches distributed by electronic mail. Receiving content shall be possible by fetching content via the git supported protocols (raw, ssh and http based) and via e-mailed patches directly from mailboxes, files or clipboard. "Bundles" shall also be supported.
  • Quickdiff against any version shall be supported.
  • Comparing any versions shall be supported.
  • Producing git-format patches to the clipboard shall be supported.
  • Selective commit (using the Quickdiff markers) shall be supported
  • Merge shall be supported
  • Cherry picking shall be supported
  • Re-base of branches shall be supported. This includes splitting, reordering and squashing (alternate term not to be confused with the normal meaning of "merge" in SCM terminology).
  • Branch switching, committing, amending commits and reset shall be supported.
  • Partial checkouts (currently not a native Git feature) shall be possible.
  • Some form of synchronization with CVS or other SCM. At least export to CVS, like git cvsexportcommit.

Perspective and Views

  • A Git perspective will be provided for browsing repositories before importing Git projects, pre-configured with available Team views and new EGit views.
  • History viewer: An history viewer with graphical presentation of history and access for compare editors will be developed as well as other views that may be useful for distributed SCM.
  • Repository browser : An explorer for examining Git repositories not connected to an eclipse project. Importing projects shall be possible from here.
  • Global directory: An explorer to find manage Git repositories ( at the minimum minimum all known local clones and their "remotes")

Extension points

Quickdiff must be enhanced to allow selective committing. New extensions points will be designed as needed to expose new core extensibility common to many distributed SCM.

Extensions to existing Eclipse Team functionality

Team provider Resource decorators Quickdiff provider

== CVS export

Git commits shall be exportable to a CVS repository with the same structure. CVS import is a much harder problem where no perfect solution exists.

Organization

Mentors

TBD

Initial Committers

  • Robin Rosenberg (project lead)?
  • Shawn Pearce (project lead) ?
  • Philippe Ombredanne


Initial Code Contribution

The initial code contribution is based on the existing EGit code base licensed under the EPL. (this has already been approved by current comitters).

Licensing and Intellectual property

A point of note is that EGit depends on the JGit, a pure Java Git implementation of Git. JGit was originally licensed under a combination of GPL and LGPL and is now made available under a (BSD/Apache/MIT TBD) license. Git itself is licensed under the GPL V2. JGit is a clean implementation of the core Git data structures and as such has received the approval of the core Git maintainers (including LT, TBD) to be licensed under any open source license the authors wish.


Tentative Development plan

Some functionality already exists, but there is no real plan at the moment for lack of committed resources. The project's rough priorities are:

Already done:

  • Connect to/create repositories for exiting projects
  • Create branches
  • Commit
  • Quickdiff against current revision
  • Resources decorators for tracked and modified resources as well as repository state
  • Basic compare of revisions

Underway:

  • Cloning and updating from remote repositories

Future:

  • Bisecting
  • Partial commits (i.e. committing partial changes)
  • Comprehensive handling of different character encodings in filenames and comments.
  • CRLF handling (unless we consider it unneeded)
  • Bugfixes for existing code
  • Formatting code for patch submission through e-mail
  • Apply patch
  • Rename/Copy tracking in compare revisions
  • Blame (annotate)
  • Merge
  • Rebase
  • External repository browser
  • Repacking (this a really a core Git feature and the one that can be really hard or impossible to perform in Java).
  • Rename tracking is an on-demand feature in git. Git does not record such information, it discovers it from content. The tight data structures in git makes implementing this in real time possible, but could still be a challenge.


Interested Parties

TBD

User community

EGIt and JGit already have an established community and we expect that this community of users and contributors will join this new project at Eclipse. Of note is that the general support of Git on Windows is limited. By being platform neutral, EGit has the opportunity to provide advanced Git support also on this platform and serve the needs of a larger community.

Relation to other Eclipse projects and to other open source projects

  • Git - The SCM we want to provide an interface through. http://git.or.cz
  • JGit - a pure Java implementation of Git licensed under (BSD/Apache/MIT TBD ?) license.
  • Eclipse platform team support
    • CVS team provider
    • SVN team provider
  • Mylyn - a Task based IDE that provides privileged integration with Eclipse-supported team providers . A possible integration with EGit could be considered.
  • Buckminster