Hi,
1. I totally agree with suggestion of splitting the GitConnection artifact from the rest. This allows configuring various deliveries of Che without code
modifications, our JGit-based delivery
would be an excellent use case.
3. My change modifies the test configuration to execute the server tests twice – once for each implementation GitConnection. They pass.
Is there any progress with my pending pull requests? I guess the che-depmgmt is very simple as an initial step (git-ext one depends on it).
thank you
Tareq Sharafy
From: che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Gennady Azarenkov
Sent: Wednesday 03 June 2015 15:14
To: che developer discussions
Subject: Re: [che-dev] JGit
1/ I'd propose
che-plugin-git-impl-* instead of che-plugin-git-connection-*
2/ I think we will move Git server side to platform api from git plugin (apparently it is che-plugin-git-git and che-plugin-git-server)
On Wed, Jun 3, 2015 at 2:07 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
Before we start adoption of JGit, I would like to share couple of thoughts
1. I think we need make some housekeeping with source code of plugin-git
Proposal of maven structure
che-plugin-git-sharde - shared DTO
che-plugin-git-ext-git - GWT client
che-plugin-git-git - Server side components
che-plugin-git-server - Git server
che-plugin-git-connection-native - native git connection + TCK for git connection
che-plugin-git-connection-jgit - Jgit git connection
For che-plugin-git-connection-native we can package test in separate jar and reuse it in jgit module
2. I want to notify you that we would like to make some changes in determination of user name and email for commit, merge etc. We would like to take it from user profile
3. Have you test Git server with new Jgit?
On Sun, May 31, 2015 at 1:11 PM, Sharafy, Tareq <tareq.sharafy@xxxxxxx> wrote:
Hi,
The initial contribution is ready.
First, this is the pull request for upgrading from JGit version 2.3 to 3.7.1 in dependency management:
www.github.com/codenvy/che-depmgt/pull/3
Then this is the pull request for the JGit integration into the git extension server-side:
www.github.com/codenvy/che-plugins/pull/132
The second pull request depends on the first one through snapshots. Please review.
After we finish with this step, we'll proceed to the new APIs that we propose for addition (rebase,
revert, cherry-pick).
thank you
Tareq Sharafy
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Gennady Azarenkov
Sent: Friday 29 May 2015 18:13
To: che developer discussions
Subject: Re: [che-dev] JGit
Hi Tareq,
Could you propose additional Git methods (as a REST methods descriptions signature or as a pull request if you prefer or so), we shortly discuss it and plan/prepare Native Git impl
accordingly.
We'll try to sync with you but if you go too fast, we could just make dumb implementations for Native Git for some time :).
On Thu, May 28, 2015 at 6:51 PM, Sharafy, Tareq <tareq.sharafy@xxxxxxx> wrote:
Hi Gennady,
Updated for now, 270/273 of the unit tests of plugin-git-ext-git in master branch pass if the
I switch the connection to JGit.
The existing abstraction of git connections allows having both implementations packaged together.
The only required step in order to pick the git implementation is to change the injection of the GitConnectionFactory interface in GitModule. Since it is agreed on to have JGit side by side with native git, then this dual mode would not require a significant
effort from our side – especially that JGitConnection already satisfies the full GitConnection interface.
The only missing 'mini-feature' for now is that JGit does not utilize SshKeysManager yet, native
git does.
Please note that we might need to add missing APIs to the git service too – rebase, cherry-pick,
revert, ... and this dual mode would delay their contribution because they must be re-implemented in native git too.
thank you
Tareq Sharafy
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Gennady Azarenkov
Sent: Thursday 28 May 2015 14:04
To: che developer discussions
Subject: Re: [che-dev] JGit
Hi Tareq,
For the time we definitely keep Native Git for our cloud environment, so keeping both of them looks unavoidable.
We may consider JGit as a main backend for the Che SDK but we have to be prepared for this step, we need to make sure:
- JGit implementation is good enough tested
- JGit implementation has the same level of functionality that Native
- our Git extension is pluggable enough to have 2 different implementation (I really hope so but have not had 2 different implementation at the same time before).
Would you mind to contribute to this work to make the things faster?
On Thu, May 28, 2015 at 12:42 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
On Thu, May 28, 2015 at 12:35 PM, Sharafy, Tareq <tareq.sharafy@xxxxxxx> wrote:
Hi,
Thank you for accepting the case.
The next question is: is it still mandatory to have JGit side-by-side with native git or just
replace native git with JGit?
Yes, we are still thinking that native git is prefered for production.
thank you
Tareq Sharafy
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergii Kabashniuk
Sent: Wednesday 27 May 2015 09:33
To: che developer discussions
Subject: Re: [che-dev] JGit
Awsome.
I think it's enaugh proff to be accepted as alternative (to native) git implementation.
Sergii Kabashniuk
On Wed, May 27, 2015 at 9:00 AM, Sharafy, Tareq <tareq.sharafy@xxxxxxx> wrote:
Hi,
The previous benchmarks were partial due to the limited VMs that I had at hand, sorry if it was
not informative enough.
Here are my full results for the use cases: (all numbers are clone durations in seconds)
1.
One 1GB file:
JGit: 103, 93, 80
git: 105, 159, 123
2.
Four 256MB files:
JGit: 200, 185, 228
git: 201, 267, 194
3.
One 256MB with four revisions:
JGit: 191, 218, 229
git: 216, 200, 194
All the clone operations were performed on the same machine. The same remote repository is used
for each use case and is located on a remote machine over the network. As shown, each clone operation is repeated three times independently to stabilize the results.
thank you
Tareq Sharafy
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergii Kabashniuk
Sent: Monday 25 May 2015 16:47
To: che developer discussions
Subject: Re: [che-dev] JGit
Command-line git – 170, 250, 220, 180 seconds
JGit – 260, 160, 190, 220 seconds
Is that number for this usecases ?
1. 1Gb file (single file) in repo
2. 4 - 256Mb files in single repo.
3. 1-256Mb file in repo with 4 changes.
On Mon, May 25, 2015 at 4:43 PM, Sharafy, Tareq <tareq.sharafy@xxxxxxx> wrote:
Hi,
Git add takes the same amount of time with both tools: about 47 seconds for both the single 1GB
file and the four 256MB files.
Git clone times vary significantly with large files due to the massive data transfer, but I see
similar results too.
I test cloning a remote repository with two commits, each adding a unique 256MB binary file:
Command-line git – 170, 250, 220, 180 seconds
JGit – 260, 160, 190, 220 seconds
Apparently JGit does perform similarly to native Git in cloning large binary files.
thank you
Tareq Sharafy
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergii Kabashniuk
Sent: Monday 25 May 2015 12:54
To: che developer discussions
Subject: Re: [che-dev] JGit
Right now I more worried about cloning operation. Have you check it?
But yes add operation is also interesting.
Hi Sergii,
JGit uses in-memory methods to reduce file IO, causing a slower performance when cloning binary
files.
Other operations (e.g. git add) with binary files on existing repositories perform exactly the
same in JGit. So, for example, if a user adds a large binary file to the index then JGit won't form any performance bottleneck compared to native Git.
Allow me to gently question these benchmarks in Che's context. Is Che supposed to provide a general
file storage solution?
Adding a huge file to the index would require uploading it to the server first and then executing
the add command.
Also, checking a huge file would be possibly followed by downloading it.
Specifically speaking about the 'accidental' case, we can think of configuring Che to limit the
size of a file that is being added to the index. JGit has such feature anyway.
I do agree that JGit can be integrated as a side-by-side tool with native Git, at least initially.
thank you
Tareq Sharafy
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergii Kabashniuk
Sent: Thursday 21 May 2015 11:38
To: che developer discussions
Subject: Re: [che-dev] JGit
My concern in the fact that user can add by mistake some large binary file to git.
If you can proof that JGit can handle such usecases
1. 1Gb file (single file) in repo
2. 4 - 256Mb files in single repo.
3. 1-256Mb file in repo with 4 changes.
we may think to accept JGit as optional alternative implementation to native git.
Hi all,
We started a fork project to integrate the most recent release of JGit (3.7.1, April 2015) into
Che's git extension. It is based on the previously removed JGit code and practically works fine. It is still in works and has missing features, e.g. using Che's credentials mechanism.
Per my understanding, an old version of JGit (2.3, February 2013) was used back when it was decided
to abandon it. Official JGit page reports significant performance improvements in clone, fetch and other features from 3.0 onwards.
http://wiki.eclipse.org/JGit/New_and_Noteworthy
We at SAP would be glad to re-evaluate the use cases that caused the performance issues you had
with JGit 2.3.
The goal is to proceed with the change and contribute it back to the mainstream open source version
of Che ASAP.
Here is the source code:
https://github.com/tareqhs/che-plugins
thank you
Tareq Sharafy
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergii Kabashniuk
Sent: Tuesday 31 March 2015 15:10
To: che developer discussions
Subject: Re: [che-dev] JGit
<jgit.version>2.3.1.201302201838-r</jgit.version>
Agree with Sergey.
There are two kinds of problem with native Git
1/ It requires additional installation for Che standalone
2/ It is some difficult (but not impossible) to implement advanced usecases on UI (as San Tan mentioned)
But it is not comparable with workability problems we had some time ago using JGit.
So, until we have strong evidences of JGit production readiness we have to support native git wrapper as a main option.
But it would be appreciated if someone wants to develop and contribute JGit version to be used standalone, We can even share our old code for this to use it as a starting point.
On Tue, Mar 31, 2015 at 11:18 AM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
As you mention "It's not impossible". Right now I don't see any blockers that you can't implement with native git.
We are not consider JGit as an option for hosted version. At least because number of testers and users JGit vs Native git are not comparable at all.
Which leads to the issues that we have on production. And we don't want to repeat it again.
But in the same time we opened for other implementations like JGit based for some other use cases.
Hi,
OK I didn't have a look in details to JGit, but with the native git used by the GUI, we have some issues
I will take 3 examples
1. Merge conflict using git pull
When you "git pull" and have conflicts, it ask you to solve the conflicts (git add) and continue with (git commit). With the current implementation, it's not possible as you can't perform the command "git commit" without options ....
With JGit you can detect that you are in a "conflict" state and suggest the right resolution step in the UI.
2. conflict while rebasing
It doesn't exist in the Git plugin but if you use git rebase it will ask you to solve conflicts and do actions: git rebase --continue after solving conflicts, or git rebase --abort to cancel. In both case, you will be stuck, and it's hard to handle that situation
by embedding Git.
In Eclipse IDE (using JGit) it handles the conflicts properly: asking me in the UI the actions to do. I guess there are some handlers behind it: easier to detect and to handle with Java.
3. push is asking for passphrase ... but not handle by UI
Usually i prefer using ssh key with passphrase. But using the native git command, it will ask my passphrase in the console ... not in the Web UI ...
Git native command is good when using it as a CLI. A lot of git commands needs interaction and is part of a global workflow. It's not impossible, but it's harder to deal with these cases with a embeded native git client.
Le 25/03/2015 15:56, Sergii Kabashniuk a écrit :
Sorry that was fast response. :)
For instance it was very surprised to see 200Mb files in his history.
And this use case was not the last.
Can you elaborate more about what are you missing for git conflict resolving?
On Wed, Mar 25, 2015 at 4:52 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
The main issue with jgit - is that we don't trust it. It was made by normal developers for normal developers.
On Wed, Mar 25, 2015 at 4:43 PM, Sun Tan <sun.tan@xxxxxxxxx> wrote:
Hi all,
The problem by using the command line version of git is that we can hardly handle the interactive side of it: for instance if you do a git pull or merge or rebase, and get into
conflict issue, it's hard to solve the conflicts at the moment with the current implementation of Che.
Is the problem only for clone ? maybe we could have a mixed usage:
- command line for clone
See attachments
On Tue, Mar 24, 2015 at 10:13 PM, Tyler Jewell <tyler@xxxxxxxxxxx> wrote:
@Sergii - do we have any old test sequences or selenium tests that offer algorithms for reproducing the issues?
On Tue, Mar 24, 2015 at 12:43 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
On Tue, Mar 24, 2015 at 9:28 PM, Sharav, Omer <omer.sharav@xxxxxxx> wrote:
Hi CheDev’s,
I understand that you saw some issues when trying to integrate JGit into Che, which led to using the Git binary instead.
We at SAP know a colleague who is contributing to JGit and would be interested to investigate the issues you encountered with regards to the JGit integration.
Would you be able to tell us how to recreate the integration (e.g. in which release was it present)?
It was in IDE2(Not in current codebase)
We are not recommended to use JGit. It's was extremely unpredictable with concurrent operations like clone in projects larger when "hello world"
From our experience git causes endless operation with 200% CPU usage lots of times.
Thanks!
Omer Sharav.
SAP.
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
|
