At idle, with no applications running, the commit charge is at a whopping 483 MB!! Obviously, the final release or even the beta releases will not consume this much of the system resources.
How is it obvious that the resource utilization will go down? When they add more bloat, the commit charge gets bigger. No surprise there.
A MUD is not a text adventure game. A MUD generally has a theme, but not any sort of consistent plot.
And having 35,000 rooms seems like a serious drawback, not a useful feature. I can't imagine that many of those rooms are well-developed. Good text adventure games typically have under 200 rooms or locations, but put a great deal of effort into designing them well.
'This brazen attempt by ICANN to assume 'regulatory power' over VeriSign's business is a serious abuse of ICANN's technical coordination function.'
But ensuring that the registry operator's systems conform with the official DNS specifications, including negative responses, is a perfectly legitimate technical coordination function.
Nothing in the DNS RFCs suggests that a compliant DNS server can return arbitrarily chosen answers in response to a DNS question regarding an unknown domain. In fact, doing so clearly violates RFC 1035 section 4.1.1, which specifies that the response code 3 ("name error", also known as NXDOMAIN) should be returned for that case.
How can Verisign personnel seriously claim that there is nothing wrong with SiteFinder?
In my opinion, Verisign already breached their contract to operate the registry when they instituted SiteFinder the first time, and ICANN and the Commerce Department should have started a process to award a new contract to a different registry operator. The wholesale fee of $6/domain/year that Verisign gets is ridiculously large to begin with, which makes it seem even more unprofessional that they deliberately sabotage the registry operation to try to make even more money.
They don't provide anything of value, but they make it look more cluttered. The genius of the current interface is its simplicity.
The geographic location stuff might be of marginal utility occasionally, but I'd just want an extra link to click on near the result if I wanted that info.
It's replying with them at the same time. That is willfull interference. Calling it some other name like "over-answering" doesn't magically make it different than interference.
It's cobbled together poorly and sometimes very basic functionality doesn't even work right.
[...]
And although you can purchase a license to see the source code for their OS, it's cost prohibitive for a lot of companies, and development is stunted until you have it.
I've worked for companies with vxWorks source licenses, and fully agree. Both companies had huge problems with the vxWorks networking, and one company ended up licensing a TCP/IP stack from a different vendor. Part of my job was gluing that stack to Wind River's device drivers.
For read-only views of a repository there are way more deployed WebDAV clients then subversion clients, like all modern Windows and Mac OSX boxes. In fact for trivial version control as well (like no comment, and each file change is a commit), not just read-only.
I could be wrong, but I was of the impression that to commit to a Subversion repository over HTTP, you need WebDAV and Delta-V. Very few WebDAV clients support Delta-V yet.
The Subversion book mentions that you need to set the umask, something that svnserve doesn't do automatically.
It makes sense for svnserve not to automatically set umask, because there are multiple ways that svnserve can be used, and multiple ways that the repository user(s) and groups might be set up, and a single umask value is not the right thing for every configuation.
In fact, on my Subversion server I run svnserve both from xinetd (for anonymous read-only access) and from sshd, and over multiple repositories with different security requirements, and there's no single umask value that is correct for everything just on my one server machine.
That said, it would certainly be nice if the Subversion documentation explained this better. I'm not very good at writing documentation, though, so I don't think I'm the right person to submit improvements to it.
On further reflection, I realized that I may be setting up the repository ownership slightly differently than mgm was describing, although I'd hardly call it "magic".
Rather than having a common subversion group owning all the repositories, I have a separate group per repository, and make the users members of the groups for which they should have write access.
Subversion over its native network protocol is substantially faster than over WebDAV, and puts less load on the server. It's also much easier to configure. I don't have anything against WebDAV, but I can't at the moment think of a single practical advantage of Subversion over WebDAV vs. Subversion using svnserve.
At the time I started using Subversion, there were some deadlock problems in mod_dav_svn, though I expect those have long since been resolved. I think the fundamental difficulty is that doing this through an Apache module is inherently more complicated, and thus somewhat more brittle.
I think you're confused at least a little bit: vn+ssh uses svnserve, but runs it as the user authenticated via ssh
I don't think I'm at all confused. That's exactly what I expect and want.
I use svn+ssh all the time, using ssh authentication. So all my users are disctinct Unix users. Thus I have multiple Unix users accessing the repository, sometimes simultaneously. Yet I've never had the problems the earlier poster was complaining about.
and also requires some other magic to work.
If setting a few file permissions appropriately is what passes for "magic" these days... All you have to do is set the setgid bit on the directories (chmod -R 2770 repository). How hard is that?
When a permission problem occurs, your repository often needs to be "recovered" in order to fix it. Subversion's "svnadmin recover" can be used in these (usually rare) cases.
If you set it up correctly, why would permission problems occur?
I fully understand that, and I still don't think it's all that important to me as a Subversion user. It's the effect, cheap tagging and branching, that is important to me, not the cause, cheap copying. The cheap tagging and branching could just as well be implemented by magic pixie dust, and as long as it worked well and reliably, that would suit me fine.
Just as I care that my car gets me where I want to go, not how the engine works. (Yes, I know some people care how the engine works, and I'm not trying to be critical of that.)
I meant "direct" as in "not over the network". You still run the Subversion client (or any other client linked to the Subversion libraries).
AFAIK, there's no easy way to actually mount a Subversion repository as a filesystem, other than perhaps using a WebDAV filesystem and the mod_dav_svn Apache module.
Berkely DB is a transactional database; it will not necessarily work properly if multiple processes are accessing it at the same time.
Berkeley DB works fine with multiple processes accessing the database at the same time. It has locks which are used for dealing with contention. Subversion uses the locks. I don't doubt that you had problems with Subversion, but I'm dubious of this explanation.
For more details, check out the subversion book, chapter 6.
The URL you gave did not work for me. But I've read chapter six in its entirety, and it certainly does not say that svn+ssh doesn't work for multiple concurrent access. In fact, chapter six section five explains exactly how to do it. There are minor concerns over permissions, but the database locking works just fine.
The solution is to drop svn+ssh, and run svnserve.
One of us is very confused, and I'm pretty sure it's not me. "svn+ssh" is exactly what is used to access svnserve through an ssh tunnel. I know, because that is the ONLY way to access Subversion on my server. I didn't install WebDAV/Delta-V, and ssh on my Subversion server does not allow logins for any purpose other than Subversion.
It's doesn't lose source... Not very often, at least...
A few years ago I worked for a company that switched (over my objections) from CVS to SourceSafe. I didn't realize how bad SourceSafe was until we started having trouble with it. Then I started reading the MS web pages about it. They bragged abou the fact that they had a tool to fix corrupted repositories. Then in the fine print they mentioned that sometimes that tool couldn't fix a corrupted repository in a single run, and you should run it again. What, the tool can't even figure out when it's done?
I've NEVER had a corrupted CVS repository.
The programmers that pushed for the switch to SourceSafe said that the reason they wanted it was that they didn't like the CVS command line interface. So I showed them three different GUI interfaces for CVS. That didn't convince them. I never was able to get a straight answer, but I've come to the conclusion that what they didn't like was the fact that there wasn't a single, *official* GUI for CVS. That's the typical "choice is bad" thinking I've come to expect from people who've drunk the Microsoft koolaid.
In CVS you could set the ownership of each project to a particular group to control commit access. Can you do something similar in SVN?
I'm not sure about doing it using the WebDAV/Delta-V access method, but you can do it using the subversion native network protocol tunnelled over SSH.
I have my Subversion server configured with a "svn" user, and a group for every project. Each user belongs to the appropriate groups. The authorizedkeys files have the user keys and a command to automatically run svnserve.
The repository directories and files are owned by user "svn" and the appropriate group. The setgid bit on the directories are set so that when Berkeley db4 creates additional log files, they end up owned by the correct group.
Further, even if the Arch tools were to disappear tomorrow, I could still retrieve the contents of my files using tar, patch and similar tools -- something I can't do with a tool that backends into BerkeleyDB.
I was concerned about that when I started using Subversion. They supply a command, "svn dump", that outputs a flat text file version of a repository in an easily parsed format. I have a cron job to do this periodically for backup. If a was more paranoid, I'd set it up to do it after every commit.
However, I've been using Subversion for quite a while, and it has never yet lost any of my data.
but I don't trust my source to big binary blobs managed by the same library that's destroyed my RPM database so many times).
I have had occasional RPM database problems, but as far as I can tell they have been due to RPM problems, not due to Berkeley DB problems. In my experience Berkeley DB is fairly robust.
In principle, there is no reason why Subversion can't use your favorite relational database as the back end. The Subversion developers chose Berkeley DB as the first back end implementation, but there may be others in the future.
arguably superior core design
That's rather vague. What's better about Arch's core design? (I'm not trying to knock Arch; I just don't know much about it.)
...and if memory serves me correctly, does O(1) branching and tagging.
I don't think that's very exciting.
It's very exciting when you've been stuck with CVS for a large repository, where branching and tagging take a long time.
It's more exciting that it does O(1) copying, including O(1) copying of entire trees. They build branching and tagging on top of that functionality, which is the clever part.
That's not more exciting to me. I branch and tag frequently, so I care how long those operations take. I only very rarely do a copy for some reason other than a branch or tag. Therefore, I would have been satisfied if branching and tagging were implemented in some mysterious O(1) manner other than copying, and copying took O(n) or even O(n*log(n)).
The fact that Subversion does O(1) copying is a nice bonus, but its main benefit is that it makes the O(1) branching and tagging possible.
Slashdot Mirror
Paying royalties to Microsoft for VC-9 won't bother the vendors much unless the royalty amount is substantially higher.
And having 35,000 rooms seems like a serious drawback, not a useful feature. I can't imagine that many of those rooms are well-developed. Good text adventure games typically have under 200 rooms or locations, but put a great deal of effort into designing them well.
Nothing in the DNS RFCs suggests that a compliant DNS server can return arbitrarily chosen answers in response to a DNS question regarding an unknown domain. In fact, doing so clearly violates RFC 1035 section 4.1.1, which specifies that the response code 3 ("name error", also known as NXDOMAIN) should be returned for that case.
How can Verisign personnel seriously claim that there is nothing wrong with SiteFinder?
In my opinion, Verisign already breached their contract to operate the registry when they instituted SiteFinder the first time, and ICANN and the Commerce Department should have started a process to award a new contract to a different registry operator. The wholesale fee of $6/domain/year that Verisign gets is ridiculously large to begin with, which makes it seem even more unprofessional that they deliberately sabotage the registry operation to try to make even more money.
The geographic location stuff might be of marginal utility occasionally, but I'd just want an extra link to click on near the result if I wanted that info.
It's replying with them at the same time. That is willfull interference. Calling it some other name like "over-answering" doesn't magically make it different than interference.
FCC regulations prohibit deliberately interfering with radio communication. 47 CFR 15.5(b)
What happened to BSD? It wasn't that long ago that Wind River announced that BSD was the wave of the future.
In fact, on my Subversion server I run svnserve both from xinetd (for anonymous read-only access) and from sshd, and over multiple repositories with different security requirements, and there's no single umask value that is correct for everything just on my one server machine.
That said, it would certainly be nice if the Subversion documentation explained this better. I'm not very good at writing documentation, though, so I don't think I'm the right person to submit improvements to it.
Rather than having a common subversion group owning all the repositories, I have a separate group per repository, and make the users members of the groups for which they should have write access.
At the time I started using Subversion, there were some deadlock problems in mod_dav_svn, though I expect those have long since been resolved. I think the fundamental difficulty is that doing this through an Apache module is inherently more complicated, and thus somewhat more brittle.
I use svn+ssh all the time, using ssh authentication. So all my users are disctinct Unix users. Thus I have multiple Unix users accessing the repository, sometimes simultaneously. Yet I've never had the problems the earlier poster was complaining about.
If setting a few file permissions appropriately is what passes for "magic" these days... All you have to do is set the setgid bit on the directories (chmod -R 2770 repository). How hard is that? If you set it up correctly, why would permission problems occur?Just as I care that my car gets me where I want to go, not how the engine works. (Yes, I know some people care how the engine works, and I'm not trying to be critical of that.)
AFAIK, there's no easy way to actually mount a Subversion repository as a filesystem, other than perhaps using a WebDAV filesystem and the mod_dav_svn Apache module.
I recommend using svnserve (Subversion's native network protocol) over ssh, rather than the WebDAV/Delta-V/Apache module approach.
I've NEVER had a corrupted CVS repository.
The programmers that pushed for the switch to SourceSafe said that the reason they wanted it was that they didn't like the CVS command line interface. So I showed them three different GUI interfaces for CVS. That didn't convince them. I never was able to get a straight answer, but I've come to the conclusion that what they didn't like was the fact that there wasn't a single, *official* GUI for CVS. That's the typical "choice is bad" thinking I've come to expect from people who've drunk the Microsoft koolaid.
I have my Subversion server configured with a "svn" user, and a group for every project. Each user belongs to the appropriate groups. The authorizedkeys files have the user keys and a command to automatically run svnserve.
The repository directories and files are owned by user "svn" and the appropriate group. The setgid bit on the directories are set so that when Berkeley db4 creates additional log files, they end up owned by the correct group.
However, I've been using Subversion for quite a while, and it has never yet lost any of my data.
I have had occasional RPM database problems, but as far as I can tell they have been due to RPM problems, not due to Berkeley DB problems. In my experience Berkeley DB is fairly robust.In principle, there is no reason why Subversion can't use your favorite relational database as the back end. The Subversion developers chose Berkeley DB as the first back end implementation, but there may be others in the future.
That's rather vague. What's better about Arch's core design? (I'm not trying to knock Arch; I just don't know much about it.)The fact that Subversion does O(1) copying is a nice bonus, but its main benefit is that it makes the O(1) branching and tagging possible.