My understanding of darcs put is that it is essentially copying the patches to
the remote file system and then invoking 'darcs apply' in that repository.  This
would explain why 'darcs get' doesn't require a remote instance of darcs but
'darcs put' does.

Assuming I have the correct understanding, could 'put' be rewritten to put the
current way to a temporary directory and then upload, via HTTP PUT, scp or
whatever protocols darcs can speak, the results?

This may be slightly slower in some use cases, is it's possible that we may want
to retain the current functionality and choose between them with a commandline flag.

The bonus is that putting to machines without a remote darcs wouldn't require
the user to do the extra step of using scp, rsync or unison manually.  It would
also make 'darcs put' compatible with the Tahoe file system by simply turning on
support for HTTP PUT.

There may be patches in the remote repository that the current patches need to
be commuted past, right?  So the local side doing this trick might be unable to
do it unless it can get those remote patches.

P.S.  I really like the idea of using the Tahoe secure, distributed, persistent
storage grid to hold darcs repositories...

Oh, I was thinking of "darcs push", not of "darcs put".

So, I guess dagit's suggestion of making "darcs put" able to write to a "dumb
server" (one that doesn't know darcs) is much easier than what I was thinking of
-- making it possible "darcs push" to write to a dumb server.

Although it is interesting to note that the latter might also be possible.

On Mon, Sep 8, 2008 at 10:21 AM, Zooko <bugs@darcs.net> wrote:
>
> Zooko <zooko@zooko.com> added the comment:
>
> There may be patches in the remote repository that the current patches need to
> be commuted past, right?  So the local side doing this trick might be unable to
> do it unless it can get those remote patches.

Zooko, we discussed this over IRC and came to the conclusion that you
were having a thinko and confusing push with put and that we now both
agree that this comment is mistaken and should be ignored :)  I'm just
putting is note here for anyone that reads the bug details.

Thanks,
Jason

I'm promoting this to a feature because I think this is worth actively pursuing
(whereas the message behind a 'wishlist' item is 'patches welcome!')

It sounds like we could even reduce the code paths by making put call the
relevant bits of darcs get.  One minor bit of cleverness would be to get to the
target directory if local, else to a temporary directory.  I guess sftp will be
the way to go.

But no extra flags/choices, please!  Unless there's really a compelling reason
to keep the old giant-patch-bundle code, we can nuke it.

Removed Target-2.4 as it was not among the highly wanted things at the meeting
at the Vienna sprint.

HTTP PUT (and FTP PUT) would have to work file by file because I don't
see how you could uncompress the tarball on the server. I don't see an
improvement to just using a FTP client.

Now remains the SSH case. Two possible implementations would be:

A) rely on a tar executable on the server side: 1) local get 2) local
compress 3) scp 4) remote uncompress and delete tarball
B) rely on a darcs executable on the server side: 1) compress _darcs 2)
scp 3) remote darcs get and delete tarball

A) is more robust and likely to happen, for instance if the remote
machine is just the LAMP web server of your company/lab.

Is it worth mentioning sftp here?

I'm tentatively assigning this to Guillaume (no obligation!) because he
said that he might work on it.

gh wrote:
> HTTP PUT (and FTP PUT) would have to work file by file because I don't
see how you could uncompress the tarball on the server.

I agree that the first thing to do would be to make it work file by file 
over HTTP PUT, FTP PUT, and SFTP PUT.

However, the next thing to do is make it so that darcs *get* reads 
compressed bundles and not just reads individual files. Then darcs *put* 
could start writing compressed bundles.

Maybe darcs *get* already does read compressed bundles. Does it? I think 
making it do that was planned Future Work.

The following patch sent by Guillaume Hoffmann <guillaumh@gmail.com> updated issue issue1066 with
status=resolved;resolvedin=2.10.0 HEAD

* resolve issue1066: clone to ssh URL by locally cloning then copying by scp 
Ignore-this: 2778bc4774fe8d5c53d0011b2193c1c2
Introduce an internal flag ForgetParent that enable to clone
repositories while forgetting about their source (do not copy
sources nor caches).