Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 337818

Summary:	[server] Provide REST API for git clone
Product:	[ECD] Orion	Reporter:	Tomasz Zarna <tomasz.zarna>
Component:	Client	Assignee:	Tomasz Zarna <tomasz.zarna>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	john.arthorne, Szymon.Brandys
Version:	0.2
Target Milestone:	0.2
Hardware:	PC
OS:	All
Whiteboard:
Bug Depends on:	338558
Bug Blocks:	337820, 338226, 338652, 340553

Description Tomasz Zarna

2011-02-22 07:30:12 EST

The scenario we would like to address with the API is not only allowing to clone a git repository, but also be able to point to a subfolder in the repository and make a project out of it.

There are at least 3 approaches we can consider implementing the API:

1) Add API for calling POST on /git/clones, which would clone the given repository into a hidden location in workspace. Return the location as a path in the filesystem in the response. And then used that location to link a project, call POST on /workspace/<id> with the ContentLocation returned in the previous step + an optional path in the clone. This approach reuses the existing API for creating projects, which is great, but the fact than anyone knowing location of the newly created clone can link to it may be considered a major drawback.

2) Similar to 1) but instead of returning location in the filesystem of the newly created clone the server would return a location in /file/<id> form. This would require us to modify the current API for creating project so it allows linking using a server path. What we gain doing that is an ability to verify if the user can link to the location he provided.

3) Finally, we could squash both operations (cloning and adding a project) into a single call. Doing POST on /git/clones would not only create a clone (in the hidden location) but it would also create a project and link it to the clone.

Comment 1 John Arthorne

2011-02-23 16:35:02 EST

I would lean towards 3). If you keep them separate, then you need this new concept of a "cloned repository that is not a project", which raises questions of how to access/modify/delete/manage authorization on such a thing.

Comment 2 Szymon Brandys

2011-02-23 17:18:03 EST

(In reply to comment #1)
> I would lean towards 3). If you keep them separate, then you need this new
> concept of a "cloned repository that is not a project", which raises questions
> of how to access/modify/delete/manage authorization on such a thing.

Actually there is option 4). 
- We create a clone first and this operation should not create any folder in the workspace. The clone location is /git/clone/[cloneId]. Its children locations are /git/clone/[cloneId]/[path]
- Then you can go to any node in the clone, call POST on it and pass the name of the top-level folder to create
- Even better would be to have a special importToWorkspaceLocation field in the git clone representation. This location would be used to import part of the clone to the workspace. It is a similar concept to import/export on files.

Comment 3 Szymon Brandys

2011-02-24 03:35:32 EST

(In reply to comment #2)
Tomek, as we chatted yesterday we would need GET /git/clone implemented that would return the list of existing clones. We need that to populate the git clones view.

Comment 4 Tomasz Zarna

2011-02-24 08:32:37 EST

I implemented 1) with  543ff2fa9a183237e0ef58a42d85886450c2b831, keeping in mind that this is a temporary solution. Next I thnik I will switch the implementation to 4) but first I'm going to add GET /git/clone from comment 3.

Comment 5 Tomasz Zarna

2011-02-24 11:44:55 EST

(In reply to comment #3)
>  we would need GET /git/clone implemented that would return the list of existing clones

Fixed with 24fc6dd3bcfb16b47097b6234401313022b2b9f0.

Comment 6 Szymon Brandys

2011-03-30 11:26:35 EDT

The initial work is done. We have new bugs raised against remaining issues.