Re: [fossil-users] Making the go tool support fossil
Lluís Batlle i Rossell writes: > Hello, > I'm trying to add fossil support to the 'go tool', as it supports > other VCSs: > http://golang.org/cmd/go/#hdr-Remote_import_path_syntax Starting with Golang and wonder if something has changed in between in regard to ability to provide Fossil support for 'go tool'? Sincerely, Gour -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Thu, Feb 21, 2013 at 11:16 AM, Lluís Batlle i Rossell wrote: > I'd make it work with the 'timeline' or 'clone' permission flags. > Using the clone rights for this purpose sounds reasonable to me. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Thu, Feb 21, 2013 at 02:13:14PM +0400, Konstantin Khomoutov wrote: > On Thu, 21 Feb 2013 10:28:52 +0100 > Lluís Batlle i Rossell wrote: > > [...] > > > That's correct, but Lluis is right in suggesting that we "should > > > have" a command like: > > > > > > fossil ping repo-address > > > > > > which can piggyback on the protocols supported by cloning (ssh/http > > > [s]), but: > > > > > > a) does no authentication checks (because we cannot know which > > > permissions would be required by later commands). > > > b) does no useful work - simply checks for connectivity. > > > c) returns a trivial response, e.g. "OK" or "FAIL", and uses the > > > exit code to report success/failure. > > > > Well it would be better if it reported something like 'fossil info' > > for tip. :) > > This might contradict point (a) above in certain setups, does it? > I mean that my own repos require authentication only for pushing but > supposedly there might be some use for locked down private repos. > I just don't know is it possible to "fully lock" a Fossil repo so that > any access to it must be authenticated. I find this behaviour reasonable: If the url had a username, it could ask for a password. And in any case, if the rights aren't ok to fetch the info, it should fail. I'd make it work with the 'timeline' or 'clone' permission flags. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Thu, 21 Feb 2013 10:28:52 +0100 Lluís Batlle i Rossell wrote: [...] > > That's correct, but Lluis is right in suggesting that we "should > > have" a command like: > > > > fossil ping repo-address > > > > which can piggyback on the protocols supported by cloning (ssh/http > > [s]), but: > > > > a) does no authentication checks (because we cannot know which > > permissions would be required by later commands). > > b) does no useful work - simply checks for connectivity. > > c) returns a trivial response, e.g. "OK" or "FAIL", and uses the > > exit code to report success/failure. > > Well it would be better if it reported something like 'fossil info' > for tip. :) This might contradict point (a) above in certain setups, does it? I mean that my own repos require authentication only for pushing but supposedly there might be some use for locked down private repos. I just don't know is it possible to "fully lock" a Fossil repo so that any access to it must be authenticated. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Thu, Feb 21, 2013 at 10:24:27AM +0100, Stephan Beal wrote: > On Thu, Feb 21, 2013 at 8:33 AM, Konstantin Khomoutov < > flatw...@users.sourceforge.net> wrote: > > > IOW, that shell pipeline was just an example demonstrated to you, so > > don't be too attached to the fact it requires a shell. > > > > That's correct, but Lluis is right in suggesting that we "should have" a > command like: > > fossil ping repo-address > > which can piggyback on the protocols supported by cloning (ssh/http[s]), > but: > > a) does no authentication checks (because we cannot know which permissions > would be required by later commands). > b) does no useful work - simply checks for connectivity. > c) returns a trivial response, e.g. "OK" or "FAIL", and uses the exit code > to report success/failure. Well it would be better if it reported something like 'fossil info' for tip. :) Just to make the command a bit more useful. The go tool will use it for 'ping' basically, though. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Thu, Feb 21, 2013 at 8:33 AM, Konstantin Khomoutov < flatw...@users.sourceforge.net> wrote: > IOW, that shell pipeline was just an example demonstrated to you, so > don't be too attached to the fact it requires a shell. > That's correct, but Lluis is right in suggesting that we "should have" a command like: fossil ping repo-address which can piggyback on the protocols supported by cloning (ssh/http[s]), but: a) does no authentication checks (because we cannot know which permissions would be required by later commands). b) does no useful work - simply checks for connectivity. c) returns a trivial response, e.g. "OK" or "FAIL", and uses the exit code to report success/failure. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Thu, Feb 21, 2013 at 11:33:42AM +0400, Konstantin Khomoutov wrote: > On Wed, Feb 20, 2013 at 11:22:00PM +0100, Lluís Batlle i Rossell wrote: > > [...] > > > stephan@tiny:~/cvs/fossil/fossil/src$ wget -q -O /dev/stdout > > > http://fossil-scm.org/index.html/json/HAI | grep -q '"timestamp":' && echo > > > OK || echo NOK > > > NOK > [...] > > Thank you, I didn't know this. But again, this supposes we have a shell > > interpreter. We don't have a shell interpreter there, and don't want to > > depend > > on one. :) > [...] > > Your analysis is incorrect: what you see here is mere piping of the > standard output stream of the first process (wget) to the standard input > of the second process (grep) and then running this or that code based on > the exit code of the last process in the pipeline (grep). I know how a shell code does the piping using syscalls. It looked to me that Stephan wasn't proposing to use fork/pipe/exec/dup though, but a shell single-liner. And as I mentioned before, this is a huge change in the go vcs.go code. > If you fear that coding a HTTP request like I outlined above would mean > requirement to deviate from some common approach currently implemented in > the `go get` code, then just first rework the current code to be more > modular, and then implement your Fossil backend in it. If all other VCS can be supported in 100 lines, and adding fossil requires adding 200 lines, it's not about making anything modular. When 80% of the code involved (20% = run commands, 80% = http GET, mkdir, piping, grep) is ONLY for fossil, I can't call it "modular". It will be just a lot of code that will be used ONLY for one target, no matter how I make it look like "it will work for any VCS similar to fossil too". :) Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Wed, Feb 20, 2013 at 11:22:00PM +0100, Lluís Batlle i Rossell wrote: [...] > > stephan@tiny:~/cvs/fossil/fossil/src$ wget -q -O /dev/stdout > > http://fossil-scm.org/index.html/json/HAI | grep -q '"timestamp":' && echo > > OK || echo NOK > > NOK [...] > Thank you, I didn't know this. But again, this supposes we have a shell > interpreter. We don't have a shell interpreter there, and don't want to depend > on one. :) [...] Your analysis is incorrect: what you see here is mere piping of the standard output stream of the first process (wget) to the standard input of the second process (grep) and then running this or that code based on the exit code of the last process in the pipeline (grep). Two points to note here: * Those `|'-s and "&&"-s and "||"-s are, in fact, bits of the Unix shell syntax, but the syntax is just that -- the way a shell allows you to construct pipelines and check exit codes of processes it runs. There's no problem to construct and supervise such a pipeline in Go, it will just be way more verbose since Go is way more lower-level than a Unix shell. The basic approach is outlined, for instance, here [1]. * The `wget` program in that example performs a simple HTTP GET request and is told to output the returned content to its standard output. The `grep` program tries to find a specific string in the text supplied to it from `wget`. But there's no need to run anything like this in Go: its standard library already has the net/http package to do HTTP requests and the JSON parser to parse the payload a request would return. IOW, that shell pipeline was just an example demonstrated to you, so don't be too attached to the fact it requires a shell. In fact, requiring `wget` is a way more serious restriction (and `grep`, too, by the way). If you fear that coding a HTTP request like I outlined above would mean requirement to deviate from some common approach currently implemented in the `go get` code, then just first rework the current code to be more modular, and then implement your Fossil backend in it. For instance, implement a type of some "VCS fetch function" then make each backend code (for each VCS) implement and provide such a function; then most backends would use a simple call to exec.Command(), and Fossil backend would be more involved. Make sure to first bring this idea to the golang-nuts mailing lists, and not just lurk implementing your patch bomb secretly to just dump it on the developers later ;-) -- their coding guidelines clearly hint at that rather involved changes should be openly discussed first. 1. http://stackoverflow.com/a/9323144/720999 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On 21 February 2013 04:57, Lluís Batlle i Rossell wrote: > 1) there were a way to clone+checkout at once into a subdirectory: > fossil clonedir http://blabla.org/ blabla > # ^ It creates blabla/, blabla/.repository.fossil, and in it, checks out > # the .repository.fossil, for example > Marc Simpson's *fsl* wrapper gives you the ability to make all kinds of neat alterations to Fossil's command line. Instructions for doing so are here: http://yfl.bahmanm.com/Members/ttmrichter/yfl-blog/fsl-interceptor-creationand examples that cover your specific use case are found in the cookbook here: http://fossil.0branch.com/fsl/wiki?name=Cookbook -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Wed, Feb 20, 2013 at 11:20:18PM +0100, Stephan Beal wrote: > On Wed, Feb 20, 2013 at 11:18 PM, Lluís Batlle i Rossell > wrote: > > > I will try to do all the new code required for that, but I doubt it will be > > accepted easily. And the lack of the command to check an upstream server > > will > > also make my patch look even worse, compared to the code that was there. > > > > Would a new page, e.g. /ping, which simply returns HTTP 200 and no content > (or a single line, like "ok") suffice? It has to be something that the 'fossil' command can run alone, and return a good or a bad errorcode depending on upstream being a fossil repository or not. Thank you, Lluís ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Wed, Feb 20, 2013 at 5:20 PM, Stephan Beal wrote: > On Wed, Feb 20, 2013 at 11:18 PM, Lluís Batlle i Rossell > wrote: > >> I will try to do all the new code required for that, but I doubt it will >> be >> accepted easily. And the lack of the command to check an upstream server >> will >> also make my patch look even worse, compared to the code that was there. >> > > Would a new page, e.g. /ping, which simply returns HTTP 200 and no content > (or a single line, like "ok") suffice? > I think he'd still want a client-side command to query the /ping command on the server. And in either case, that wouldn't really work for file: or ssh:. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Wed, Feb 20, 2013 at 11:18:35PM +0100, Stephan Beal wrote:
> On Wed, Feb 20, 2013 at 9:57 PM, Lluís Batlle i Rossell
> wrote:
>
> > 2) and if there were a way to check if an upstream repository answers
> > correctly, other than by cloning into a file:
> > fossil remoteinfo http://blabla.org/
> > # ^ Error if the other side isn't a fossil repository
> >
>
> As a workaround for this lacking feature (which sounds like a good one to
> me), the json API could be used to see if a URL is-a fossil server
> (assuming json's enabled on the remote):
>
> stephan@tiny:~/cvs/fossil/fossil/src$ wget -q -O /dev/stdout
> http://fossil.wanderinghorse.net/repos/cson/index.cgi/json/HAI | grep -q
> '"timestamp":' && echo OK
> OK || echo NOK
>
> If it's not enabled:
>
> stephan@tiny:~/cvs/fossil/fossil/src$ wget -q -O /dev/stdout
> http://fossil-scm.org/index.html/json/HAI | grep -q '"timestamp":' && echo
> OK || echo NOK
> NOK
Hello Stephan,
Thank you, I didn't know this. But again, this supposes we have a shell
interpreter. We don't have a shell interpreter there, and don't want to depend
on one. :)
('We' as a shortcut for what I suppose will be the answer of the go community:
we will first not support fossil, instead of depending on multiplatform code for
shell interpreters. Not that I'm representative of anything around go)
Thank you,
Lluís
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Wed, Feb 20, 2013 at 11:18 PM, Lluís Batlle i Rossell wrote: > I will try to do all the new code required for that, but I doubt it will be > accepted easily. And the lack of the command to check an upstream server > will > also make my patch look even worse, compared to the code that was there. > Would a new page, e.g. /ping, which simply returns HTTP 200 and no content (or a single line, like "ok") suffice? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Wed, Feb 20, 2013 at 9:57 PM, Lluís Batlle i Rossell wrote: > 2) and if there were a way to check if an upstream repository answers > correctly, other than by cloning into a file: > fossil remoteinfo http://blabla.org/ > # ^ Error if the other side isn't a fossil repository > As a workaround for this lacking feature (which sounds like a good one to me), the json API could be used to see if a URL is-a fossil server (assuming json's enabled on the remote): stephan@tiny:~/cvs/fossil/fossil/src$ wget -q -O /dev/stdout http://fossil.wanderinghorse.net/repos/cson/index.cgi/json/HAI | grep -q '"timestamp":' && echo OK OK || echo NOK If it's not enabled: stephan@tiny:~/cvs/fossil/fossil/src$ wget -q -O /dev/stdout http://fossil-scm.org/index.html/json/HAI | grep -q '"timestamp":' && echo OK || echo NOK NOK -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Wed, Feb 20, 2013 at 05:00:13PM -0500, Richard Hipp wrote: > On Wed, Feb 20, 2013 at 3:57 PM, Lluís Batlle i Rossell > wrote: > > > 1) there were a way to clone+checkout at once into a subdirectory: > > fossil clonedir http://blabla.org/ blabla > > # ^ It creates blabla/, blabla/.repository.fossil, and in it, checks out > > # the .repository.fossil, for example > > > mkdir blabla > cd blabla > fossil clone http://blabla.org/ .repo > fossil open .repo Sure, I know. But this requires issuing those orders in a shell, and that means writing per-platform go code, instead of a simple 'universal' exec.Cmd. Because Windows may have cmd, command, ... Others may have flavours of 'sh', ... If not using a shell, 'cd' will affect the working directory of the process, or has to be done after forking, before execing fossil, ... This is already much more complicated than what has been required until now. Imagine you have a C program, and no shell. The formula that worked for the other VCS just doesn't work for fossil. I will try to do all the new code required for that, but I doubt it will be accepted easily. And the lack of the command to check an upstream server will also make my patch look even worse, compared to the code that was there. Regards, Lluís ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Making the go tool support fossil
On Wed, Feb 20, 2013 at 3:57 PM, Lluís Batlle i Rossell wrote: > 1) there were a way to clone+checkout at once into a subdirectory: > fossil clonedir http://blabla.org/ blabla > # ^ It creates blabla/, blabla/.repository.fossil, and in it, checks out > # the .repository.fossil, for example > mkdir blabla cd blabla fossil clone http://blabla.org/ .repo fossil open .repo -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Making the go tool support fossil
Hello, I'm trying to add fossil support to the 'go tool', as it supports other VCSs: http://golang.org/cmd/go/#hdr-Remote_import_path_syntax Adding fossil supprt requires lots of changes, due to a lack of similarity with the other VCS supported. The current code is not flexible enough, and I think that some of the pieces it requires from the VCS would be nice to have in fossil. Specifically, these things would be much easier if: 1) there were a way to clone+checkout at once into a subdirectory: fossil clonedir http://blabla.org/ blabla # ^ It creates blabla/, blabla/.repository.fossil, and in it, checks out # the .repository.fossil, for example 2) and if there were a way to check if an upstream repository answers correctly, other than by cloning into a file: fossil remoteinfo http://blabla.org/ # ^ Error if the other side isn't a fossil repository The point '2' is important because go uses some kind of addresses without the front protocol: blabla.org/repo for example. And then it uses the required "command 2" to test different modifiers: http://, https://, ... Currently I've no way other than cloning (and this requires creating a file!) to test the future client sync. The currently supported VCS have a way to run these commands: bazaar, git, mercurial, subversion. Is there any chance that fossil gets into that shape? Even if partially? Otherwise the 'go' patch just to support fossil will be a so big rework, that will be much harder to be accepted. As a note, here is the current vcs handling code: http://golang.org/src/cmd/go/vcs.go Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
