26 Sep, 2009, Xiuh wrote in the 1st comment:
Votes: 0
A few years ago I moved my code base from a mangled and broken CVS setup into a subversion repository. After a disappointing run with the GNU Autotools, I've decided to focus more on my SVN setup by embedding it into my code. My code currently builds up static libraries and links them into an executable with a wrapper script (This was probably done for the CVS setup). Thus, code my resembles an FSFS setup, but my repository is using the Berkeley DB. Obviously, I've got to make some decisions here before I can do an embed SVN into my code. Using FSFS for a Subversion repository isn't near as common as using the Berkeley DB and in fact, appears to of had limited support up until version 1.5. So….anyone here that uses Subversion setup, using FSFS and if so, are you miserable or happy with the results?

If you h ave no idea what I'm talking about but using SVN and interested…

SVN datastore
Embedding SVN
26 Sep, 2009, David Haley wrote in the 2nd comment:
Votes: 0
When you say "your code", do you mean the actual source code and running program, or the whole build process? I've never heard of somebody embedding SVN into the program itself, as opposed to using it to manage source control.

I believe that at work, we use an FSFS backend, and it hasn't given us any grief.
26 Sep, 2009, Xiuh wrote in the 3rd comment:
Votes: 0
Sorry, to clarify, I meant the "whole build process". As mentioned, some of this was left over from the CVS. When I was setting up my development platform I was extremely interested in the GNU Autotools and focused on this as opposed to the SVN building my environment (That being setup for test versions, archiving, backups, logs, compiling my code, etc). I just wasn't happy with the Autotools set and although I'm sure I'll use some pieces of it, I was just focusing on the Autotools, while completely ignoring my repository setup.
26 Sep, 2009, Xiuh wrote in the 4th comment:
Votes: 0
Scratch the topic. I just converted into the fsfs system with no problems what so ever. Thought it was going to be nasty.
27 Sep, 2009, David Haley wrote in the 5th comment:
Votes: 0
Glad that things worked out well, then. :smile:

I find Autotools very arcane, to be honest. The output of a correctly configured system is pretty nice, but setting up that system in the first place seems somewhat complex…
27 Sep, 2009, Xiuh wrote in the 6th comment:
Votes: 0
David Haley said:
Glad that things worked out well, then. :smile:

I find Autotools very arcane, to be honest. The output of a correctly configured system is pretty nice, but setting up that system in the first place seems somewhat complex…


David, I totally agree with you. Although, some of the things Autotools sets up is quite amazing, as a whole, it's missing a few pieces of the puzzle. Perhaps if I was actually making a distribution it might be worth the time. On the other hand, if I was making a distribution I'd consider some other tool sets, which Autotools doesn't seem to stack so well against.
27 Sep, 2009, flumpy wrote in the 7th comment:
Votes: 0
This brings up an interesting topic tho… something I've been thinking about. Do muds out there actually integrate SVN and the likes as commands in the mud? If so, how is it done in the various libraries if at all?

I'm askin, cause I might add it as a plugin or sommit to groovymud one day if people think it would be useful..
27 Sep, 2009, Xiuh wrote in the 8th comment:
Votes: 0
flumpy said:
This brings up an interesting topic tho… something I've been thinking about. Do muds out there actually integrate SVN and the likes as commands in the mud? If so, how is it done in the various libraries if at all?


I'm sorry, but I think I might have had a bit to much coffee last night and overstepped the scope of what I wanted to accomplish. However, if the time was deemed appropriate for such a projects, SVN provides you with libraries for the different connection layers into the repository. So possible? I'd say definitely. Something that I could personally accomplish before burning out….I doubt it :P However, adding a commit command would certainly be cool!
27 Sep, 2009, bbailey wrote in the 9th comment:
Votes: 0
flumpy said:
This brings up an interesting topic tho… something I've been thinking about. Do muds out there actually integrate SVN and the likes as commands in the mud? If so, how is it done in the various libraries if at all?

I'm askin, cause I might add it as a plugin or sommit to groovymud one day if people think it would be useful..


A few I know of do integrate revision control into the in-game tools. Discworld is one such example, iirc. I believe that the integration isn't done through libraries in their case, but through external calls to the rcs/cvs commands directly (or equivalents implemented in LPC).

I'd be very interested in having more complete integration for a mud engine which relied heavily on scripting for its game logic so that individual builders/coders/scripters/whatever could manage changes as they develop their domains. One of the drawbacks from Discworld's implementation is that there didn't seem to be any real user authentication or access control so everything wound up being checked in under one master account (the shell it ran on). Additionally, relying solely on the mud engine's access controls meant that having write-access in-game meant having commit access to the repository. While usually that will wind up being the case anyway, it isn't always so.
27 Sep, 2009, elanthis wrote in the 10th comment:
Votes: 0
In response to autotools, check out Scons. It took me a little getting used to but I'm fairly happy with it now. There's a few things that are too hard to do it in, but there are far more things that are too hard to in autotools. :)

In response to embedding revision control into a MUD, I would suggest looking into git. Subversion has quite a few major design disadvantages, not least of which is the horrific method it uses for branching (which in fact made it literally unusable for a number of our projects I've been on) and the fact that it requires server access (not a huge deal if you're hosting the repo locally). There is an experimental libgit project that makes integrating basic git control into a C/C++ application quite easy, which would be ideal if all you want to do is use it for managing MUD data files. git is also waaaay faster than SVN, even when hosted locally.
28 Sep, 2009, Xiuh wrote in the 11th comment:
Votes: 0
Scons….I'll look it over, thanks for the suggestion.
0.0/11