Jason van Zyl wrote:
On 7 Sep 07, at 5:20 PM 7 Sep 07, Brian E. Fox wrote:
I don't currently, but have in the past used file:// for remote.
For deploying or actually pulling? Deploying is a totally different
story. I know tons of people who use file, dav, scp, and ftp. Strictly
for pulling I'm saying. And I'm not saying it will satisfy our users,
just throwing out the idea. But HTTP is pretty much ubiquitous, handles
all security concerns, easily distributed ...
I agree that http is the most widely used and will satisfy the majority of use
cases.
But consider the following use case: a commercial product delivering in the form of multiple
artifacts, which then the user will build upon (API level artifacts). Supporting a file:// protocol
would enable the artifacts to be delivered as a repo and would not require http access to import in
the local repo.
The use case was that we had to mirror our internal repo to another corp
network. We essentially zipped up the repo and transferred it to their
machine (regularly and automatically via scm), which set a mirror entry
pointing to the local fs. This had to be done this way because a proxied
connection to our internal repo was not allowed, they needed full copies
of the entire build in scm.
I think these tools could could probably be special tools using Wagon,
or something else like an rsync tool would be ideal.
I agree though that file:// is pretty useful. Just looking to make the
mechanism as streamlined, simple, and consistent as possible.
How is removing file:// going to simplify significantly the mechanism?
Cheers
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
