Accessing SVN through Ruby
Bob Aman
backend. However, the only simple interface to Subversion I seem to
have available to me is to call out to the Subversion command line
client, which is rather less than optimal. I saw the Subversion SWIG
bindings in the Subversion repository at
http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/ruby/
but when I tried to work with them, I couldn't figure out how to set
them up properly.
I kept getting "No such file to load -- svn/ext/core (LoadError)" when
trying to run run-test.rb
Has anyone out there had better luck with the ruby svn bindings or
does anyone know of a nicer ruby interface to SVN, preferably one
that's more "ruby-like"? There also seems to be disclaimers about the
functionality of the ruby bindings in the Subversion documentation,
but not a lot of information about what doesn't quite work. Just that
there might be some stuff. Anyone know what's missing or not working?
--
Bob Aman
Tanner Burson
> does anyone know of a nicer ruby interface to SVN, preferably one
> that's more "ruby-like"? There also seems to be disclaimers about the
> functionality of the ruby bindings in the Subversion documentation,
> but not a lot of information about what doesn't quite work. Just that
> there might be some stuff. Anyone know what's missing or not working?
I also would be interested. I was looking for this very thing not a
week ago, and wasn't able to find anything substantial.
Bob Aman
Ok, so I guess I should create something then. I'd just assume wrap
the ruby SWIG bindings with something more elegant, but I'm still
having trouble getting them to run as expected. I'm not sure how to
get the external parts of the bindings to work. The thing errors out
looking for the svn/ext/core stuff (mainly because it's not there).
But I can't figure out where it is or how to create it. From little
snippets in the changelists, it seems like the ext directory should
have the .so files (or probably .dll files in Windows) but those
aren't in the Subversion respository and it's not really obvious how
to build them. If anyone could give me pointers for how to get
started, that would be much appreciated. I'm doing the development on
both FreeBSD and Windows, so explanations for both environments would
be really helpful.
--
Bob Aman
Dick Davies
> > > Has anyone out there had better luck with the ruby svn bindings or
> > > does anyone know of a nicer ruby interface to SVN, preferably one
> > > that's more "ruby-like"? There also seems to be disclaimers about the
> > > functionality of the ruby bindings in the Subversion documentation,
> > > but not a lot of information about what doesn't quite work. Just that
> > > there might be some stuff. Anyone know what's missing or not working?
> >
> > I also would be interested. I was looking for this very thing not a
> > week ago, and wasn't able to find anything substantial.
>
> Ok, so I guess I should create something then. I'd just assume wrap
Isn't there a bounty for this?
--
'Everybody I know who is right always agrees with ME.'
-- Rev Lady Mal
Rasputin :: Jack of All Trades - Master of Nuns
Bob Aman
Bounty?
--
Bob Aman
Dick Davies
> > Isn't there a bounty for this?
>
> Bounty?
As in Jango Fett - not the chocolate bar.
On closer reading, that's not quite it, but see:
http://www.chadfowler.com/index.cgi/Computing/Programming/Ruby/FreeMoney.rdoc,v
--
'This must be Thursday. I never could get the hang of Thursdays.'
-- Arthur
Kouhei Sutou
In <599af4e205040...@mail.gmail.com>
"Accessing SVN through Ruby" on Fri, 8 Apr 2005 01:00:27 +0900,
Bob Aman <vaci...@gmail.com> wrote:
> I saw the Subversion SWIG
> bindings in the Subversion repository at
> http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/ruby/
> but when I tried to work with them, I couldn't figure out how to set
> them up properly.
Try the following sequence:
% svn co http://svn.collab.net/repos/svn/trunk svn
% cd svn
% ./autogen.sh
# or
# % env AUTOCONF=autoconf259 \
# AUTOHEADER=autoheader259 \
# LIBTOOL_M4=/usr/local/share/aclocal/libtool15.m4 \
# ./autogen.sh
# (If you are working on FreeBSD.)
% ./configure
# or
# % ./configure \
# --with-apr=/usr/local/lib/apache2 \
# --with-apr-util=/usr/local/lib/apache2
# (If you are working on FreeBSD.)
% make check-swig-rb
% sudo make install-swig-rb # if you pass all test.
--
kou
Bob Aman
>
> % svn co http://svn.collab.net/repos/svn/trunk svn
> % cd svn
> % ./autogen.sh
> # or
> # % env AUTOCONF=autoconf259 \
> # AUTOHEADER=autoheader259 \
> # LIBTOOL_M4=/usr/local/share/aclocal/libtool15.m4 \
> # ./autogen.sh
> # (If you are working on FreeBSD.)
> % ./configure
> # or
> # % ./configure \
> # --with-apr=/usr/local/lib/apache2 \
> # --with-apr-util=/usr/local/lib/apache2
> # (If you are working on FreeBSD.)
> % make check-swig-rb
> % sudo make install-swig-rb # if you pass all test.
I'm on Windows at home, and I don't think TextDrive (only FreedBSD
machine I have access to) would be keen on me doing this. I don't
suppose I could get info on how to do this for Windows?
--
Bob Aman
Garrett Rooney
> I'm on Windows at home, and I don't think TextDrive (only FreedBSD
> machine I have access to) would be keen on me doing this. I don't
> suppose I could get info on how to do this for Windows?
I don't think anyone has done the leg work to make the ruby bindings for
svn work on windows yet.
-garrett
Kouhei Sutou
"Re: Accessing SVN through Ruby" on Sat, 9 Apr 2005 10:59:01 +0900,
I'm sorry for my poor English skill, but I can't understand
what you want to say.
Please try the sequence on Windows and show me the output of
it.
--
kou
Bob Aman
> it.
Heh, ok.
(I already had svn checked out, so I'm skipping that bit.)
"Windows cannot open this file: autogen.sh"
Windows doesn't do the whole scripting thing very well.
--
Bob Aman
Kouhei Sutou
"Re: Accessing SVN through Ruby" on Sat, 9 Apr 2005 11:21:55 +0900,
Bob Aman <vaci...@gmail.com> wrote:
> "Windows cannot open this file: autogen.sh"
> Windows doesn't do the whole scripting thing very well.
I don't have Windows box, so I can't help you about the
thing. But INSTALL file in Subversion repository may help
you:
> Contents:
>
> I. BUILD REQUIREMENTS
>
> II. INSTALLATION
> ...
> E. Building the Latest Source under Windows
--
kou
Lee Marlow
gabriele renzi
try installing a tiny unisih environment such as cygwin or msys/mingw ,
and use the shell that is coming with it to do this.
Bob Aman
> You might want to take a look at the rscm library on rubyforge: http://rubyforge.org/projects/rscm/
Saw it already, won't do what I need. I have to have access to the
metadata, and speed is going to be an issue, so going through the
command line client will be less than optimal.
On Apr 9, 2005 4:19 AM, gabriele renzi <surren...@remove-yahoo.it> wrote:
> try installing a tiny unisih environment such as cygwin or msys/mingw ,
> and use the shell that is coming with it to do this.
I have cygwin, but ideally, I'd like to make sure my code works everywhere.
On Apr 8, 2005 10:37 PM, Kouhei Sutou <k...@cozmixng.org> wrote:
> I don't have Windows box, so I can't help you about the
> thing. But INSTALL file in Subversion repository may help
> you:
I'll give it a whirl, see what happens.
--
Bob Aman
Bob Aman
> > I don't have Windows box, so I can't help you about the
> > thing. But INSTALL file in Subversion repository may help
> > you:
>
> I'll give it a whirl, see what happens.
From the INSTALL file:
E.1 Prerequisites
* Visual Studio 6 and service pack. It can be built with Visual Studio
7 (aka Visual Studio.NET aka Visual Studio.NET 2002) but these
instructions assumes VS6.
* A recent Windows SDK, the one provided with Visual Studio 6 is
too old. You only need the 'Core SDK'. You can get it from MSDN
if you have it or from
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ if you
don't.
* Python 2.2 or higher, downloaded from http://www.python.org/ which is
used to generate the project files.
* Perl 5.8 or higher from http://www.activestate.com/
* Awk, from http://cm.bell-labs.com/cm/cs/who/bwk/awk95.exe
This is needed to compile Apache or APR. Note that this is the
actual awk program, not an installer - just rename it to awk.exe
and it is ready to use.
* Neon 0.24.7 or higher, downloaded from
http://www.webdav.org/neon/neon-0.24.7.tar.gz which is required
for building the client components. Neon is included in the zip file
distribution.
* Berkeley DB is required for support for local server components,
version 4.2.52 is available from
http://subversion.tigris.org/servlets/ProjectDocumentList as
db-4.2.52-win32.zip. For more information see Section I.5.
* Apache 2 source, downloaded from
http://httpd.apache.org/download.cgi, these instructions assume
version 2.0.50. Only needed for building the server dso modules.
* Apache 2 msi install file, also from
http://httpd.apache.org/download.cgi (required for running the
tests). Only needed for testing the server dso modules.
* Apache apr, apr-util, and apr-iconv libraries, version 0.9.5.
Included in both the Subversion ZIP file and the Apache 2 source
tarball. If you are building from a Subversion checkout and have
not downloaded Apache 2, then get these 3 libraries from
http://www.apache.org/dist/apr/
* ZLib 1.1.4 or higher (version 1.1.x) binaries
http://www.winimage.com/zLibDll/zlib114dll.zip.
* Openssl 0.9.7d or higher obtained from
http://www.openssl.org/source/openssl-0.9.7d.tar.gz
* An assembler, e.g., nasm which is available from
http://www.kernel.org/pub/software/devel/nasm/binaries/win32/
* For localization gnu gettext is needed. Get
gettext-runtime-0.13.bin.woe32.zip,
gettext-tools-0.13.bin.woe32.zip, and
libiconv-1.9.1.bin.woe32.zip from
http://mirrors.kernel.org/gnu/gettext/ and
http://mirrors.kernel.org/gnu/libiconv/.
* Either a Subversion client binary from http://subversion.tigris.org/ to
do the initial checkout of the Subversion source or the zip file
source distribution. See the section "Bootstrapping from a Zip or
Installer File under Windows" above for more.
* A means of unpacking the files. The Subversion tar.gz file uses the
POSIX.1 standard for file names which exceed 100 characters. This
format is not understood by all programs which claim to be able to
unpack .tar.gz files. Notable examples of this are WinZip and the
utilities which can be found at http://unxutils.sourceforge.net/. The
version of tar at http://gnuwin32.sourceforge.net/ is derived from GNU
tar, so it can handle POSIX.1. However, it is *not* able to unpack
gzip files, although it is able to read a pipe from gzip. Cygwin can
unpack this file, however cygwin is a large package to install such
just to unpack the tarball on Windows. To avoid these problems use
the Subversion zip file source distribution. The other required
package which is packaged as a tar file (openssl) can be unpacked with
any of the utilities mentioned.
Please tell me that I don't need to do all of that just to generate
the SWIG bindings for Windows... (mumble, grumble, why can't this be
automated more easily?)
I was looking through the pickaxe book and I saw that rubygems seems
to make allowance for precompiled gems... Can I make use of this?
Ultimately, what I'd like to create is a simple ruby-svn gem that can
be installed anywhere with zero hassle. If it's possible, I'd like to
just include the external libraries for svn for each of the possible
platforms inside the gem or something like that. I don't want to rely
on the library's user actually having all of the required build tools
(especially for the windows platform). Is this possible? If so, how
hard is it, and what do I have to watch out for as far as pitfalls?
I'd prefer not to have to make seperate gems for each platform, is
that possible, given what I want to do?
For that matter, how hard would it be to make a pure-ruby svn client
that conversed with svn only via http/apache? How bad of an idea is
this?
Be aware, I've never tried to make a gem before. (Heck, I'm only just
getting started with ruby, so...)
--
Bob Aman
Eric Hodel
>> On Apr 8, 2005 10:37 PM, Kouhei Sutou <k...@cozmixng.org> wrote:
>>> I don't have Windows box, so I can't help you about the
>>> thing. But INSTALL file in Subversion repository may help
>>> you:
>>
>> I'll give it a whirl, see what happens.
>
>> From the INSTALL file:
>
> Please tell me that I don't need to do all of that just to generate
> the SWIG bindings for Windows... (mumble, grumble, why can't this be
> automated more easily?)
>
> I was looking through the pickaxe book and I saw that rubygems seems
> to make allowance for precompiled gems... Can I make use of this?
>
> Ultimately, what I'd like to create is a simple ruby-svn gem that can
> be installed anywhere with zero hassle. If it's possible, I'd like to
> just include the external libraries for svn for each of the possible
> platforms inside the gem or something like that. I don't want to rely
> on the library's user actually having all of the required build tools
> (especially for the windows platform). Is this possible? If so, how
> hard is it, and what do I have to watch out for as far as pitfalls?
> I'd prefer not to have to make seperate gems for each platform, is
> that possible, given what I want to do?
Is DL unsuitable for this? That would require only a compiled SVN
library.
> For that matter, how hard would it be to make a pure-ruby svn client
> that conversed with svn only via http/apache? How bad of an idea is
> this?
You'd then have to track any changes to the svn protocol, which is
unlikely to be fun/easy.
svn lists easily parseable output as one of its features...
> Be aware, I've never tried to make a gem before. (Heck, I'm only just
> getting started with ruby, so...)
That's the easy part
--
Eric Hodel - drb...@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
Bob Aman
this message is probably better answered by them. Apologies to the
respective mailing lists for the parts that are off topic.)
> Is DL unsuitable for this? That would require only a compiled SVN
> library.
DL?
> 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.
Ideally, I need a reliable interface to Subversion for Ruby. I want
to be able to easily wrap it with something more "ruby-like" than the
raw API. Ideally, I need to be able to "checkout" to memory - I
probably don't have the luxury of checking stuff out to disk. The
ultimate purpose is something almost like ViewSVN or WebSVN, except
that I need to, at the very least, be able to modify the metadata from
within the web app. And we're probably talking about around 50-100
concurrent users, not just one person at a time. It needs to be
cross-platform. 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.
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.
--
E:\Ruby Projects\Libraries\ruby-svn\swig>swig svn_client.i
apr.i(47): Error: Unable to find 'apr.h'
svn_types.i(527): Error: Unable to find 'svn_types.h'
svn_delta.i(91): Error: Unable to find 'svn_delta.h'
svn_wc.i(116): Error: Unable to find 'svn_wc.h'
svn_client.i(434): Error: Unable to find 'svn_client.h'
--
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.
But for me to actually do what I want, this thing needs to all get
packaged up in a gem. (http://docs.rubygems.org/read/book/1) Thus
far, I've gotten the impression that even if I were to get this whole
SWIG thing to work, the steps required to get there might be too
difficult for rubygems to handle compiling from source. Which seems
to leave me with precompiled gems? I don't know, I'm kinda fuzzy on
this.
I want this as the end result:
gem install ruby-svn
*poof, magic ensues*
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 want the only prerequisite to be ruby and
rubygems. That includes build tools. If the user lacks SWIG or vc++
or whatever, I don't want that to prevent the library from working. I
think that leaves me with binaries, but...
It looked like the fxruby library did some stuff with SWIG and managed
to pull it off fairly well, but I'm not sure I want users of the
library to be presented with a list of 10 possible versions for
different platforms when they type gem install ruby-svn like what
happens with fxruby. Especially when one of those platforms is
"ruby". Sooooo.... what happens with fxruby if I'm on Windows and I
select "ruby" as my platform instead of "win32"? "ruby" doesn't make
sense as an option, so ideally, I'd rather just have the end result
work everywhere instead of confusing the user with nonsensical choices
that I don't have much control over.
Also, I don't want to be dealing with bleeding edge stuff from
Subversion's svn repository. I have to make the corporate overlords
happy, and you all know how that goes.
So... is there any way for me to access the subversion client library
without doing any SWIG magic, or at the very least, doing the SWIG
magic ahead of time and then including any necessary binaries for the
various platforms within a single gem? And if I'm absolutely stuck
doing SWIG magic, can someone hold my hand and walk me through getting
that to work in Windows? I've been trying to do this for almost a
week now, and I'm really no further than when I first started.
--
Bob Aman
Saynatkari
Le 12/4/2005, "Bob Aman" <vaci...@gmail.com> a écrit:
>> On Apr 8, 2005 10:37 PM, Kouhei Sutou <k...@cozmixng.org> wrote:
>> > I don't have Windows box, so I can't help you about the
>> > thing. But INSTALL file in Subversion repository may help
>> > you:
>>
>> I'll give it a whirl, see what happens.
>
>From the INSTALL file:
>
> E.1 Prerequisites
>
>
>Please tell me that I don't need to do all of that just to generate
>the SWIG bindings for Windows... (mumble, grumble, why can't this be
>automated more easily?)
Hey, it is not that bad. See the snippet at the end that
I wrote for a 'native' extension. The code is not all that
great (I was mainly trying to get it to just work) but
that Apache Portable Runtime is some truly horrible stuff.
>I was looking through the pickaxe book and I saw that rubygems seems
>to make allowance for precompiled gems... Can I make use of this?
>
>Ultimately, what I'd like to create is a simple ruby-svn gem that can
>be installed anywhere with zero hassle. If it's possible, I'd like to
>just include the external libraries for svn for each of the possible
>platforms inside the gem or something like that. I don't want to rely
>on the library's user actually having all of the required build tools
>(especially for the windows platform). Is this possible? If so, how
>hard is it, and what do I have to watch out for as far as pitfalls?
>I'd prefer not to have to make seperate gems for each platform, is
>that possible, given what I want to do?
>
>For that matter, how hard would it be to make a pure-ruby svn client
>that conversed with svn only via http/apache? How bad of an idea is
>this?
>
>Be aware, I've never tried to make a gem before. (Heck, I'm only just
>getting started with ruby, so...)
Someone is already working on a SVN extension to go with the RSCM
project... I would suggest taking a look if you can help there
instead?
>--
>Bob Aman
E
//////////////////////
// rsvn.c
//-- rsvn_client_ls / Method --//
/* -- Lists the contents of a repo directory.
*/
VALUE rsvn_client_ls(VALUE self,
VALUE path_or_url,
VALUE revision,
VALUE recurse)
{
rsvn_client_rep* clt; // The raw client info
const char* encoded_uri; // URI-encoded path/URL
svn_opt_revision_t revision_data; // SVN revision information
apr_pool_t* pool; // Memory pool for this operation
apr_pool_t* subpool; // Temporary pool for looping
apr_hash_t* directory; // Hash for the file/dir names
apr_hash_index_t* element; // A single element in the directory
has
const void* filename; // Hashed file/directory name
void* file_entry; // File information
svn_error_t* error; // Any received errors
VALUE directory; // The directory structure
// Initializations
// Get the raw data for the client
Data_Get_Struct(self, rsvn_client_rep, clt);
// Extract the revision information from the Ruby object
_rsvn_revision_get_svn_revision(revision, &revision_data);
// Subpool for safe looping
pool = svn_pool_create(clt->memory_pool);
subpool = svn_pool_create(pool);
// Generate an encoded URI (spaces replaced etc.)
// TODO: Can't seem to be able to access local reps on a Windows
// machine.
encoded_uri = svn_path_uri_encode(STR2CSTR(path_or_url), pool);
// Implementation
// Propagate to SVN
error = svn_client_ls(&directory, // Directory entries
encoded_uri, // Path to list
&revision_data, // Revision to retrieve
0, // Recursion
clt->context, // Context
pool);
if (error != 0)
{
// Throw an error <fix>Only prints the topmost error</fix>
rb_raise(rsvn_eSVNError,
"Ruby-SVN::rsvn_new_client (%s:%d): %s\n", error->file,
error->line,
error->message);
}
// Sort the retrieved file names
// TODO: Remove completely?
//files = svn_sort__hash(directory_hash,
svn_sort_compare_items_as_paths,
pool);
// Create a directory to fill
directory = rb_class_new_instance(0, 0, rsvn_cDirectory);
// Fill it
for (element = apr_hash_first(pool, directory);
element != 0; element = apr_hash_next(element))
{
// Extract the key (filename) and value (file info)
// from the hash, ignore key length
apr_hash_this(element, &filename, 0, &file_entry);
// Add the file to the directory
_rsvn_directory_add(directory, filename, file_entry);
}
// Release both pools
svn_pool_destroy(pool);
// The user will receive the directory
return directory;
}
// ...
//-- _rsvn_client_on_username_prompt / Callback --//
/* -- Invoked if the authenticator needs to get
the username interactively.
*/
svn_error_t*
_rsvn_client_on_username_prompt(svn_auth_cred_username_t** credentials,
void* client,
const char* realm_string,
svn_boolean_t may_save,
apr_pool_t * pool)
{
VALUE self; // Calling Client object
VALUE listener; // Event listener for this Client
VALUE retval; // The retrieved values in a hash
svn_auth_cred_username_t* cred = 0; // Collected credential data
// Extract the variables, propagate error out if there's a problem
SVN_TRY(_rsvn_client_get_listener(client, &self, &listener),
"Ruby-SVN::rsvn_client_on_username_prompt: ");
// Query the Listener for a username (may_save should be 0 or 1)
retval = rb_funcall(listener,
ID_PROMPT_USERNAME,
2,
rb_str_new2(realm_string),
INT2FIX(may_save));
// Verify the query succeeded
if (retval == Qnil)
{
// Error and cancel
return svn_error_createf(SVN_ERR_CANCELLED,
0,
"Ruby-SVN::rsvn_client_on_username_prompt: No username from
Listener.");
}
cred = apr_palloc(pool, sizeof(svn_auth_cred_username_t));
// Collect the data <todo>UTF conversion unnecessary?</todo>
SVN_TRY(svn_utf_cstring_to_utf8(&cred->username,
STR2CSTR(rb_funcall(retval,
ID_GET_INDEX,
1,
rb_str_new2("username"))),
pool),
"Ruby-SVN::rsvn_client_on_username_prompt: ");
cred->may_save = FIX2INT(rb_funcall(retval,
ID_GET_INDEX,
1,
rb_str_new2("cache")));
// No errors, we're done
*credentials = cred;
return SVN_NO_ERROR;
}
// End
--
No-one expects the Solaris POSIX implementation!
Eric Hodel
> (Cross-posting to d...@subversion.tigris.org since at least part of
> this message is probably better answered by them. Apologies to the
> respective mailing lists for the parts that are off topic.)
>
>> Is DL unsuitable for this? That would require only a compiled SVN
>> library.
>
> DL?
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?
> Ideally, I need a reliable interface to Subversion for Ruby.
If you build it to be reliable, it will be reliable. Unit tests come
in really handy for this.
> I want
> to be able to easily wrap it with something more "ruby-like" than the
> raw API.
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.
> Ideally, I need to be able to "checkout" to memory - I
> probably don't have the luxury of checking stuff out to disk.
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.
> The
> ultimate purpose is something almost like ViewSVN or WebSVN, except
> that I need to, at the very least, be able to modify the metadata from
> within the web app. And we're probably talking about around 50-100
> concurrent users, not just one person at a time.
FreeBSD's CVSweb shells out for all of its commands, and likely handles
50-100 concurrent users just fine (probably more, in fact).
> It needs to be cross-platform.
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).
> 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).
> 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. 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.
> --
> E:\Ruby Projects\Libraries\ruby-svn\swig>swig svn_client.i
> apr.i(47): Error: Unable to find 'apr.h'
> svn_types.i(527): Error: Unable to find 'svn_types.h'
> svn_delta.i(91): Error: Unable to find 'svn_delta.h'
> svn_wc.i(116): Error: Unable to find 'svn_wc.h'
> svn_client.i(434): Error: Unable to find 'svn_client.h'
> --
>
> 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.
> But for me to actually do what I want, this thing needs to all get
> packaged up in a gem. (http://docs.rubygems.org/read/book/1) Thus
> far, I've gotten the impression that even if I were to get this whole
> SWIG thing to work, the steps required to get there might be too
> difficult for rubygems to handle compiling from source. Which seems
> to leave me with precompiled gems? I don't know, I'm kinda fuzzy on
> this.
I believe gems work can ship both precompiled libraries or build their
own. I seem to recall that gems have setup.rb on the inside (or
something like it).
> I want this as the end result:
> gem install ruby-svn
> *poof, magic ensues*
An svn wrapper or DL are going to get you something that works fastest
and require the fewest incantations before the magic ensues.
> 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.
> I want the only prerequisite to be ruby and
> rubygems. That includes build tools. If the user lacks SWIG or vc++
> or whatever, I don't want that to prevent the library from working. I
> think that leaves me with binaries, but...
Remember that you'll have to do the work of making this cross-platform,
which means keeping all the necessary packages up to date. That sounds
like a lot of work.
> 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.
> but I'm not sure I want users of the
> library to be presented with a list of 10 possible versions for
> different platforms when they type gem install ruby-svn like what
> happens with fxruby. Especially when one of those platforms is
> "ruby". Sooooo.... what happens with fxruby if I'm on Windows and I
> select "ruby" as my platform instead of "win32"? "ruby" doesn't make
> sense as an option, so ideally, I'd rather just have the end result
> work everywhere instead of confusing the user with nonsensical choices
> that I don't have much control over.
> Also, I don't want to be dealing with bleeding edge stuff from
> Subversion's svn repository. I have to make the corporate overlords
> happy, and you all know how that goes.
>
> So... is there any way for me to access the subversion client library
> without doing any SWIG magic, or at the very least, doing the SWIG
> magic ahead of time and then including any necessary binaries for the
> various platforms within a single gem? And if I'm absolutely stuck
> doing SWIG magic, can someone hold my hand and walk me through getting
> that to work in Windows? I've been trying to do this for almost a
> week now, and I'm really no further than when I first started.
Ruby SWIG wrappers for svn once existed, but bitrotted due to lack of
maintenance...
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.
Bob Aman
> Hey, it is not that bad. See the snippet at the end that
> I wrote for a 'native' extension. The code is not all that
> great (I was mainly trying to get it to just work) but
> that Apache Portable Runtime is some truly horrible stuff.
Yes, it is, and this is one of the main reasons I want something more
"ruby-like" than the straight up Ruby SWIG bindings. "Er, pools? Why
should I have to think about pools? This is Ruby, for goodness
sakes!" The thing is ugly, even by C standards.
> Someone is already working on a SVN extension to go with the RSCM
> project... I would suggest taking a look if you can help there
> instead?
Yes, but it seems that they're creating a wrapper for the svn client,
not using the client libraries directly. So they can get no more
functionality than the client itself offers. Which is quite possibly
(or probably, even) not going to be enough to meet my needs.
--
Bob Aman
Bob Aman
>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
Steven Jenkins
> On Apr 11, 2005 11:33 PM, Saynatkari <rub...@magical-cat.org> wrote:
>
>>Hey, it is not that bad. See the snippet at the end that
>>I wrote for a 'native' extension. The code is not all that
>>great (I was mainly trying to get it to just work) but
>>that Apache Portable Runtime is some truly horrible stuff.
>
>
> Yes, it is, and this is one of the main reasons I want something more
> "ruby-like" than the straight up Ruby SWIG bindings. "Er, pools? Why
> should I have to think about pools? This is Ruby, for goodness
> sakes!" The thing is ugly, even by C standards.
I've wrapped two libraries with SWIG. In both cases, I ended up writing
a layer of syntax sugar in Ruby, purely to make the API more Ruby-like.
One of those efforts is described here:
It's possible to do some of this in SWIG itself, but Ruby is easier, at
least for me.
Steve
Steven Jenkins
> [snip]
>
> It's possible to do some of this in SWIG itself, but Ruby is easier, at
> least for me.
Which is a good time for me to ask Lyle Johnson in public: Are you
coming to RubyConf? Can I solicit a tutorial on intermediate to advanced
SWIG and Ruby? (No pressure :-)).
I've successfully wrestled SWIG (C only, no C++) to the ground twice,
but I have the nagging feeling that it would be so much easier if I
understood certain things: language-indpendent rules, %rename,
exceptions, etc.
Steve
Eric Hodel
> 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 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?
--
Bob Aman
> On 04/12/05 11:49:17, Bob Aman wrote:
> > Ok, so I'm still trying to get SWIG to do its thing on Windows. And
> > I'm starting to get the impression that perhaps it's not necessary to
> > go through a full build. (At least, I certainly hope so.) Am I
> > correct in this assumption, and if so, what is the bare minimum
> > necessary to get SWIG to do its magic in Windows? I'm currently
> > working with the source for 1.1.4, not the latest code from the
> > repository.
>
> http://www.swig.org/Doc1.3/Windows.html
>
> I should also note here that as I have said before, the output files from
> SWIG are portable to almost any architecture and only need to be generated
> once. Thus, if you have SWIG installed say on linux, you can run it to
> generate the _wrap files and those exact wrap files can be used on Sun,
> Windows, Linux, MacOS, whatever. So you could even get someone to email
> you the files that SWIG creates, and you wouldn't even need SWIG installed
> to compile the bindings on windows.
>
> The right way to take care of this problem is to have the SWIG generated
> files present directly inside the released subversion tarballs, then SWIG
> does not need to be installed to build a tarball. Sadly, this feature will
> not even be in the 1.2 release, but hopefully future releases will have it.
>
> Note that all I've said is only true for SWIG since version 1.3.23... but
> subversion is using 1.3.24 so shouldn't matter.
>
> John
Well, I managed to get a little bit more progress by moving around a
bunch of the .h files. But apr.h seems to be missing. I saw apr.h.in
and that seems to be what I'm looking for. It says apr.h is a
generated file? How do I generate it? On a whim, I tried just
renaming apr.h.in to apr.h and got back an error from SWIG:
E:\svn-source\subversion-1.1.4\subversion\bindings\swig>swig -ruby apr.i
apr.h(257): Error: Syntax error in input.
*** No module name specified using %module or -module.
So I assume that was the wrong thing to do :-P
--
Bob Aman
Joshua J. Kugler
> 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.)
> 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 don't know how much reading of the svn manual you have done
<http://svnbook.red-bean.com/> because it explains very clearly how to
edit metadeta with the svn client and the svnadmin tools. It also
explains (IIRC) about the client libraries (but I could be wrong on
that). See <http://svnbook.red-bean.com/en/1.1/ch08.html>, especially
the section about "Using the API."
> 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.
You can specify where you check out, but checking out to memory might
require some interesting proramming. If it is via a web client,
though, checking out to memory wouldn't work as the memory would go
away when the script ended.
j----- k-----
--
Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295
Every knee shall bow, and every tongue confess, in heaven, on earth, and
under the earth, that Jesus Christ is LORD -- Count on it!
Bob Aman
> <http://svnbook.red-bean.com/> because it explains very clearly how to
> edit metadeta with the svn client and the svnadmin tools. It also
> explains (IIRC) about the client libraries (but I could be wrong on
> that). See <http://svnbook.red-bean.com/en/1.1/ch08.html>, especially
> the section about "Using the API."
I did read that section on using the API. It's not overwhelmingly
helpful unless you were writing everything in Python. I also know how
to edit metadata under normal circumstances. IE, when you have a
working copy checked out. That's a simple propset command. I need to
edit that metadata without having a working copy. I need to be
editing the metadata from within a multi-user web app, and writing
anything to disk would be a bad idea, especially if the sole purpose
of writing to disk was to make svn know which repository we're
interested in. Compounded on top of all that, a very likely
requirement will be having the same web app connect to more than one
repository.
> You can specify where you check out, but checking out to memory might
> require some interesting proramming. If it is via a web client,
> though, checking out to memory wouldn't work as the memory would go
> away when the script ended.
And why is that a problem? Any "checkouts to memory" would only be
occurring for the purposes of enabling in-place metadata changes. If
that's even required. See, the problem is that I'm writing a wrapper
of sorts around Subversion. For example, things like workflow states
will be saved in the svn metadata. I don't particularly want users
editing metadata manually, though I don't see any really, really big
problems with them being able to do it since the metadata is
versioned. Workflow states will probably have some sort of encrypted
authorization token that will be next to impossible for an end user to
fake, and if they change those, someone walks over to their cube and
tells them to cut it out and then restores the workflow state to what
it should be. Not a big deal. (Certainly better than the system that
currently exists. The app will just have to make allowance for
possibly erroneous data. No biggy, I would be remise in my coding
anyhow if I made the assumption that everything was clean.) But for
that to work, the program needs to be able to "promote" or "demote"
files from within the web interface. That's not something you want to
make people do via TortoiseSVN. Especially if you have complex
group/role logic going on to determine who can promote or demote what.
--
Bob Aman