GitSharp on a WCF shared port?

[Brannon]

WCF supports port sharing. I'm not aware of any source control
management system that supports a WCF connection, though. Would
GitSharp be able to fill that niche? There are a lot of people who
have hosted Windows servers and no way to use a nonstandard port or
WebDav.

I'm a little fuzzy on how GitSharp would be used in this manner. I'm
used the traditional SVN server-type thinking. Could I run a version
of GitSharp on my hosted server and use that as my backup repository?

[Meinrad Recheis]

GitSharp is a library to access and interact with git repositories. It does not contain any server implementations, in contrast to JGit, which does implement a simple HTTP servlet AFAIK.
You would need to write the server part on top of gitsharp. Maybe some of the transport code could be reused.
Cheers,
-- henon

--
For infos about GitSharp visit http://www.eqqon.com/index.php/GitSharp
To join this group visit http://groups.google.com/group/gitsharp

[Brannon]

So to clarify this further, GitSharp has some "transport" code where I
could insert my own transport?

[Meinrad Recheis]

On Sat, Feb 5, 2011 at 6:10 AM, Brannon <notac...@gmail.com> wrote:

So to clarify this further, GitSharp has some "transport" code where I
could insert my own transport?

yes. gitsharp implements http transport as well as transport over ssh. the ssh library seems to have a bug though.
-- henon

[...]

[Brannon]

A few more questions:

I notice that the Uri.User field has the "username:password". Would
you assume Basic authentication if those were set? If there was a
username but no password would that be Windows authentication? Or
none? Is the username always set to the current user or is that added
on the command line? Or is there some other authentication choice
information I can access globally?

[Brannon]

After starting to work on this I've got a few more questions:

1. I see that the TransportHttp supports Fetch but not Push. Why is
that?
2. For a WCF endpoint I will need a server situation -- something like
git-daemon. Is there any kind of TSR/daemon mode for GitSharp? Do any
of the other protocols host a server endpoint?
3. Is the TransportHttp endpoint just pointing to a WebDav type of
server or is there actually some server listening on the far end?

[Meinrad Recheis]

On Wed, Feb 23, 2011 at 6:22 AM, Brannon <notac...@gmail.com> wrote:

After starting to work on this I've got a few more questions:

1. I see that the TransportHttp supports Fetch but not Push. Why is
that?

I think push support wasn't ready in JGit when GitSharp was ported. One would need to compare the jgit snapshot from then with the current one to see how jgit did evolve and port the push implementation. I got a fork of jgit on github where I attached tags with GitSharp-commit-hashes to jgit commits so you can comprehend which jgit commits were ported by which gitsharp commits.
 

2. For a WCF endpoint I will need a server situation -- something like
git-daemon. Is there any kind of TSR/daemon mode for GitSharp? Do any
of the other protocols host a server endpoint?

I am afraid not. I was not able to port the simple HTTP server from JGit because the Java servlet code seemed to be non-reusable for c#. Maybe someone with better understanding of Java servlets could port it though.

3. Is the TransportHttp endpoint just pointing to a WebDav type of
server or is there actually some server listening on the far end?

I am not aware of any server impl. I am sorry for not being of much help.

Best wishes,
-- Henon

[Shawn Pearce]

On Wed, Feb 23, 2011 at 00:32, Meinrad Recheis
<meinrad...@gmail.com> wrote:
>> 2. For a WCF endpoint I will need a server situation -- something like
>> git-daemon. Is there any kind of TSR/daemon mode for GitSharp? Do any
>> of the other protocols host a server endpoint?
>
> I am afraid not. I was not able to port the simple HTTP server from JGit
> because the Java servlet code seemed to be non-reusable for c#. Maybe
> someone with better understanding of Java servlets could port it though.

The servlet stuff is a lot of magic goop, but really its pretty simple
in the end. C# needs a web service thing that can handle 4 URLS:

GET ...repository.../info/refs?service=git-upload-pack
GET ...repository.../info/refs?service=git-receive-pack

POST ...repository.../git-upload-pack
POST ...repository.../git-receive-pack

The first 2 need to generate a response that looks like the initial
advertisement portion of the UploadPack and ReceivePack classes. In
JGit we literally just exported that method as public in the API and
then had the servlet goop create the class and run the method, dumping
its results onto the stream back to the client. Pretty simple.

The second 2 need to take the POST body in and pass that to the
UploadPack or ReceivePack class, and take their output and return it
to the client. In JGit these are pretty simple classes, 10 lines or
something to find the repository for "...repository...", create the
class, and tie the POST body as the input stream and the response
output stream as the output stream.

There are a few gotchas, you need to implement gzip decoding of the
POST body if the Content-Encoding: gzip header is sent by the client.
You also need to send a special header line in the GET /info/refs
responses before the actual advertisement data, but that's about it.

Most of the servlet goop in JGit is to support the older dumb HTTP in
parallel to the new smart HTTP. I'm not sure this was actually worth
doing. Smart HTTP has been shipping in Git for over a year now. Almost
everyone's Git client speaks it, and if they don't, they are usually
OK with upgrading.

>> 3. Is the TransportHttp endpoint just pointing to a WebDav type of
>> server or is there actually some server listening on the far end?
>
> I am not aware of any server impl. I am sorry for not being of much help.

JGit's TransportHttp client only supports the newer smart HTTP
protocol for Git, which requires a Git-aware server software on the
server end to correctly format the GET /info/refs advertisement, and
correctly handle the POST /git-receive-pack containing the push
arguments and object data.

We never implemented the dumb HTTP protocol that uses WebDAV. We
probably never will, its horrible as a protocol for Git over HTTP.

--
Shawn.