Re: GIT push to sftp (feature request)

[Jan Hudec <bulb@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

On Mon, Aug 06, 2007 at 00:20:55 +0200, Matthieu Moy wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
> 
> > Git tries to be smart in at least 2 ways that don't work with dump
> > protocols: it works locklessly (yet it performs atomic updates) and it
> > sends only the objects needed over the wire (saving a lot of
> > bandwidth).
> >
> > Using dumb protocols it's impossible to do either.
> 
> That's not exactly true. You can't be as efficient with dumb protocols
> than you are with a dedicated protocol (something with some
> intelligence on both sides), but at least the second point you mention
> can be achieved with a dumb protocol, and bzr is a proof of existance.
> To read over HTTP, it uses ranges request, and to push over
> ftp/sftp/webdav, it appends new data to existing files (its ancestor,
> GNU Arch, also had a way to be network-efficient on dumb protocols).

I believe bzr locks are not completely safe in a sense that breaking a lock
does not cause the operation to immediately abort. GNU Arch ones did, but
it's specific data layout was part of a reason why it worked (it wrote the
data to a directory, so removing that would abort the operation).

> Regarding atomic and lock-less updates, I believe this is
> implementable too as soon as you have an atomit "rename" in the
> protocol. But here, bzr isn't a proof of existance, it does locking.

Actually rename or link is necessary for atomic updates, lockless or lockful.

Slight problem with it is, that unix (and similar) systems allow overwriting
another file on rename (and do so atomically in a sense the destination
always exists), while windooze fail if the target exists. Most network
protocols don't specify overwriting and simply do whatever the underlying
system does. GNU Arch solved this by renaming directories, which are not
overwriten under any system.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]