SSHStore in bfile

[David Douard-2]

Hi Greg and others,

in my requirements to be able to use bfile in my project, I need to be ablt to
use the currently unimplementd SSHStore.

I have been digging a bit on the subjet. Have you already started working on
this?

If not, do you think we should use raw shell scp-like commands or we should
better use hg's curent mecanism, adding new commands to hg server, and using
it to perform data transfer. This latter solution seems more in the spirit of
mercurial, but have the drawback of requiring to have hg installed on the ssh
store server, which is not really necessary.

David

PS: I began to think about this latter solution, and if I can easily add
commands to hg's ssh server by monkeypatching the class, I had to do a very
dirty hack in order to be able to add "capabilities" to the sshserver, like:


# diry hack to be able to add capability to sshserve
sshserver_do_hello = sshserver.sshserver.do_hello
def _sshserver_do_hello(self):
    respond = self.respond
    caps = []
    self.respond = caps.append
    sshserver_do_hello(self)
    self.respond = respond
    caps.append('bfstore')
    allcaps = ' '.join([x.strip() for x in caps])    
    self.respond("%s\n" % allcaps)
sshserver.sshserver.do_hello = _sshserver_do_hello

Are there any better way of doing this?

--
David Douard                        LOGILAB, Paris (France), [phone]
Formations Python, Numpy, Debian :  http://www.logilab.fr/formations
Développement logiciel sur mesure : http://www.logilab.fr/services
Informatique scientifique :         http://www.logilab.fr/science

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Greg Ward-17]

On Tue, Oct 27, 2009 at 12:16 PM, David Douard <david.douard@...> wrote:
> in my requirements to be able to use bfile in my project, I need to be ablt to
> use the currently unimplementd SSHStore.
>
> I have been digging a bit on the subjet. Have you already started working on
> this?

No, but this *is* near the top of my priority list.  I hope to get to
it within the next week or so.  But I will glady accept help!

> If not, do you think we should use raw shell scp-like commands

I worked out a plan for doing this with a colleague.  Pretty sure I
can make work with one scp command per bfupdate/bfpush command.  But I
haven't done the real feasibility test to ensure that scp really
behaves as I think it behaves, so I could still be in for a surprise.

> or we should
> better use hg's curent mecanism, adding new commands to hg server, and using
> it to perform data transfer. This latter solution seems more in the spirit of
> mercurial, but have the drawback of requiring to have hg installed on the ssh
> store server, which is not really necessary.

I hadn't really considered this.  It is definitely more in the
Mercurial spirit, but I don't really know how to do it.  And doesn't
it really require hg + bfiles on the server?  For me, that is a very
minor drawback and quite tolerable.

Actually, my colleague and I pretty much decided that the simple
scp-based store would use scp:// URLs (same syntax as hg ssh:// URLs,
but different URL scheme).  That leaves the way open for ssh:// URLs
to use a more intelligent protocol ... just like you are proposing.
So if I knock off a quick and easy SCPStore, it might be a little less
elegant and efficient, but 1) it should be easier to implement and 2)
it'll have fewer server-side dependencies.  And I will happily accept
an SSHStore if you implement it!

> PS: I began to think about this latter solution, and if I can easily add
> commands to hg's ssh server by monkeypatching the class, I had to do a very
> dirty hack in order to be able to add "capabilities" to the sshserver, like:
>
> # diry hack to be able to add capability to sshserve
> sshserver_do_hello = sshserver.sshserver.do_hello
> def _sshserver_do_hello(self):
>    respond = self.respond
>    caps = []
>    self.respond = caps.append
>    sshserver_do_hello(self)
>    self.respond = respond
>    caps.append('bfstore')
>    allcaps = ' '.join([x.strip() for x in caps])
>    self.respond("%s\n" % allcaps)
> sshserver.sshserver.do_hello = _sshserver_do_hello
>
> Are there any better way of doing this?

Use the extension mechanism to wrap do_hello()?  It would be neat if
enabling bfiles on the server also added the required commands to the
protocol.

Greg

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[David Douard-2]

Hi,

Le Thursday 29 October 2009 03:17:30 Greg Ward, vous avez écrit :
> On Tue, Oct 27, 2009 at 12:16 PM, David Douard <david.douard@...>
wrote:

> > in my requirements to be able to use bfile in my project, I need to be
> > ablt to use the currently unimplementd SSHStore.
> >
> > I have been digging a bit on the subjet. Have you already started working
> > on this?
>
> No, but this *is* near the top of my priority list.  I hope to get to
> it within the next week or so.  But I will glady accept help!
>
> > If not, do you think we should use raw shell scp-like commands
>
> I worked out a plan for doing this with a colleague.  Pretty sure I
> can make work with one scp command per bfupdate/bfpush command.  But I
> haven't done the real feasibility test to ensure that scp really
> behaves as I think it behaves, so I could still be in for a surprise.
>
> > or we should
> > better use hg's curent mecanism, adding new commands to hg server, and
> > using it to perform data transfer. This latter solution seems more in the
> > spirit of mercurial, but have the drawback of requiring to have hg
> > installed on the ssh store server, which is not really necessary.
>
> I hadn't really considered this.  It is definitely more in the
> Mercurial spirit, but I don't really know how to do it.  And doesn't
> it really require hg + bfiles on the server?  For me, that is a very
> minor drawback and quite tolerable.

Here is a bundle implementing this latter solution. In fact, I've been playing
a bit with raw scp commands, and I found it to be not that easy. The solution
proposed here, using hg's serve mecanism offers more flexibility.

For example, it should be very easy to implement a http-based store.

The proposed implementation is mostly the code from the sshrepo, and seems to
work (on Linux), but have not been intensively tested. I have not yet wrote
unit tests.

> > PS: I began to think about this latter solution, and if I can easily add
> > commands to hg's ssh server by monkeypatching the class, I had to do a
> > very dirty hack in order to be able to add "capabilities" to the
> > sshserver, like:
> >
> > # diry hack to be able to add capability to sshserve
> > sshserver_do_hello = sshserver.sshserver.do_hello
> > def _sshserver_do_hello(self):
> >    respond = self.respond
> >    caps = []
> >    self.respond = caps.append
> >    sshserver_do_hello(self)
> >    self.respond = respond
> >    caps.append('bfstore')
> >    allcaps = ' '.join([x.strip() for x in caps])
> >    self.respond("%s\n" % allcaps)
> > sshserver.sshserver.do_hello = _sshserver_do_hello
> >
> > Are there any better way of doing this?
>
> Use the extension mechanism to wrap do_hello()?  

Sure, but my real uneasiness was about the temporary overloading of the
respond method.

> It would be neat if
> enabling bfiles on the server also added the required commands to the
> protocol.
> Greg



--
David Douard                        LOGILAB, Paris (France), [phone]
Formations Python, Zope, Debian :   http://www.logilab.fr/formations
Développement logiciel sur mesure : http://www.logilab.fr/services
Informatique scientifique :         http://www.logilab.fr/science


_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial