Git# a fully managed Git implementation
=======================================
Igor Guerrero Fonseca <igfgt1@gmail.com>
Summary
~~~~~~~
Git is a fast, scalable, distributed revision control system, that is used in fairly big projects, one of the biggest problems of Git is his inclusion in tools(mostly IDE's), GUI clients, CLI applications and non-Unix platform like Windows. A very good way to solve this problems is making a Git implementation in managed code that can run on multiple platforms.
Benefits
~~~~~~~~
In my opinion Git is very good doing his job, the benefits of making a fully managed implementation are very interesting. With Git# a lot of paths will be open to Git, a Monodevelop plugin and also Visual Studio can benefits with this. Also Git can be used as a storage system to build rich desktop distributed applications, I can see software like Tomboy using Git# to handle notes remotely and in a distributed way, the same can go for Banshee and F-spot. Having a complete distribute system is having endless possibilities.
Understanding Of The Project
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The project can be separated in operational levels, all of this aims to implement a low level API and a high level API:
* Contributor: In this level is the more typical level in any community people without developer access will download a copy of the repository or modules. Some features to be implemented: git-show-branch, git-log, git-checkout, git-diff, git-reset, git-tag.
* Developer: In this level we have the people that are part of the project, developing it constantly and are completely trusted persons to give them accesses to change the project tree, also he will take care of reviewing the code from a "Contributor". Some features to be implemented: git-add, git-commit, git-clone, git-pull, git-push, git-fetch, git-format-patch
* Integrator: This is the high level developer that takes responsibility of applying all the patches from a "Contributor" and resolving the conflicts between "Developers". Some features to be implemented: git-diff*, git-am, git-merge*, git-pull, git-revert, git-push.
* Repository Administration: This is a level where all the other levels are involved because in Git we all manage a branch in our local repository. Some features to be implemented: git-fsck, git-init, git-init-db, git-clone.
Organization
~~~~~~~~~~~~
I and another fellow student will work in this project spliting it in two parts:
* Low level API: This includes the filesystem operations and the object model. This includes git-fsck, git-init, git-init-db, git-clone, git-cat-file, update-index, .
* High level API: This includes operational task to be able to manipulate the content in the branch. This includes git-merge, git-pull, git-push.
Plan
~~~~
* Week 1 May 26 - June 1: Automate using Nant and Nunit the creation, running and logging of the tests. Begin work in basic filesystem operations.
* Week 2 June 2 - June 8:
Week 3 June 9 - June 15:
Implementation of low level filesystem.
* Week 4 June 17 - June 22:
Implementation of filesystem database, tag system, index(cache) system.
* Week 5 June 23 - June 29:
Week 6 June 30 - July 6:
Implementation of Objects API, tree operation can be done after this.
* Week 7 July 7 - July 13 (Mid-Term):
Milestone: Filesystem, object and tree operations done.
Begin merge of the low and high level branches, identification of missing features to get a successful merge.
Begin work on basic merge low level api
* Week 8 July 14 - July 20:
Week 9 July 21 - July 27:
Begin work on checkout functionality
* Week 10 July 28 - August 3:
Week 11 August 4 - August 10:
checkout functionality done, implement missing tests
* Week 12 August 11 - August 17:
Final Milestone: Successful merge of both layers. Low level
features to manage the database objects indexes and basic merge operations and high level ones like merge, pull and push.
August 18 (Pencils Down)
Deliverables
~~~~~~~~~~~~
* Project plan
* Fully managed Git# implementation
* Set of tests to the Git# API
* Full set of documentation
Qualifications
~~~~~~~~~~~~~~
I'm sure that I can manage to finish this task, because I always exited about making developer tools, I work in a software company that makes developer tools for database connectivity(mertechdata.com) using C++, C# and a high level language called Dataflex. Also I have worked in Java using Cocoon for writing web applications with ASF member Antonio Gallardo.
I have used in all my experience SCM tools including SVN, CVS, Bazar and Sourcegear producs. Able to understand the process.
Personal Info
~~~~~~~~~~~~~
I have over 2 years of professional experience on various areas of Software Development and System Administration, includes job experience in ASF Member Antonio Gallardo's ISV company in Nicaragua writing web applications using Cocoon, developing desktop applications using Visual Basic .NET for a educational institution, being a member of the CC of UbuntuNI local users group of Ubuntu in Nicaragua and part of the QA team in Mertech Data Systems in Florida able to test their products in Unix and Windows platforms and with all types of database engines. More info, read my online resumé: http://igordevlog.blogspot.com/2007/06/my-resum.html
References
~~~~~~~~~~
* http://groups.google.com/group/google-summer-of-code-discuss/files
* http://git.or.cz/#documentation
Mar 24, 2008
Application for Google Summer of Code 2008, Mono Project
Subscribe to:
Post Comments (Atom)
disclaimer
Things written in this blog are my personal thoughts or points of view, and do not represent at all the position of my employer.
Content of this blog is:

Licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.

Licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.

4 comments:
Please let us know if your proposal is accepted. This is a fantastic idea! I love git, but its adoption in the Windows world is limited just as you say. It's taking over *nix projects, but not Windows. I would love for it to take over Windows as well.
Have you tried to compile git in managed C++? Doing so would minimize the differences between the git codebase and git.net. That would increase the likelihood of the codebase being a branch, rather than a fork.
Wow, man, thanks :)
I'm still researching about this, but the advantage of having a .NET implementation is what really motivate me to get into this project.
Perhaps you might want to inquire on the msysgit mailing list to see if there's interest. Or if you were to publish a git repository of your branch, I'd be interested in participating myself.
I think if you tried to use managed C++ you could keep 99% of the proper git codebase, and there's a strong likelihood that the project could reside on the git site itself!
JGit exist as an example of a reimplementation of Git, but I don't really know if the Git people have really considered porting Git to managed C++. This is interesting but managed C++ extensions are not implemented in GCC, so if we need a non-Microsoft .NET dependent Git implementation, I need to implement it with C#.
Anyway we'll see, I really hope to be accepted, so I can discuss this with my mentor.
Btw, Managed C++ GCC extensions is a Mono Project too: http://www.mono-project.com/StudentProjects#Managed_C.2B.2B_extensions_to_GCC
Post a Comment