From: Eric Hodel Date: 2005-04-13T02:20:26+09:00 Subject: Re: Accessing SVN through Ruby --Apple-Mail-26--272273634 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 12 Apr 2005, at 06:33, Bob Aman wrote: > Nice, an answer that might get me somewhere. Thank you! > >> DL is a generic dynamically-linked library wrapper that requires none >> of this C compiler business. You load a so/dll and tell Ruby what the >> parameters are for the C calls, and it takes care of all the argument >> passing for you. >> >> DL ships with ruby 1.8, but there doesn't seem to be an exact home >> page >> for it. >> >> http://www.google.com/search?q=ruby+dl >> >> Will give you several tutorial/documents on it. >> >>>> svn lists easily parseable output as one of its features... >>> >>> I don't think calling out to the command line client is a truely >>> viable option. >> >> Why? > > The requirement of having to be able to modify the metadata. I assume > there's no way to modify the metadata in place through the client. If > there is, then that very nearly settles it, I think. (Only thing left > to deal with is my irrational apprehention every time I shell out for > something. Plus my reservations about needing to have Subversion > installed.) > >> There's nothing that prevents an svn wrapper from presenting a >> ruby-like API. DL and SWIG only give different tradeoffs in how this >> is implemented. > > What potential trade-offs are there between DL and SWIG? I think I've illustrated the biggest ones already, with SWIG you can get exactly what you want, but it will take you more time and effort. With DL, you may run into some gotcha in the corner that DL doesn't handle well. DL will require less effort to keep up-to-date than SWIG will, the difference depends on how quickly the svn internals change. (It looks like the subversion people do the right thing here, 1.1.3 still seem to have the same library numbers as 1.0.0, so this probably won't be as big a deal.) >> While many of the svn commands can work directly with the repository >> without local storage, I don't know of any way to avoid writing to >> disk >> for those commands that require a local checkout. > > Oh yeah, that reminds me... Let's say you try to run the svn client > from a random directory that isn't a svn working directory. Since > we're trying to avoid writing to disk, this will probably effectively > be the case. Are there any parameters to the command line client to > tell it which repository it should be looking at? It looks like you > can specify the target but not the url? > > So how does TortoiseSVN do it with the repo-browser? What > capabilities do the client libraries expose that the command line > client does not? You'll have to consult with the subversion people more on this, but: $ svn help propset propset (pset, ps): Set PROPNAME to PROPVAL on files, dirs, or revisions. usage: 1. propset PROPNAME [PROPVAL | -F VALFILE] PATH... 2. propset PROPNAME --revprop -r REV [PROPVAL | -F VALFILE] [URL] 1. Creates a versioned, local propchange in working copy. 2. Creates an unversioned, remote propchange on repos revision. [...] I believe that, in general, svn commands that have a URL version require no local storage. >>> I've been trying to get the Ruby SWIG bindings to work, but I have >>> absolutely no idea how to get SWIG to do its thing. It just sits >>> there and complains about missing files. >> >> DL or an svn wrapper will probably get you farther faster than SWIG, >> since both have a lower barrier to entry. For an svn wrapper you just >> need svn installed. For DL you need to be able to find an svn .dll or >> .so, which may be as simple as installing svn. > > But judging from the contents of my svn directory, maybe not: > > Volume in drive D is PRIMARY > Volume Serial Number is 1CEC-3A16 > > Directory of D:\Program Files\Subversion\bin > > 01/26/2005 11:07 PM . > 01/26/2005 11:07 PM .. > 01/20/2005 06:25 AM 794,722 svn.exe > 01/20/2005 06:25 AM 311,392 svnadmin.exe > 01/20/2005 06:25 AM 286,814 svnlook.exe > 01/20/2005 06:25 AM 315,488 svnserve.exe > 01/20/2005 06:25 AM 663,652 svnversion.exe > 01/20/2005 06:25 AM 254,058 svndumpfilter.exe > 01/20/2005 06:25 AM 647,168 libdb42.dll > 01/20/2005 06:25 AM 127,057 libapr.dll > 01/20/2005 06:25 AM 168,026 libaprutil.dll > 01/20/2005 06:25 AM 36,956 libapriconv.dll > 05/04/2004 08:52 AM 61,519 intl.dll > 01/20/2005 06:25 AM 843,776 libeay32.dll > 01/20/2005 06:25 AM 159,744 ssleay32.dll > 03/31/2004 06:13 PM 61,440 SVNService.exe > 14 File(s) 4,731,812 bytes > > Maybe I'm missing something, but I'm not really seeing that supposed > svn library that I can stick into a DL here. I have these: libsvn_client-1.0.0.0.dylib@ libsvn_client-1.0.dylib* libsvn_client-1.dylib@ but judging from the size of svn.exe, libsvn_client (or whatever) might be compiled-in. You'd have to ask the subversion people on how to generate the dlls. >> Ruby SWIG wrappers for svn once existed, but bitrotted due to lack of >> maintenance... > > Well, if you take a look in the subversion subversion repository, > you'll see that they do exist and there's some nice unit tests and > everything for them. Kou has been working on them fairly recently I > think. But building for Windows isn't any easier, which, for the > moment, seems to be my main problem. Ah! If that's your main problem, then your options are significantly different than I had imagined. Unfortunately, I can't help much with the SWIG/windows stuff because I don't have a windows box. Another responder says the ruby svn bindings work quite well, if you can get all the prerequisites built. (Ugh.) >> Really, I think you should check out DL, you'll quickly cut your >> problems down to those of actually wrapping the svn dll/so rather than >> trying to figure out why SWIG can't find your apr or svn headers. > > I like the sound of DL, but... since there doesn't seem to be any .so > or .dll for the client, maybe it's not even possible? I don't mind > learning SWIG _too_ much, I still have some C knowledge buried in the > attic, and I can dig it out if I don't have any choice. > > So I guess my question now is, can the svn client modify the metadata > in place without writing to disk, or is a checkout necessary? Same > question for the stuff I'm able to do via the SWIG bindings or the > mythical DL? This is really the most important part to me I think. > > Since it appears that there's actually no svn client libraries > packaged with svn, (presumably because the functionality is entirely > within svn.exe?) then perhaps to use DL magic, I have to compile the > SWIG stuff and then stick _that_ in the DL? Can I get all of the > resultant DL's (since SWIG seems to generate multiple libraries?) to > package up nicely into one gem without much hassle? I'd go hop back on the subversion lists and see what they can tell you about repoless actions and building a dll for windows. > And is there any way to use the svn client to work directly with the > repository in the way I want? If not, how would you manage a > reasonably large multi-user system with lots of different things being > worked on, probably in some kind of temp directory? Because right now > I'm envisioning that kind of thing getting out of control really fast. > > And if it's not currently possible to edit metadata in place, would it > be unreasonable to make that a feature request for subversion? -- Eric Hodel - drbrain@segment7.net - http://segment7.net FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 --Apple-Mail-26--272273634 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iEYEARECAAYFAkJcAz8ACgkQMypVHHlsnwRwYgCfZksemPpOfIxQe52lXWb//FLw 2PAAnAqXeoh0tvqPdRdUsN/i5tIbBlqK =ambX -----END PGP SIGNATURE----- --Apple-Mail-26--272273634--