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.)
> If you build it to be reliable, it will be reliable. Unit tests come
> in really handy for this.
Agreed, though you always have to consider the weakest link. It's bad
if the weakest link is something you can't control. That's kinda what
I meant.
> 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?
> 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?
> This is easiest if you just shell out, since it will be easier to
> maintain a svn wrapper than maintaining libraries for the platforms
> that don't typically ship with a compiler (windows).
Agreed, and it's really the only real attraction to me for wrapping
the command line client.
> > It needs to be somewhat easy, because I am not a C
> > hacker by any stretch of the imagination. And it's got to be
> > reasonably simple to set up on Windows, since, for the moment, that's
> > the dev environment I'm stuck with.
>
> Sounds like you'd rather to an svn wrapper or DL (in that order).
Yeah, I would agree, assuming that all of the functionality I need can
be had through the command line client.
> > 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 <DIR> .
01/26/2005 11:07 PM <DIR> ..
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.
> For SWIG you need
> headers and a compiler, which can be no fun if there's no default
> compiler and you have 2 or 3 different compilers to choose from.
> > Of course, it doesn't help that building svn on Windows seems to
> > require superhuman effort, though it's quite possible that I'm just
> > missing some build step somewhere.
>
> If you're having these difficulties, do you expect other people to find
> it easier? Do you feel you can maintain what you've done when you've
> completed your wrapper? These are important things to think about
> before you put your hands on the keyboard. I have failed before when
> trying to do something Too Big™ because I didn't think about how hard
> it would be to complete.
True, though if I can do it once, I can do it again. The question is
whether it's worth the effort if it's going to take 4 hours every time
there's a new release of Subversion. Beyond that, once I get the
thing started, if it seems to be going reasonably well, I won't be the
only person working on it.
But yeah, the possibility of Too Big™ thing is why I haven't started
writing any code quite yet. I like to know what I'm getting into.
> > And I want that magic to ensue regardless of what platform I'm running
> > on. If the user doesn't have subversion installed, I don't want that
> > to be a problem.
>
> I think that you'll be better off making this a requirement, I would
> hate to be stuck duplicating the three different svn access protocols
> (http/DAV, file, svn) or even one of them.
>
> The subversion people seem to have done a good job of getting
> no-brainer svn packages for all the major platforms.
This is true. Ok, so maybe having svn as a prereq isn't too much of a problem.
> > It looked like the fxruby library did some stuff with SWIG and managed
> > to pull it off fairly well,
>
> I believe that Lyle has a good deal of C mojo in his back pocket, which
> would make SWIG much easier for him.
Where's the C mojo when you need it? I think long ago I used to have
it... but thus far I've been happier not even thinking about C.
> 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.
> It sounds like you need to step back and re-evaluate all of the options
> available.
>
> SWIG seems to be more like a belt-fed, automatic, pneumatic nail gun,
> and less like a box of nails and a hammer. Just about anybody can use
> a hammer, but a belt-fed, automatic, pneumatic nail gun is going to
> take lots of practice to use correctly. Once you have it down though,
> you'll be able to pound out houses with ease. If you can invest the
> time and energy to build SWIG bindings for subversion, then you'll get
> a great tool.
>
> If you can't invest that time, I would instead go for DL, or a wrapper
> for svn.
>
> 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?
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?
--
Bob Aman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 15:34:13 2005