Subversion Hits Alpha 210
C. Michael Pilato writes: "This overheard while eavesdropping on announce@subversion.tigris.org: Gentle coders, The ever-growing cadre of Subversion developers is proud to announce the release of Subversion 'Alpha' (0.14.0). Since we became self-hosting eleven months ago, we've gone through ten milestones. This milestone, however, is the one we've always been working towards; it's a freeze on major features for our 1.0 release. From here out, it's mostly bug-fixing. We hope this announcement will lead to more widespread testing; we welcome people to try Subversion and report their experiences on our development list and issue tracker." Subversion, a source control system akin to CVS, has been in the works for a couple of years now.
Why? (Score:4, Funny)
Re:Why? (Score:2, Interesting)
Re:Why? (Score:1)
Yes. Insanely expensive. It is pretty good but not really close to being worth $500 per seat (when purchased separately from Visual Studio).
Re:Why? (Score:3)
Sourcesafe isn't that bad. (Score:3, Insightful)
You shouldn't use it for large projects. So when people still use it for large projects, it can be cumbersome and slow.
So your 'it's a total piece of shit' is way off base, or you're one of these people who cram 1.5 million lines projects in Sourcesafe and then start complaining.
Re:Why? (Score:2, Interesting)
When the license + 1 year support for each is all added up, we'll be cutting a check to the tune of about $16,000
I've asked the CM people before why we're not using something cheap (free) like CVS (as the sysadmin, I don't get to make the decisions, I just get to make it work once the stuff is purchased), and they casually said "Hell, I don't know, that's just what we're stuck with."
I guess "Hell, I don't know, that's just what we're stuck with" is an appropriate attitude when you've got oodles and oodles of taxpayer dollars to spend...
I know, I know. I'm going to hell.
Re:MOD PARENT DOWN: OVERRATED (Score:2)
Besides, so many people post at +2 now, you almost have to hope to be heard above the noise. I browse at 3 most of the time, I'm sure many other people do too.
Re:MOD PARENT DOWN: OVERRATED (Score:2)
Re:MOD PARENT DOWN: OVERRATED (Score:2)
Re:Why? (Score:1)
Good source control systems includes Bitkeeper and ClearCase. Neither of those are free/opensource.
Microsoft doesn't even use its own products ... (Score:2)
Here's a list ...
Re:Microsoft doesn't even use its own products ... (Score:4, Informative)
There are lots and lots of DNS/AD servers at MS, although not as many running W2k anymore (they're running W2k + 1 mostly)
And, unfortuneately, we have LOTS of boxes running ISA server. On numerous occasions i've emailed the relevant admins saying "please let me setup 1 squid box for you so i dont have to put up with this crap anymore". It's gotten better but man dogfooding is painful sometimes.
I can think of 1 team larger than 50 using VSS. There's an internal-only project spread over several teams that has been the same source base for 4+ years that is using VSS. There are easily over 50 people who've made checkins. Thats probably different than 50 active developers.
You're generally right though about VSS - it's not being used anymore internally for large projects. It's an adequate SCM for small projects or groups of small projects. The project I mentioned has about 5GB under VSS control and it works reasonably well, but I probably wouldn't start with VSS if i were starting from scratch.
Re:Why? (Score:2)
In 20 words or less. (Score:2, Interesting)
Four words (Score:1, Funny)
Re:In 20 words or less. (Score:5, Informative)
Directories, renames and file meta-data are versioned.
Commits are truly atomic.
Apache as network server, WebDAV/DeltaV for protocol
Branching and tagging are cheap (constant time) operations.
Natively client/server, layered library design.
Client/server protocol sends diffs in both directions.
Costs are proportional to change size, not data size.
Efficient handling of binary files.
Parseable output.
For more details, see the website.
Jon
Re:In 20 words or less. (Score:2)
They do. But they have decided that adding this fucntionality to CVS is not viable, so they're developing subversion instead.
Hint: Many of the subversion developers are also CVS maintainers.
Re:In 20 words or less. (Score:1, Redundant)
Re:In 20 words or less. (Score:3, Informative)
In 20 words or less:
Subversion is CVS on steroids without being tied down to the history of CVS.
And some of the reasons why are:
Subversion handles directories.
CVS does not.
Subversion handles file permissions.
CVS does not.
Subversion makes atomic commits (and rolls back prior to the commit if necessary).
CVS cannot, it will stop at the last file processed (and you have to clean it up by hand).
Subversion uses HTTP/WebDAV (both reliable protocols).
CVS uses it's own protocols which might be less reliable.
Subversion performs more operations in constant time.
CVS uses more time for the same operations although it is not necessary.
Subversion is naitvely client-server.
CVS had the client-server added on after the core code was developed creating some odd aspects of operation.
Subversion transmits deltas, so costs are porportional to change size.
CVS changes are (I believe, not know) proportional to project or file size.
--- Fabrication is the stuff filling the holes of memory.
Re:In 20 words or less. (Score:2)
CVS uses ssh which is much more reliable and secure than yet-another-protocol-over-HTTP.
Re:In 20 words or less. (Score:3, Informative)
CVS uses [kgnp]server (Kerberos, GSSAPI, NTLM, Password) as its communication protocol. It's not even encrypted.
The cvs-over-[rs]sh thing is a kludge, an extension of the local repository access. It requires each person have a Unix shell account with write access to the repository. You can't do much security-wise with that. Since CVS stores each file independently, you can at least say they don't have access to a module but you can't say they don't have access to a certain branch. And you certainly can't say something like "they can't delete/modify existing revisions".
HTTP/WebDAV/DeltaV is nice for a few reasons:
Re:In 20 words or less. (Score:3, Interesting)
Noone in their right minds uses this.
It's a 'kludge' that works extremely well, and fits well into the unix philosophy.
False. It requires that they have an account on the system, not one necessarily that allows you to execute a shell (just like SourceForge has it set up).
True. But this has little to do with the transport protocol.
Re:In 20 words or less. (Score:2)
> Noone in their right minds uses this.
Right, no one uses its authentication for anything important. CVS doesn't have a decent protocol. For extra annoyance, they do use it for anonymous stuff, since it is not good to have a Unix account for anonymous people. So you need two different ways of accessing CVS.
> > The cvs-over-[rs]sh thing is a kludge, an extension of the local repository access.
> It's a 'kludge' that works extremely well, and fits well into the unix philosophy.
No, it does not work well. There's not a lot of Java code available to talk ssh, for example. It's not good for cross-platform stuff.
Also, ssh handshakes are time-consuming. This is important because cvs reconnects for each operation. In contrast, HTTP has well-defined and well-known standards for keepalive and pipelining.
> > It requires each person have a Unix shell account with write access to the repository. You can't do much security-wise with that.
> False. It requires that they have an account on the system, not one necessarily that allows you to execute a shell (just like SourceForge has it set up).
I'm afraid you have me at a disadvantage - I've not seen SourceForge's setup. I'm not a committer on any projects there. However, ssh requires a shell account - it might be a restricted shell of some sort, but they need a shell.
Also, the manual certainly has no better way. If you are able to do so, please patch it. I quote:
There are a lot of things not possible to do with Unix file permissions. Saying things can be added but not modified. (You can have setgid directories, but not setuid ones.) One group that can read/write, one that can read, everyone else who can do nothing. Permissions within the files (short of splitting them into more files, which makes Subversion's ACID semantics difficult) . All of these things are possible with Subversion - you just write a Perl script that inspects the transaction and allows or denies it. Please take a look at commit-access-control.pl [collab.net] for an example.
> True. But this has little to do with the transport protocol.
You need a smart server to accomplish this. Subversion's :ext: method of remote access (rerunning the command on the other machine through [rs]sh) doesn't qualify. Arch's modify-via-ftp doesn't either. Those can't ever do anything but the Unix file permisssion way, but with a server between it can decide what is allowed or denied.
You notably didn't quote/comment on my points about why HTTP/WebDAV/DeltaV was a good choice. They clearly needed a protocol of some sort. I think using the existing standards was a good choice. Why would something else be better? Why would you not use HTTP? You said:
> CVS uses ssh which is much more reliable and secure than yet-another-protocol-over-HTTP.
Do you have anything to back that up? How is HTTP/TLS/WebDAV/DeltaV unreliable or insecure?
If you're that dead set against that protocol, write a new one. It already has the abstraction - both ra_local and ra_dav are supported. Write a new ra_XXX if you so desire. And a new server to replace mod_dav_svn. Of course, no one will use it - the DAV stuff works well. But maybe you'd feel better.
Re:In 20 words or less. (Score:2)
You assume a basic unix filesystem, not something like AFS, which has rich, powerful (though not sub-file) ACL support.
SourceForge only lets you execute cvs when you login (that is, you cannot execute any other program, including any shell). Furthermore, you really don't need line in /etc/passwd, if that is your concept of a 'shell account'. SourceForge uses an LDAP server, I think, for accounts. So, given the abscence of a line in /etc/passwd, and only the ability to execute 'cvs', I don't quite see how this qualifies as a 'shell account'
I did not comment because I had nothing to argue against in what you said, they were all quite true statements. But the benefits you stated has no value to me.
The cryptography for ssh is much more secure than the examples you've give. The authentication means are more powerful, and there is agent-forwarding, both extremely important.
I highly dislike systems writing servers where none is needed (ala CVS with [rs]sh; ssh handles the network).
Re:In 20 words or less. (Score:2)
You're confused as to how this is implemented. ssh itself allows you to restrict the command to ssh. From the sshd manpage:
I'm well aware that I'm not forwarding the agent to the repository, but I am forwarding the agent from my base machine to where I do my work, and from there I authenticate to the repository.
Actually, I can easily forsee needs to forward the agent to the repository, if the repository needs to authenticate to something like the filesystem (ala AFS).
I don't diagree with that statement. However, the 'smart server' doesn't need to know anything about the network, just talk over a unix domain socket.
The need for database systems to talk over a network I do question.
If cvs's ever begins to actually be a worry for me, and I consider a different version-control system, I might look into it. But that would likely mean having to work with WebDAV, which is another argument in its own right.
Re:In 20 words or less. (Score:2)
Well, if it uses a different protocol, it will probably be hard to tie talking to the agent for authentication with the protocol Subversion would be using. In other words, while I could forward the agent to from point 1 to X-1, where X is Subversion, and not need to forward the agent from X-1 to X, and the protocol through 1 to X-1 and X-1 to X are different, it would be difficult to get these two protocols to 'talk'.
Actually, I wouldn't be at all surprised if AFS supported locking, but I won't delve too deep here, since I'm not sure. But certainly don't rule it out.
The fork-exec cost is highly overrated in my book (assuming the code is already in memory), given copy-on-write.
This is one drawback, yes, but lessed a great deal with NSS and the like. It's not the UID that is the problem (practially all systems have a user id of some sort), but more the tying of multiple authentication databases together isn't that great. I wouldn't be surprised the ssh people are working on making it good for authenticating more than unix accounts, though.
Oh, I was more referring to trying to replace the transport mechanism (HTTP(S)), not the communications layer (what is actually spoken across it).
Re:In 20 words or less. (Score:2)
From cvs.info (Direct connection with GSSAPI):
The data transmitted is _not_ encrypted by default. Encryption support must be compiled into both the client and the server; use the `--enable-encrypt' configure option to turn it on. You must then use the `-x' global option to request encryption.
Re:In 20 words or less. (Score:2, Interesting)
Modify it once to support the old "there's no network" calls. Modify it again to support the added on "network enabling code".
For most users this is not a visible issue, that is until:
1. You issue a command via network and it doesn't act like a command when you're in the box.
2. You want to know why #1 happens.
Yes, you can argue that having a web server is extra overhead, but that burden is being supported by people who worry about web servers full time, not by those who worry about source code control. And if you're not using a network, why the extra overhead of CVS? RCS would remove the network overhead entirely.
testing subversion/cvs... (Score:1, Offtopic)
Seriously, though, how, other than using it for real, might one test subversion? And how would you recover from the bugs that will be in there without devoting your life to it for a few weeks?
Just wondering.
Graham
Re:testing subversion/cvs... (Score:1, Informative)
Re:testing subversion/cvs... (Score:1)
a) hope nothing goes wrong (ROFL)
b) backup my personal source tree immediately before each subversion commit step
Because otherwise you can guarantee that when I want to roll back 2 or 3 steps to dig through an issue with my code, I'll hit a bug in subversion.
Now do you get what I was asking? And why?
Maybe next time I'll use a few more words...
Re:testing subversion/cvs... (Score:2, Informative)
But extreme pessimism for the first couple of "checkout-edit-compile-test-release-commit" cycles wouldn't hurt either - just don't expect to be shocked at issues.
I think this alpha stage is more about getting a wider audience using SVN, and give feedback on usability, rather than stability and correctness. Things like how noisy is it, how informative, can a oft-repeated three-step process be reduced to two, or one (or none!) with a little thought for SVN's activites. Stuff that comes up when code is released into the wild.
Re:testing subversion/cvs... (Score:4, Informative)
Seriously, though, how, other than using it for real, might one test subversion? And how would you recover from the bugs that will be in there without devoting your life to it for a few weeks?
You raise some serious concerns, let me try and alleviate those fears.
I've been using Subversion for a few months now (since revision 1210 or so), and let me to tell you, there is nothing that the dev team values more than the integrity of your data. Nothing. This means that once something has been comitted, it will never be lost.
Does this mean your data is guaranteed with an alpha-quality system? No. But let me tell you, in 6 months I've not seen it happen once. Oh sure, there have been a few times when the DB schema changed, and the format of the dumpfile (more on that in a bit) changed on you, but these things were discussed well in advance on the dev list and not only did you have plenty of opportunity to prep your data for the change, there were ways for you to convert your data after the fact.
If you are the sort of person that likes to tweak around with your data in the repository (if you come from a CVS background -- you have to be) and gets the heeby-jeebies from having your data stored in a non-accessible format, let me ask you this, do you worry about the fact that you have data stored in Oracle/Postgres/Sybase/MySQL? No? Then why worry about the Subversion repository at all?
Of course, the dev team has provided you with some nice backup tools, for example, the normal Unix cp command can be used to make hot-backups of your repostories, a very cool trick. In addition, there is an svnadmin command that has a "dump" feature that allows you to store your repository in a text file, if you worry about Subversion trashing your data, keep regular dumps of your repository.
Of course, all is not rosy. I would like to see a patchsets feature, and I really miss "cvs annotate" (but "svn blame" is scheduled to be added after the 1.0 release), and of course, the db has a tendency to lock up every once in a while (you can fix it easily with db_recover) but by and large, these are things I can live with.
After using this system for a while, I've come to one conclusion: it works. And it works better than CVS. Forget the years of bad habits you learned on CVS, once you start using Subversion, you will start to think about SCM systems in a whole new way. Try it out.
Re:testing subversion/cvs... (Score:2)
Please check out hot-backup.py [collab.net]. It doesn't do much more than cp, but it doesn't just do cp repository backupdir. It copies the logfiles last. That's important.
not just "akin to CVS" (Score:5, Informative)
This is intended to be a replacement for CVS. No less, and no more (for the "more", see some of the more experimental SCM stuff like Tom Lord's arch).
Thanks (Score:1)
Re:Thanks (Score:2)
Be interested to hear what problems you're having. I used ClearCase in one of my jobs, and thought it was really rather good.
Cheers,
Ian
Re:Thanks (Score:1)
Working on a medium to large project with it is a good choice.
But if you're out to get a huge project going, it's getting complicated. I'm talking about multi-site development. You just have to take so much attention, it will eat away a pretty large amount of time.
Not to mention the terror an unexperienced or badly trained engineer can cause.
Re:Thanks (Score:1)
Ah yes, I remember now. We too had to use it for multi-site development, and the speed was awful. So we got into some sort of remote syncing, and that turned into a nightmare too...
Yes. Now I recognise what you mean.
Cheers,
Ian
Re:Thanks (Score:2)
curious,
-l
My own bad experience 9 years ago (Score:3)
I have never worked on huge projects, never more than a dozen programmers at most, and CVS has always been good enough. I will certainly switch to subversion, or maybe one of the others, because I like a lot of the improvements, but CC has always seemed like bloated overkill.
Re:Thanks (Score:2)
That's obvious!! (Score:5, Informative)
1. Needs kernel modifications in order to work. PROFOUNDLY STUPID. It's always an adventure trying to get clearcase to work with any recent linux kernel, and forget trying to keep current with kernel security patches.
2. "Filesystem" style sharing does not scale well outside of a high speed, local network. If your developers are distributed around the internet you need to use clearcase's horrible hack "snapshot" views, or shell out ridiculous amounts of money and complexity to implement multisite. It's very difficult from a performance and a security standpoint to use clearcase over a low-speed VPN.
3. Good GUI administration tools are windows-only. While rational could have created cross platform admin tools when they ported their product to Windows, they didn't. Instead they rewrote their admin tools to be windows only, added many new features, and now the windows tools are 200X more usable than their unix equivalents. When I pressed irRational when the unix tools would be similarly improved they gave the patronizing answer that unix customer's don't want good admin tools. Sounds like a self fullfilling prophesy to me. The unix GUI tools are so awful that it is easier to use the command line! Thus, irRational insures that unix shops with clearcase will always have a brick-wall style learning curve.
4. Vobs don't scale well, especially when you version large binary files, like media. You have to manually tune how many vobs to use and how large to make them.
5. Relies on automounting and persistent filesystem connections for day-to-day work. This design is inferior to a more traditional client-server TCP/IP app in terms of both performance and robustness.
6. Lack of commitment to the unix platform. iRational has stopped future development on their unix bug tracking software (DDTS) in favor of a MS-ACCESS backed solution. A large majority of new clearcase features are windows-only. You would think that Rational would be a cross platform company, but they are not. They make platform-specific solutions for multiple platforms, most of them purchased from some other company and poorly maintained.
7. Extremely high maintenance costs, not just in the licensing but in the dedicated personel needed to throw their careers away doing nothing but babysitting the vobs and views.
If you're buying a proprietary CMS the last thing you should consider is iRational clearcase. Try bitkeeper or perforce and you'll be much happier.
Re:That's obvious!! (Score:2, Interesting)
Scalability is the biggest downstream issue any manager has to consider before choosing Clearcase. It is extremely resource hungry and I used to work for a small company that deployed a Sun Enterprise server to support CLearcase for just 10-15 developers. Get ready with barrels of memory - shticks and drives.
The Steep learning curve is not something that u can wish away in a production environment.
In spite of all this, I remain fond of Clearcase - It was the first Version Control/Configuration System I used seriously and haven't found anything even remotely similar in terms of functionality. I felt like vomiting when I first used CVS after 4 years of CVS. Another nice feature is it integrates nicely with other Rational products like ClearDDTS the bug tracking system - Against a specific ticket you can check the list of related checkins/checkouts.
It was originally developed by a company called Atria and was later taken over by Rational.
And don't forget multisite. A Pig it is - but it provided lot of value for money, especially to comapnies that could afford it.
Re:That's obvious!! (Score:2)
That's funny
At my current job we use Perforce, which, although it has its own problems, is quite alot better than either CVS or Clearcase.
But subversion looks really good
way to go (Score:1)
faster, better overall design, extendable, seamless integration with apache
while we're at it, let's burn our Makefiles too (Score:2, Interesting)
While we're considering throwing away CVS, let's also throw out make. Check out Scons [scons.org], a replacement for make. I have been using it for a few months on small projects and it's shaping up to be a really great tool.
Burn your Makefiles!
Re:while we're at it, let's burn our Makefiles too (Score:1, Informative)
Re:while we're at it, let's burn our Makefiles too (Score:4, Interesting)
Ant has some pretty cool features (and a few misfeatures, sadly), but it's really caught on in Java-land.
Re:while we're at it, let's burn our Makefiles too (Score:2)
We are moving our visual studio build to Nant because it works with our Nunit [sourceforge.net] tests and can do everything we need automatically. We have used both nmake (make) and VS to accomplish builds in the past but have had to overcome a few difficulties in large builds that hopefully this will solve. We'll see but using ant in the past for my java projects I am hopeful. Using nmake simply was to error prone on large builds, we don't like finding that our build failed because of whitespace problems, and VS was simply to unreliable for us (your own results may vary). We still use vs.net to build our custom installer, but we call it from the cmd line using Nant.
Tying the whole process in to a source control app like subversion or cvs (which we currently use) would benefit us. Hopefully someone will write a
Re:while we're at it, let's burn our Makefiles too (Score:2)
Make is fine, but like I said we are searching for something a little more friendly.
Re:while we're at it, let's burn our Makefiles too (Score:2)
After using ant for a while at my work, we decided that it was the most common cause of people checking in broken code (which hadn't caused a problem for the author) and incorrect builds, and switched to make (with a python script to find java dependancies correctly).
The other problem with ant was (at the time, at least), there was no way to avoid running a program because it could be determined that it was unnecessary. This made trying to use EJB with a container that required an EJB compiler practically impossible, because we had a 20 minute build cycle, even when the ejbc step wasn't necessary.
Re:while we're at it, let's burn our Makefiles too (Score:2)
You can also do some really interesting things with conditionals and what amounts to iterative includes. I have a set of Makefiles totalling 315 lines which will accurately do exactly the steps needed to rebuild a program if any source file changes, regardless of which directory the file is in, and can be run from any directory in the tree. If nothing has changed, make says nothing except "'target' is up to date". It wasn't terribly hard to do.
Re:while we're at it, let's burn our Makefiles too (Score:2)
Re:while we're at it, let's burn our Makefiles too (Score:2)
Build variations should be refactored until they come down to, essentially, "which parts of the code do I build". Then, based on simple cues from the user, you can build the right things.
My non-recursive make is for a project which has about nineteen targets which are either binaries or libraries; the one which is build depends on which directory you invoke make from. There is a make target to make a distribution, which includes everything needed for the target in the current directory and can be build from the root of the distribution.
The scalability issue is not with the number of build variations but with the number of types of build variations. Having a lot of dissimilar build variations is just a mess, regardless of what you're using to build with.
Re:Questions about scons (Score:2, Informative)
"Unless you don't know Python. I never figured make syntax to be very difficult."
Neither is Python, and Python is much more powerful. I've seen makefiles for complex build processes, and they are nigh unreadable. Even if you don't know Python already, we considered the choice of a well-established, actively developed, powerful scripting language to be superior to the invention of Yet Another Mini Language.
"I didn't realize this was an improvement over make, which is pretty language-agnostic. What about other languages? I usually assume listing specific elements means unlisted elements are NOT supported."
You know what they say about assuming... I'll stipulate that the exact meaning of this statement is unclear at first glance. However, consider one of SCons's other features...automated dependency generation. In order to do that, SCons must have a dependency generator for that particular language (to parse #include's, etc.) Users can add their own dependency generators as well. SCons *will* support any language just like make, as long as you can put up with specifying dependencies explicitly for "unsupported" languages, just like make.
SCons also makes it much easier than make to set up builds, since it already has some built-in knowledge of the way certain tools work. All of this is of course user-extensible, but we provide built-in support for some common tools.
"That -j option look like they borrowed it from make"
Okay, yes, we did borrow that from make.
"Not sure exactly what this means, but make understands RCS and SCCS, IIRC. Been a while since I used the feature"
SCons does not integrate with a specific source control system, but it does allow you to specify multiple directories (repositories) that will be searched for files before they are built or taken from the host machine. This allows building from a server, or even multiple servers. I think this is akin to make's "VPATH" support, but AFAIK it is more flexible.
Come and see SCons and judge for yourself. I find it alredy vastly superior to make for large-scale, highly variant projects (or any project!) Of course, I am biased, since I wrote a large part of it, but I did so because I found existing tools insufficient.
www.scons.org
Oh good, It's just a software story (Score:1)
Thank goodness, the last thing we need are some subverted scientists doing whatever in LEO!
Gil, just being a peanut gallery member
comparisons (Score:1)
arch vs Subversion (Score:4, Informative)
http://regexps.com/src/src/arch/=FAQS/subversion
-l
Re:arch vs Subversion (Score:2)
Subversion's not ahead here; but by using a standard database, at least you can use standard database tools to manage it. You still have to learn, of course.
I like arch. It's a cool system. But nonsense like that...
-Billy
Re:arch vs Subversion (Score:3, Interesting)
Re:arch vs Subversion (Score:2)
Nothing. Nothing's wrong with using standard filesystem tools to manage arch. Nothing's wrong with arch -- or at least I have nothing to criticise.
What's wrong is arch's idiodic propaganda stating that Subversion is magically inferior because it uses a database rather than a file system.
The one weakness in arch is that it manages the existing filesystem as a database but accepts the use of non-database tools to alter it. You can use grep and so on to maintain it, but you'll certainly destroy it if you don't know exactly what you're doing, since filesystem tools can't possibly know how to maintain a database, while database tools must.
But this isn't a big deal to me -- after all, you can have a perfectly good database which isn't a version control system, so your database management tools can cause a lot of problems as well when used by an idiot. So again, I have no complaints with arch's approach. Only its marketing.
-Billy
Re:arch vs Subversion (Score:2)
I have to note, though, that high performance databases don't run as layers on top of the filesystem; they run directly on the drives, with no filesystem intervention. ReiserFS won't change that; it may be better than ext2fs for database tasks, but it's still not tuned for big-league work. And it never will be -- it's not targetted for that.
-Billy
Re:arch vs Subversion (Score:2)
The benefit of a DB based filesystem (direction of ReiserFS4) are also great. It may be the case that you'll not need a separate DB (but maybe you will, if you need other features!).
MS going to a DB filesystem will make our lives more difficult for sure. We just need to way and see, but that's my guess. And they can make it work, because the can force a single DB filesystem you cannot avoid.
On the other hand, Linux will probably have options for DB filesystem, but as they will not be widespread (and there may be a lot of incompatible DB fs) for a long time, you can't sucessfully base aan app on a specific DB fs beign at the core.
This my semi-uneducated opinion of course.
Re:arch vs Subversion (Score:2)
The point is that having a local archive of all the versions allows you, for example, to grep through the source for that old snippet of code in some version that you need but aren't sure what version it's in. Sure, you can checkout all the Subversion versions locally, but arch does it implicitly. I think that's pretty sweet.
dig around in here to get an idea of what the file tree looks like:
http://regexps.com/src/src/arch/%7barch%7d/
-l
Re:arch vs Subversion (Score:2)
-Billy
Re:arch vs Subversion (Score:2)
-l
Re:arch vs Subversion (Score:2)
Anyhow, I certainly agree that arch has this, and other, advantages. (Many others.) None of them make arch "more managable" or "more usable" or anything else than subversion; they simply give the two different characteristics. Remote files have HUGE advantages as well, in the right environment.
-Billy
Re:arch vs Subversion (Score:2)
What on earth does that have to do with your claim that "with arch, you can use standard tools to access past revisions" (implying VERY specifically that you can't do that with Subversion). The entire point of the document is to compare Subversion and arch; instead, you're allegedly comparing databases versus file systems.
"Allegedly" because you're actually comparing your special-purpose database to Subversion's use of BDB (or whatever they switch to when they've had enough of that).
That second point isn't some loopy overgeneralization about databases: it's an observation about how the implementation "came together" around simple file formats.
In a FAQ about the history of arch, that makes sense. In a FAQ about comparing Subversion versus arch, it doesn't. Frankly, your statement here doesn't even make sense, considering what you're actually SAYING in that document. You're NOT giving a history; you're making a very specific claim about present capability.
I'm REALLY impressed with arch. I like the documentation I've read, like the software. I'm not an enemy. But I HATE, abhor, detest this kind of sniping against other projects.
Second, what I've tried to say in the FAQ is not that databases are overapplied (that's for another discussion) but rather that arch's standard-file-formats and ordinary filesystem tree orientation resulted in a very tiny, simple implementation that nevertheless has many of the desirable semantic and performance characteristics people often presume require a database.
Again, context is very important. The context of this FAQ is a contrast between Subversion and arch; in this FAQ, any bullet list claiming a feature especially for arch is implicitly a claim that the same feature is unavailable or very difficult in Subversion.
In fact, I would definitely say that by the definition of the term "database" you've written your own database. It's probably not relational, but RDBs aren't the only type, nor are they unambiguously the best. So you aren't scoring any points on the "databases are not needed" scoreboard. All you're doing is proving "I can write my own database which serves my needs better than some general-purpose database" (I would tend to agree, even without the beautiful evidence of arch to support your argument).
Of course, this sort of claim doesn't belong in a comparison with Subversion either, although it's certainly worth some good discussion.
You know what, I'm wondering if you're talking about the same FAQ I am. Look at the link which started this, and make sure we're on the same page.
With all due respect, maybe I'm not the one who needs to work on his reading comprehension
-Billy
Re:arch vs Subversion (Score:4, Informative)
As a simple example, consider (numbered for my convenience)
However, this characterization is horribly, obviously lopsided in favor of arch. Putting the smarts on the server is a good thing, because it prevents replication and therefore differences and therefore bugs on the client side, with logic the client should not need to deal with. It makes it harder to write an arch client correctly (witness the profusion of cvs clients).
1 does not follow; a server can often do things faster then a client, because the client may be slow while the server is an 8GHz quad-Sexium with 8 gigs of RAM.
2 does not follow as an advantage; there's nothing that says a server-based solution can't scale, they do all the time.
3 is true, but you're trading off with an entire system (server + clients) that's harder to program correctly because of rampant logic duplications in the clients. It's not an unmitigated advantage in favor of arch, and in fact I read it as an advantage to Subversion.
4 is a nonsequitor; it may be true but it does not follow from being non-centralized. Same for 5. Again, there's no law that servers must be difficult to recover failure from.
This is just one example of an attitude that pervades the linked document. In fact, the article pointed does more to turn me off to arch then anything else. If the author was a developer for arch, I'd be concerned at the lack of experience in design (it is almost never the case that one solution is better then another in every way) and inability to fairly evaluate two products (why not show what both are good for?) being shown here.
Re:arch vs Subversion (Score:2)
The point of distributed archives is replication. It's fundamental to the design. It assumes you live in an often disconnected world and you can sit there with your laptop in the middle of nowhere doing merges and whatnot independent of some remote archive.
Anyway, that's the point of it. If it doesn't fit your environment, you shouldn't use it. :)
using your enumeration:
[1]. The problem is he doesn't define "fast". When I think "slow", I'm thinking being on the slow end of a pserver/webdav connection in a large project with a lot of concurrent branches in need of merging. Still, I agree, if you can afford the server and all the clients have a decent connection.
[2]. Well, server-based solutions are expensive on the Linus Torvalds level. Have you seen the merges that guy does? Scary.
[3]. You're right, except that there are no arch servers (by server, I'm guessing the guy means "main ftp archive" or something). But sometimes it's better to have a smart client. I definitely don't want Apache trying to render web pages for me... sending an image to a dumb browser, no matter how annoying IE vs Mozilla incompatibility gets! :) But yeah, in a highly centralized, probably corporate-style, environment, arch is probably not as good a fit as Subversion.
[4] & [5] follow from being decentralized because the distributed trees all maintain the history. It obviates the need to specifically keep mirrors of the main archive around since each local archive is already a mirror. At least, that's my understanding of it.
As far as the author is concerned, I'm guessing he's just trying to advertise his wares. He may have failed due to his poor writing, but I'm guessing his goal was marketing. You might contact him about it... you know: download arch, get a copy of his tree, write up a patch, and publish the archive. hehehehe
-l
Re:arch vs Subversion (Score:2)
He may have failed due to his poor writing, but I'm guessing his goal was marketing. You might contact him about it... you know: download arch, get a copy of his tree, write up a patch, and publish the archive. hehehehe
"Marketing" open source is an interesting issue. I think the issues involved in attracting developers and users to your project are not well explored by the community. There should be a 'definitive essay' on the topic, as in 'Homesteading the Noosphere". (I intend to write one in a few years, if my projects are released and do well. Failing that, I'm not qualified, so don't ask me to do it.
See, the author here has already turned me off and lost. Marketing Open Source should be more honest... 'here's what it's good for, here's what it isn't, here's what needs more work'.
Re:arch vs Subversion (Score:2)
2) The author isn't bashing Subversion. His point is he thinks arch has some better features, particularly for open source-style development.
3) bash and awk both run on Windows and Mac. The author says (in another document on the website) there's also a Perl version in the works.
4) ftp is not an issue since ssh can masquerade ftp well enough.
-l
Re:arch vs Subversion (Score:2)
2) Ok, maybe bashing is a too harsh word, but I'd hardly say his comparison is unbiased.
3) Yes but there are other things like hard links etc (like almost the entire unix tool chain). A quick search on google finds the author saying himself that arch is only for POSIX environments.
4) Even if it works when you use passive mode ftp, you still need shell access for ssh. Anyway, maybe this isn't such a big problem since there are patches for webdav support. Maybe they'll get integrated into the main tree soon.
Bottom line: both of these will easily blow cvs out of the water. Use whatever you like.
Re:arch vs Subversion (Score:2)
right, which was the point of my original post:
Here is short comparison of why you might want to use arch over Subversion, depending on your project's needs
-l
versus jakarta slide? (Score:2, Interesting)
Does anyone know how subversion compares with Slide [apache.org] from the Jakarta Project? Slide is also a WebDAV/DeltaV client and server. In the past, I've been more interested in Slide because it has a more "pluggable" back end (Slide is in Java, and I am a pretty good Java programmer, not so much with the C.) Easier to embed/extend for my own uses.
For example, are the two interoperable in any way? Can you use one's client to talk to the other?
Re:versus jakarta slide? (Score:2, Insightful)
If you're looking for something to embed/extend and you know Java, then Slide would make sense, especially if you're planning to use it for something other than source code management. However, you might still want to use subversion for the source of that project... Most people don't need to extend their source code manager much, except perhaps with a few scripts.
Seems like too much baggage (Score:2, Interesting)
- Berkeley DB, a particular version (this makes sense)
- Apache 2.x
- WebDAV
- Neon
and a bunch of other stuff, IIRC. (Their site is
All we need at my company is a server to run on one Linux machine and clients for all the others (MacOSX/WinXP/Linux/IRIX), all within our firewall.
Doesn't all the above stuff, especially the Apache/WebDAV/Neon stuff, seem like overkill just to implement a network protocol for a version control system? Setting up a CVS server is certainly not this complicated, and it seems like with a little more effort on the developers' part, much end-user time and pain could be saved. Does Apache/WebDAV/Neon really buy enough so it's worth the install&admin overhead?
I'm not trying to rag on the Subversion developers; it looks like a really cool system, once you get it up & running. It also looks like they've really done a great job of meeting their goals. I'm definitely looking forward to checking it out -- as soon as I have enough time.
Re:Seems like too much baggage (Score:2)
Re:Seems like too much baggage (Score:2, Informative)
APR was dead simple. (No RPM available, but not needed.)
Autoconf: I had a version of autoconf in
libtool 1.4: no problem. (RPM available.)
I downloaded neon, and subversion built it automatically. (RPM available, but I didn't use it.)
Berkeley DB was pretty simple, except that the whole subdir of docs/ that explains the build process was missing in my download -- I found the instructions on the web. This also created errors when doing the 'make install', had to use make -k to work around them. (No RPM for this version available.)
However, when I went to configure subversion, it didn't recognize my Berkeley DB install (in the default place,
As for apache, the first thing is subversion requires 2.0.40, but the latest I can find is 2.0.39. OK, so I figured out that means I need the latest CVS version. Also, I already have an older 1.3.xx version running because RT requires it, so now I have two versions running simultaneously! A bit of an admin hassle, but again, not a showstopper. (No RPM available for this version.)
(I also installed python 2.0, which required a bunch of other stuff, but I gather that was optional.)
I guess, from the comments I've seen, that I'm the only one who thinks it's weird to require people to install a web server just to do source control (with more than one machine). HOWEVER: now that I've started to try it out, I have to say it's really a pretty cool idea. It might even be useful to my company!
I expect all this will get much simpler, but for now it's not for the faint of heart. Still, from what I can tell I think subversion will be the best post-CVS CVS!
Re:Seems like too much baggage (Score:2)
But you can just as easily build a Subversion client that has BerkeleyDB linked into it; you'd still be able to create and access a repository on local disk.
In other words, it's relatively simple to build and use Subversion for "personal" use -- say, on a box where you don't have installation privs. Just use it in your home directory.
Re:Seems like too much baggage (Score:3, Insightful)
Re:Seems like too much baggage (Score:2, Insightful)
You are overstating the requirements a bit. WebDAV is part of Apache 2, and Apache 2 is only required for remote access to the repository. The only real dependancies are Neon, BerkelyDB 4, which, at least for linux, will likely be included in the next generationj of distributions as Berkeley DB 3 and 2 are now. A neon is justa small shared library, not that big of a deal.
Look at it this way, by the time Subversion is released the packages it depends on will be standard parts of most Linux distributions and will be staples in the *BSD ports system if they aren't already. Subversion will just snap right in.
And I have to disagree about administrative overhead. By integrating with Apache, it's one less network service to configure, plus you get to take advantage of Apache's authentication modules, and you get web repository access with no extra setup.
Re:Seems like too much baggage (Score:2, Informative)
'WebDAV' is a protocol. 'Neon' is a client library we (Subversion) use to speak that protocol. 'Apache' is a server that provides an implementation of the protocol that we use in our server.
So yes, we require Neon for building the client, and Berkeley DB if you want to access a repository directly (either for a local repository or if you're building a server), and Apache if you want to run a server. These requirements don't seem to crazy to me, and if you don't want to mess with them yourself, download a package. There are RPM's and a FreeBSD port (I think both still need to be updated for alpha, but I'll be doing that for the FreeBSD port tonight, and the RPM's are always updated pretty quick).
-garrett
Re:Seems like too much baggage (Score:2)
I did:
sudo apt-get install subversion
Voila! Installed, configured. It's just a little older than today's alpha (.13) but I don't mind. It will automatically update to the latest version in a few days.
I've been using Subversion for three months... (Score:4, Interesting)
SCC works well for several purposes:
oh no! (Score:3, Funny)
How did you know what I was doing? Did someone stick an X10 in my bedroom?
I think.. (Score:2)
How about migration tools from CVS? (Score:2)
Re:How about migration tools from CVS? (Score:5, Informative)
The script examines the cvs repository, deduces changesets, and commits them to an svn repository. It works right now.
However, it doesn't yet convert cvs branches and tags. We're working on it.
Re:why does subversion exist? (Score:2, Informative)
Re:why does subversion exist? (Score:4, Informative)
After a decade (has CVS been around longer?) some things just need to be restarted from scratch as every hack possible on the base has already been tried.
In the case of CVS, it's the storage format that is causing the largest problems -- and the reason for the term 'repo-copy' which is one of the most annoying things I can think of (repo-copy then check out an old version -- look, duplicated stuff!).
Re:why does subversion exist? (Score:4, Informative)
The CVS guys are working on subversion, but "fixing" CVS would not necessairly be the best way to fix their problems. Massive changes in CVS would raise a cry of desperation from the masses of programmers that rely on CVS for day-to-day operation. Also, if it is discovered that a totally new way of handling things is much better than the way CVS works, you encounter nasty if not impossible upgrade difficulties.
People don't want to put their code at risk. Too much time and money goes into it. Subversion "solves" the migration problem by making a totally new project.
Re:ssl (Score:3, Insightful)
Re:ssl (Score:3, Insightful)
So the client is entirely web based? How do you checkin code? Paste it into a web browser?
No, the client is a command-line client, like cvs. It just uses HTTP (or to be more specific WebDAV, a HTTP extension) to communicate with the server.
Re:ssl (Score:2)
Ugh, how awful. One of the things I love about CVS is that it can run over ssh.
Re:ssl (Score:2)
Re:ssl (Score:2)
I care becuase ssh has agent forwarding, public-key authentication, port tunnelling, and much more. All of this I care about, and use in conjunction with CVS and other things.
The entire user-agent system for HTTP(S) is incredibly crappy compared to what ssh provides.
Re:ssl (Score:2)
Re:Emacs support (Score:3, Informative)
Unfortunately, the VC API doesn't exactly match up with subversion concepts. So people have been batting around ideas to revamp the API for pcl-cvs, or maybe inventing a new API.