Re: Providing the functionality of CVS as a library
Larry == Larry Jones [EMAIL PROTECTED] writes: Larry To: [EMAIL PROTECTED] (Alex Taler) Larry Subject: Re: Providing the functionality of CVS as a library Larry Date: Sun, 3 Nov 2002 14:01:58 -0500 (EST) Larry There's only one client/server protocol that's used by all the client/ Larry server methods (pserver, ext, fork, etc.): see doc/cvsclient.*. And happily it can be invoked as cvs server on the command line, to support the local repository case and make development easier. Thanks for the pointer, it's just what I need. The libcvs project has now been approved (thanks Derek?), so if you're curious take a look at libcvs.cvshome.org. I've written some design docs for the API, and now we're working on an implementation of the CVS client purely in Perl. Alex -- Some men can swing by their heels on the flying trapeze; some men can become president of the republic; I can drink cognac. Henri Toulouse-Lautrec (as portrayed in Moulin Rouge) PGP: 42D0 66C2 9FF8 553A 373A B819 4C34 93BA 23DC 453B ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Providing the functionality of CVS as a library
Ah, completely forget - someone that I contacted on this list before sent me the beginnings of a library written in Perl for the cvs client/server protocol. I just took a look at it again yesterday, it is written well, there is a library and a sample client, the library only implements a couple commands so far, it's enough to do checkout/status/etc. The client assumes that you are using pserver, I don't see any reason you couldn't have a pipe to cvs server running through SSH though. The client is simple, it doesn't maintain CVS metadata dirs or anything, prints everything ( checkouts, etc ) to STDOUT. It would be kind of neat to have a complete Perl CVS client just as a proof-of-concept on the library though, I'll take a serious look at it once I get some of my other projects a little further along :) I've been thinking of replacing SandWeb's Repository::cvs with a better version of this library, it poses some problems with regard to supporting UNIX accounts in the way I'd like to, but nothing unsurmountable. Let me know if you'd like a copy, it's Artistic license/LGPL ( like Perl ). I haven't made any changes to it yet, just looked at it. Thanks, Rob On Sun, Nov 03, 2002 at 10:31:15PM -0800, Rob Helmer wrote: On Mon, Nov 04, 2002 at 12:08:01AM -0500, Alex Taler wrote: Rob == Rob Helmer [EMAIL PROTECTED] writes: Rob We looked at VCS::Cvs for inclusion into SandWeb, and realized the same Rob thing, so we wrote our own abstracted Perl CVS class ( Rob SandWeb::Repository::cvs ). Rob If you want to check it out, I'd reccommend getting the CVS version - Rob http://sandweb.sf.net Thanks, I took a look at it. It doesn't look quite like what I want. I am thinking of an API in which the managed CVS files are individual objects which you can manipulate. Along the same lines as in VCS::Cvs. The benefit I see to this approach is better handling of unusual cases. How do you handle error and unusual cases? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Providing the functionality of CVS as a library
For Java the jcvs project provides both a CVS client (with UI) and a package implementing the CVS client/server protocol that you can use to build your own CVS aware applications. http://www.jcvs.org/ I don't know if anyone has done this in other languages Martin Fuzzey Message: 5 Subject: Re: Providing the functionality of CVS as a library To: [EMAIL PROTECTED] (Alex Taler) Date: Fri, 1 Nov 2002 10:55:11 -0500 (EST) Cc: [EMAIL PROTECTED] From: [EMAIL PROTECTED] (Larry Jones) Alex Taler writes: My incentive for this comes from my experience with writing tools that wrap CVS. I found the parsing of the CVS output quite cumbersome, and prone to failure when I brought it to a new site. I know I'm not the only one who would benefit from such a library, so it seemed like a good idea. That's one of the motivations for the CVS client/server protocol -- the intent was the people should write new clients rather than trying to wrap the existing command-line client. Librarifying CVS would likely require a complete re-write. -Larry Jones ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Providing the functionality of CVS as a library
jlcarpenter == jlcarpenter [EMAIL PROTECTED] writes: jlcarpenter To: [EMAIL PROTECTED] jlcarpenter Subject: RE: Providing the functionality of CVS as a library jlcarpenter Date: Fri, 1 Nov 2002 09:40:12 -0800 jlcarpenter Isn't there a Java CVS client library used within jCVS? jlcarpenter Unfortunately for me the library is under a GPL which doesn't jlcarpenter let me use it within any ant tasks submitted to Jakarta. Thanks for the tip, it looks like a very thorough CVS client implementation. I'm sure it will be useful to me. It looks like the library is in fact under LGPL, so you should be able to use it, no? jlcarpenter Surely there is code on CPAN which interfaces with CVS even if jlcarpenter it is really pushing a command line under the covers. If there is, I couldn't find it. There's a module called VCS::Cvs, but it's just a skeleton, and hasn't been touched in a year. It is the perl interface the interests me the most at the moment. Alex -- Touch Bowler, then choose insertion point. -- Software at the local bowling alley. PGP: 42D0 66C2 9FF8 553A 373A B819 4C34 93BA 23DC 453B ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Providing the functionality of CVS as a library
Alex Taler writes: Do you mean the pserver protocol, and not ext? I will take a look at it, although I personally don't use pserver for security reasons. There's only one client/server protocol that's used by all the client/ server methods (pserver, ext, fork, etc.): see doc/cvsclient.*. -Larry Jones It's clear I'll never have a career in sports until I learn to suppress my survival instinct. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Providing the functionality of CVS as a library
On Sun, Nov 03, 2002 at 11:35:20AM -0500, Alex Taler wrote: If there is, I couldn't find it. There's a module called VCS::Cvs, but it's just a skeleton, and hasn't been touched in a year. It is the perl interface the interests me the most at the moment. Hello, We looked at VCS::Cvs for inclusion into SandWeb, and realized the same thing, so we wrote our own abstracted Perl CVS class ( SandWeb::Repository::cvs ). If you want to check it out, I'd reccommend getting the CVS version - http://sandweb.sf.net SandWeb itself is getting ready to enter beta, the APIs for things like Repository.pm and cvs.pm are frozen. It also depends on SandWeb::Shell, since that class is the point at which everything interfaces with the Unix shell. I originally wrote Repository::cvs to make it's own calls to the shell, it would be really easy to just remove the dependency on that class and make cvs-Shell() just do a direct call. SandWeb::Repository is a class that lets us abstract different version control systems from SandWeb, cvs.pm doesn't depend on it, it just gives us a standard API ( which is almost identical to cvs.pm's API, since we only support CVS so far :) ). HTH, Rob Helmer ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Providing the functionality of CVS as a library
Rob == Rob Helmer [EMAIL PROTECTED] writes: Rob We looked at VCS::Cvs for inclusion into SandWeb, and realized the same Rob thing, so we wrote our own abstracted Perl CVS class ( Rob SandWeb::Repository::cvs ). Rob If you want to check it out, I'd reccommend getting the CVS version - Rob http://sandweb.sf.net Thanks, I took a look at it. It doesn't look quite like what I want. I am thinking of an API in which the managed CVS files are individual objects which you can manipulate. Along the same lines as in VCS::Cvs. The benefit I see to this approach is better handling of unusual cases. How do you handle error and unusual cases? Alex -- Touch Bowler, then choose insertion point. -- Software at the local bowling alley. PGP: 42D0 66C2 9FF8 553A 373A B819 4C34 93BA 23DC 453B ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Providing the functionality of CVS as a library
On Mon, Nov 04, 2002 at 12:08:01AM -0500, Alex Taler wrote: Rob == Rob Helmer [EMAIL PROTECTED] writes: Rob We looked at VCS::Cvs for inclusion into SandWeb, and realized the same Rob thing, so we wrote our own abstracted Perl CVS class ( Rob SandWeb::Repository::cvs ). Rob If you want to check it out, I'd reccommend getting the CVS version - Rob http://sandweb.sf.net Thanks, I took a look at it. It doesn't look quite like what I want. I am thinking of an API in which the managed CVS files are individual objects which you can manipulate. Along the same lines as in VCS::Cvs. The benefit I see to this approach is better handling of unusual cases. How do you handle error and unusual cases? Hi Alex, Handling managed files as objects is a pretty cool idea conceptually, if you end up doing this let me know as I may be interested in collaborating ( SandWeb is going to use what you see there for the 1.0 release, after that who knows? ). Repository::cvs is really just a wrapper around the cvs command line utility, say you create a $repository object using R:c's constructor, then call it's methods ( which are for the most part one-to-one to the CVS commands ). You pass the filename or directory you wish to work with in the constructor. There is a seperate SandWeb::File object which we use to manupulate files, I think the concept could be extended to SandWeb::Repository as well. Anyway, in the case of CVS we generally handle errors based on the error level that the CVS binary leaves. -- Rob ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Providing the functionality of CVS as a library
Larry == Larry Jones [EMAIL PROTECTED] writes: Larry That's one of the motivations for the CVS client/server protocol -- Larry the intent was the people should write new clients rather than trying Larry to wrap the existing command-line client. Librarifying CVS would Larry likely require a complete re-write. Do you mean the pserver protocol, and not ext? I will take a look at it, although I personally don't use pserver for security reasons. I wondered if I would hear the words complete re-write. I thought that might be the reason this hadn't been done yet. However, I am still committed to it. Alex -- Why would anybody shoot at a police station? -- Assault on Precinct 13 PGP: 42D0 66C2 9FF8 553A 373A B819 4C34 93BA 23DC 453B ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Providing the functionality of CVS as a library
Shankar == Shankar Unni [EMAIL PROTECTED] writes: Shankar Alex Taler writes: I'm interested in working on providing the functionality of CVS as a library. Shankar I take it you mean the _client_ side of CVS as a library? Or are you Shankar talking about serving up CVS functionality from an embedded server? Yes, I mean the client side of CVS. -- Why would anybody shoot at a police station? -- Assault on Precinct 13 PGP: 42D0 66C2 9FF8 553A 373A B819 4C34 93BA 23DC 453B ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Providing the functionality of CVS as a library
Alex Taler writes: My incentive for this comes from my experience with writing tools that wrap CVS. I found the parsing of the CVS output quite cumbersome, and prone to failure when I brought it to a new site. I know I'm not the only one who would benefit from such a library, so it seemed like a good idea. That's one of the motivations for the CVS client/server protocol -- the intent was the people should write new clients rather than trying to wrap the existing command-line client. Librarifying CVS would likely require a complete re-write. -Larry Jones You can never really enjoy Sundays because in the back of your mind you know you have to go to school the next day. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Providing the functionality of CVS as a library
Alex Taler writes: I'm interested in working on providing the functionality of CVS as a library. I take it you mean the _client_ side of CVS as a library? Or are you talking about serving up CVS functionality from an embedded server? The first is quite useful - it would make it far more easy to wrap it in good GUI tools (instead of the somersaults that the various GUI clients have to go through today to parse the output). Also, providing hooks to provide standard client-side SCC APIs (like Microsoft's) also makes it more easy to integrate into IDEs. Unfortunately, there isn't much of a standard for these things outside the Micro world.. Good idea.. -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Providing the functionality of CVS as a library
Isn't there a Java CVS client library used within jCVS? Unfortunately for me the library is under a GPL which doesn't let me use it within any ant tasks submitted to Jakarta. The Microsofties should be able to compile a Java library into a .NET assembly using J#. (One might have to touch up the code here and there.) Then any application running within the CLR or able to use wrapped .NET code could use it regardless of language. The non-Java Unix heads could use C++ to access the Java library. I think there is an ant task that claims to automate wrapping a C++ interface around Java code and vice versa. Surely there is code on CPAN which interfaces with CVS even if it is really pushing a command line under the covers. Last I heard ActiveState is working on getting Perl to compile to the CLR. I think there is an effort to develop an open-source implementation of the CLR on Unix. This might help Unix heads who aspire to be Microsofties. James Lee Carpenter Software Engineer Household Technical Services 6602 Convoy Court San Diego, CA 92111 ph: 858-609-2461 email: [EMAIL PROTECTED] Shankar Unni [EMAIL PROTECTED] To:[EMAIL PROTECTED] omcc: Sent by: Subject: RE: Providing the functionality of CVS as a library [EMAIL PROTECTED] g 11/01/2002 08:41 AM Alex Taler writes: I'm interested in working on providing the functionality of CVS as a library. I take it you mean the _client_ side of CVS as a library? Or are you talking about serving up CVS functionality from an embedded server? The first is quite useful - it would make it far more easy to wrap it in good GUI tools (instead of the somersaults that the various GUI clients have to go through today to parse the output). Also, providing hooks to provide standard client-side SCC APIs (like Microsoft's) also makes it more easy to integrate into IDEs. Unfortunately, there isn't much of a standard for these things outside the Micro world.. Good idea.. -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Providing the functionality of CVS as a library
Hi, I'm interested in working on providing the functionality of CVS as a library. I've created a project called libcvs on cvshome.org to host the work. It's pending approval, so don't go look yet. I don't think there's anyone out there already doing, this, but please tell me if I'm wrong. I'm sure the idea has come up in the past, but I couldn't find discussion of it in the mailing list archives. Is there a reason that nothing like this is being done? My incentive for this comes from my experience with writing tools that wrap CVS. I found the parsing of the CVS output quite cumbersome, and prone to failure when I brought it to a new site. I know I'm not the only one who would benefit from such a library, so it seemed like a good idea. Of course there are lots of issues to be worked out, such as source licensing, using the existing CVS source, accessing remote repositories, and libraries in multiple languages. I look forward to working out all of these problems. Alex -- Why would anybody shoot at a police station? -- Assault on Precinct 13 PGP: 42D0 66C2 9FF8 553A 373A B819 4C34 93BA 23DC 453B ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
